Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have configured two servers each with 32 GByte RAM, 2x Xeon 2.4 GHz, 4x 480 GByte Intel SSD on a LSI MegaRAID SAS 9261-8i controller. They should be identical, however one of them has a very poor performance for operations like 'du' and 'find'.

For example, a 'du' command on ten internal subversion directories with 1000 files each takes 31 seconds on the slow system, but returns instantly on the other one. Files are of course identical.

root@server26:/var/tmp# date; du -skh /home/web0000/svn/db/revs/10?; date
Wed Jan 16 22:01:06 CET 2013
886M    /home/web0000/svn/db/revs/100
2.0G    /home/web0000/svn/db/revs/101
766M    /home/web0000/svn/db/revs/102
317M    /home/web0000/svn/db/revs/103
533M    /home/web0000/svn/db/revs/104
937M    /home/web0000/svn/db/revs/105
486M    /home/web0000/svn/db/revs/106
961M    /home/web0000/svn/db/revs/107
1.3G    /home/web0000/svn/db/revs/108
1.5G    /home/web0000/svn/db/revs/109
Wed Jan 16 22:01:37 CET 2013

I have also tried the same command on a different server with conventional hard disks (RAID1), the command completes in less than one second. That server has been rebooted to make sure nothing is in the file system cache.

Similar problems when running 'du' or 'find' on /usr or /var.

The read/write performance for a single large file seems to be ok:

root@server26:/var/tmp# dd if=/dev/zero of=largefile bs=102400000 count=100
100+0 records in
100+0 records out
10240000000 bytes (10 GB) copied, 39.4998 s, 259 MB/s

Read speed is about 500 MB/s. But I have not the faintest idea why a simple 'du' or 'find' command is so slow. Please advise.

share|improve this question
What OS are you using? Kernel, distribution, filesystems? – ewwhite Jan 16 '13 at 21:33
Raid controllers identical firmware? I am inclined to say "look raid controller downstream" (cabling etc.) because your time on that thing would be slow even for discs, but sometimes bad cabling can lead to - ah - "rarely evailable data" on the link. – TomTom Jan 16 '13 at 21:33
OS is Debian Squeeze, file systems are ext4. RAID Controller firmware is also the same on both controllers. – nn4l Jan 16 '13 at 21:42
I there is bad cabling then I should also have bad performance for the single large file read/write, but that's not the case. – nn4l Jan 16 '13 at 21:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.