hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ravi Prakash (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-2984) S-live: Rate operation count for delete is worse than 0.20.204 by 28.8%
Date Wed, 01 Aug 2012 00:19:34 GMT

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

Ravi Prakash updated HDFS-2984:
-------------------------------

    Attachment: slive.tar.gz

Ok! I've been slacking on this bug for way too long. But here are my experiments and the data.

WHAT ARE THE FILES IN THIS TARBALL?
====================================
patch is the diff of 2 minor optimizations I made in hadoop-23.

I then ran Slive on clean HDFS installations for 0.23 and 0.204. These are the commands I
ran. First create 200000 files (hopefully that's what it does... though its not important
if it doesn't)
bin/hadoop org.apache.hadoop.fs.slive.SliveTest -duration 50 -dirSize 1225 -files 200000 -maps
4 -readSize 104850,104850 -writeSize 104850,104850 -appendSize 104850,104850 -replication
1,1 -reduces 1 -blockSize 1024,1024 -mkdir 0,uniform -rename 0,uniform -append 0,uniform -delete
0,uniform -ls 0,uniform -read 0,uniform -create 100,uniform and then delete 50000 files (again,
hopefully that's what it does)
bin/hadoop org.apache.hadoop.fs.slive.SliveTest -duration 50 -dirSize 1225 -files 50000 -maps
4 -readSize 104850,104850  -writeSize 104850,104850 -appendSize 104850,104850 -replication
1,1 -reduces 1 -blockSize 1024,1024 -mkdir 0,uniform -rename 0,uniform -append 0,uniform -delete
100,uniform -ls 0,uniform -read 0,uniform -create 0,uniform
I do this 3 times. Hence the 6 files
<branch>.C200 <- create 200k files
<branch>.C200D50 <- delete 50k files

In the last run, I delete 500000 files, and use jvisualvm to create snapshots
while I am profiling. The two snapshot*.npm files can be loaded into jvisualvm.



OBSERVATIONS
=============

Create seems to be twice as fast in 0.23. So I'm not too worried about that.

Delete on the other hand is a lot slower. I've tried optimizing, but I don't
know if there's much else that can be done. A huge reason is probably this:
http://blog.rapleaf.com/dev/2011/06/16/java-performance-synchronized-vs-lock/
In 0.20 we were using the synchronized variable, which although is 2-7.5x
faster (as reported in the blog), is unfair. In 0.23 we are using a fair
ReentrantReadWriteLock. This is obviously going to be slower and since
writeLock() is what's taking the most amount of time (ref the jvisualvm
profile), I am led to believe that we must incur the performance hit in order
to be fair.

Comments are welcome. Please let me know your thoughts.


@Todd: These are on the latest branch-23 74fd5cb929adc926a13eb062df7869894c0cc013
                
> S-live: Rate operation count for delete is worse than 0.20.204 by 28.8%
> -----------------------------------------------------------------------
>
>                 Key: HDFS-2984
>                 URL: https://issues.apache.org/jira/browse/HDFS-2984
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: benchmarks
>    Affects Versions: 0.23.1
>            Reporter: Vinay Kumar Thota
>            Assignee: Ravi Prakash
>            Priority: Critical
>         Attachments: slive.tar.gz
>
>
> Rate operation count for delete is worse than 0.20.204.xx by 28.8%

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message