[
https://issues.apache.org/jira/browse/HDFS-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated HDFS-5276:
---------------------------------------
Attachment: HDFS-5276.001.patch
Here's a patch which implements thread-local counters in
{{FileSystem#Statistics}}. When incrementing, no locks need to be taken-- each
thread simply increments its thread local value. The read operations sum up
the thread-local data.
Note that it is not necessary to use {{AtomicLong}}. We only need
{{volatile}}. This is because we only ever have one thread updating the
thread-local statistics. So there is no "lost updates" problem and no need for
{{CAS}} or {{LOCK}], etc. We only need a read barrier, which is provided by
{{volatile}}.
Give this a try and see if it addresses the performance problem. I think this
should perform well in non-massively-multithreaded settings as well.
> FileSystem.Statistics got performance issue on multi-thread read/write.
> -----------------------------------------------------------------------
>
> Key: HDFS-5276
> URL: https://issues.apache.org/jira/browse/HDFS-5276
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.4-alpha
> Reporter: Chengxiang Li
> Assignee: Colin Patrick McCabe
> Attachments: DisableFSReadWriteBytesStat.patch, HDFS-5276.001.patch,
> HDFSStatisticTest.java, hdfs-test.PNG, jstack-trace.PNG, ThreadLocalStat.patch
>
>
> FileSystem.Statistics is a singleton variable for each FS scheme, each
> read/write on HDFS would lead to a AutomicLong.getAndAdd(). AutomicLong does
> not perform well in multi-threads(let's say more than 30 threads). so it may
> cause serious performance issue. during our spark test profile, 32 threads
> read data from HDFS, about 70% cpu time is spent on
> FileSystem.Statistics.incrementBytesRead().
--
This message was sent by Atlassian JIRA
(v6.1#6144)
