[ 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