hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Binglin Chang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-5276) FileSystem.Statistics got performance issue on multi-thread read/write.
Date Tue, 01 Oct 2013 16:11:26 GMT

     [ https://issues.apache.org/jira/browse/HDFS-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Binglin Chang updated HDFS-5276:
--------------------------------

    Attachment: ThreadLocalStat.patch

A quick hack implementing ThreadLocal version of AtomicLong, you can see from the code that
using thread local has two impact:
1. incrementBytesRead/Written using threadlocal can avoid contention, but introduce null check
and hashmap lookup.
2. getBytesRead/Written now need to loop over all threads, which takes more time than before(just
a heap lookup)

> 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, 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)

Mime
View raw message