Very Computer

by **Jeremiah DeWitt Weine** » Wed, 04 Jul 2001 02:48:25

OK, riddle me this...

I have a directory with 64,000 files in it. They're all zero-
length regular files in an ext2 filesystem on a SCSI hard drive, nothing
unusual. But check this:

chindi:/tmp/manyfiles$ time ls
(snip list of file)
real 7m37.655s
user 0m2.640s
sys 6m20.450s

Ouch! That's /slow/. Let's see why it's slow:

chindi:/tmp/manyfiles$ strace -c ls
(snip)
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
85.15 0.321233 50 6400 write
13.65 0.051490 107 482 getdents
0.44 0.001653 8 217 brk
(snip)
------ ----------- ----------- --------- --------- ----------------
100.00 0.377256 7380 2 total

0.4 SECONDS?! Something is obviously very different here, but
what? Amusingly enough, the strace manpage says "A traced process runs
slowly"...

JDW

--
If mail to me bounces, try removing the "+STRING" part.

by **Jeremiah DeWitt Weine** » Thu, 05 Jul 2001 02:20:09

> And what about
> ~$ time ls > /dev/null?

chindi:/tmp/manyfiles$ time ls > /dev/null
real 7m13.061s
user 0m1.640s
sys 6m16.530s

Same thing, pretty much...I suspect that the 'getdents' is what's
really taking up all the time, but I can't be sure.

(snip ReiserFS - ext2fs comparison)

Quote:> Although it didn't took as long as with you, I think we may
> describe it to the performance of ext2...

Interesting - I'll have to try it out with XFS, which I've got
compiled into my kernel at home:
sadalsuud:~$ uname -r
2.4.5-xfs
We'll have a little filesystem shootout. :-) I had heard that ext2
doesn't scale well to large numbers of files, and here we see how true it
is. Incidentally, I also tried it at home, where I have kernel 2.4.5 as
opposed to the 2.2.13 I have at work, and the results were pretty similar
(not surprisingly).

I'm still really curious about the strace/no-strace difference,
though...I never would have expected that, and I can't explain it.

Quote:> PS Creating those 65000 empty files takes a long time - I think
> about 15-25 minutes - I forgot to ran `time' :(

Yeah, same (time) here.

--
If mail to me bounces, try removing the "+STRING" part.

by **Robert Nicho** » Thu, 05 Jul 2001 13:11:55

:
: OK, riddle me this...
:
: I have a directory with 64,000 files in it. They're all zero-
:length regular files in an ext2 filesystem on a SCSI hard drive, nothing
:unusual. But check this:
:
:chindi:/tmp/manyfiles$ time ls
:(snip list of file)
:real 7m37.655s
:user 0m2.640s
:sys 6m20.450s
:
: Ouch! That's /slow/. Let's see why it's slow:
:
:chindi:/tmp/manyfiles$ strace -c ls
:(snip)
:% time seconds usecs/call calls errors syscall
:------ ----------- ----------- --------- --------- ----------------
: 85.15 0.321233 50 6400 write
: 13.65 0.051490 107 482 getdents
: 0.44 0.001653 8 217 brk
:(snip)
:------ ----------- ----------- --------- --------- ----------------
:100.00 0.377256 7380 2 total
:
: 0.4 SECONDS?! Something is obviously very different here, but
:what? Amusingly enough, the strace manpage says "A traced process runs
:slowly"...

If your machine has sufficient memory the directory blocks and inodes
will still be cached in memory and won't have to be read from disk
again. Try the commands in the other order to see if that's what is
happening.

--

by **Jeremiah DeWitt Weine** » Sat, 07 Jul 2001 03:43:33

> If your machine has sufficient memory the directory blocks and inodes
> will still be cached in memory and won't have to be read from disk
> again. Try the commands in the other order to see if that's what is
> happening.

Nope, order doesn't matter. I can run 'ls' over and over again and
it's still pretty slow every time. 'strace ls' is fast every time, even if
it's the first thing I run after rebooting (thus ensuring nothing is cached).

--
If mail to me bounces, try removing the "+STRING" part.

by **cbbro..** » Sat, 07 Jul 2001 03:54:30

> > If your machine has sufficient memory the directory blocks and inodes
> > will still be cached in memory and won't have to be read from disk
> > again. Try the commands in the other order to see if that's what is
> > happening.

> Nope, order doesn't matter. I can run 'ls' over and over again and
> it's still pretty slow every time. 'strace ls' is fast every time, even if
> it's the first thing I run after rebooting (thus ensuring nothing is cached).

Check to see if there's an alias for "ls".

It could be that when you run it as "ls", it's invoking an alias that
is sorting the files into lexicographic order, whilst when you run it
as "strace ls", that runs a different binary, perhaps with the -f
option, so that they differ due to not running a sort.

Just a wild guess...
--

http://www.ntlug.org/~cbbrowne/advocacy.html
HAKMEM ITEM 163 (Sussman):
To exchange two variables in LISP without using a third variable:
(SETQ X (PROG2 0 Y (SETQ Y X)))

by **Lack Mr G** » Thu, 05 Jul 2001 03:35:31

One possibility is that you have an alias set for ls. Perhaps for
something like "ls -F". This would require it to stat evry entry to
determine what it is.

strace would just run ls without lookign at the alias.

--

This message *may* reflect my personal opinion. It is *not* intended
to reflect those of my employer, or anyone else.

by **Jeremiah DeWitt Weine** » Sun, 08 Jul 2001 00:23:20

>>Check to see if there's an alias for "ls".

>>It could be that when you run it as "ls", it's invoking an alias that
>>is sorting the files into lexicographic order, whilst when you run it
>>as "strace ls", that runs a different binary, perhaps with the -f
>>option, so that they differ due to not running a sort.

>>Just a wild guess...
> Or even more, maybe the alias includes some option which requires ls to
> stat() each file. For example, ls -F, which needs to see what's a directory
> and what has executable rights; but the output would look the same if you
> have no subdirectories or executable files. That kind of think would really
> slow it down, compared to sorting which should be relatively fast.

Aha! Thank you, you guys were absolutely correct. :-)

chindi:/tmp/manyfiles$ type ls
ls is aliased to `/bin/ls $LS_OPTIONS'
chindi:/tmp/manyfiles$ echo $LS_OPTIONS
--color=auto -F -b -T 0

'time /bin/ls' is under 3 seconds, just as it should be.

JDW

--
If mail to me bounces, try removing the "+STRING" part.

Very Computer

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?

64k files in dir - 'ls' slow but 'strace ls' fast?