[ https://issues.apache.org/jira/browse/HDFS-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782394#comment-13782394 ]
Haohui Mai commented on HDFS-5276: ---------------------------------- [~chengxiang li], can you post the detailed configuration of the test, for example, what kinds of cpu are you using to run the test? And can you test the differences of end-to-end latency before and after the patch? Although this JIRA do bring up a good point, it seems that many of us are still yet to be convinced that this is a real problem in production settings. Since there're many research proposals available since 80's, I believe that it will be straightforward to apply one of them once the community is convinced that it affects the performance significantly, by a detailed analysis of the behavior of real-world Hadoop workload. > 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 > Attachments: DisableFSReadWriteBytesStat.patch, > HDFSStatisticTest.java, hdfs-test.PNG, jstack-trace.PNG > > > 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)