On Fri, Jul 25, 2014 at 7:35 PM, <Valdis.Kletnieks@xxxxxx> wrote: > On Fri, 25 Jul 2014 15:23:42 -0700, Arlie Stephens said: > >> If you want an annoying problem, explain and/or fix directory >> performance on ext4. I've got a server where an ls of a directory took >> 5 seconds, according to "time", even though it only has 295 entries at >> present. > > I don't suppose you could get a trace of where that ls is spending its > time with the kernel's trace facilities, or even just getting a stack trace > of where that ls is in the kernel? > > I'll go out on a limb and ask if a *second* ls of the same directory runs > quickly because it's now cache-hot. If so, I'd start looking at whether > there's large amounts of *other* disk activity going on, and the reads of the > directory are getting hung in the I/O queue behind other disk read/writes. > > Also, are you doing an 'ls' (which just requires reading the name/inode# > pairs), or an 'ls -l' whihc in addition requires a stat() call to read in the > inode itself)? That makes a lot of difference. Cache-cold on my laptop, and a > *huge* Mail/linux-kernel directory (yes, it really *is* an 11M directory, > it's got a half-million entries in it): > > [~] echo 3 >| /proc/sys/vm/drop_caches > [~] cd Mail > [~/Mail] time ls linux-kernel/ | wc -l > 478401 > > real 0m2.387s > user 0m0.500s > sys 0m0.433s > [~/Mail] ls -ld linux-kernel/ > drwxr-xr-x. 2 valdis valdis 11005952 Jul 25 19:30 linux-kernel/ > [~/Mail] time ls -l linux-kernel/ | wc -l > 478402 > > real 0m32.915s > user 0m2.483s > sys 0m20.787s > Would you find reading strace as I can get the system calls and profiling the code so so we can trace where the issue is based on timing and cpu usage of the code running ? If not seems the issue is either with I/O queueneeds to add support for better reading of multiple large disk actives. Cheers Nick _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
