Suddenly slow lstat syscalls on CURRENT from Juli
Kostik Belousov
kostikbel at gmail.com
Sat Jan 1 15:45:46 UTC 2011
On Sat, Jan 01, 2011 at 04:37:44PM +0100, Beat G?tzi wrote:
> On 01.01.2011 16:10, Alexander Best wrote:
> > On Sat Jan 1 11, Beat G?tzi wrote:
> >> Hi,
> >>
> >> Since a couple of days commands like ls(1) are very slow on one of my
> >> tinderboxes. Checking with ktrace/kdump I see that the lstat syscall
> >> takes about one second:
> >>
> >> 70559 ls 0.004644 CALL lstat(0x284472f8,0x28447298)
> >> 70559 ls 0.004651 NAMI "Mk"
> >> 70559 ls 0.004664 STRU struct stat {... }
> >> 70559 ls 0.004672 RET lstat 0
> >> 70559 ls 0.004688 CALL lstat(0x2844a1b8,0x2844a158)
> >> 70559 ls 0.004696 NAMI "README,v"
> >> 70559 ls 1.004245 STRU struct stat {...}
> >> 70559 ls 1.004263 RET lstat 0
> >> 70559 ls 1.004277 CALL lstat(0x2844a2b8,0x2844a258)
> >> 70559 ls 1.004286 NAMI ".cvsignore,v"
> >> 70559 ls 2.004282 STRU struct stat {...}
> >> 70559 ls 2.004302 RET lstat 0
> >> 70559 ls 2.004316 CALL lstat(0x2844a3b8,0x2844a358)
> >> 70559 ls 2.004325 NAMI "CHANGES,v"
> >> 70559 ls 3.004275 STRU struct stat {...}
> >> 70559 ls 3.004296 RET lstat 0
> >> 70559 ls 3.004310 CALL lstat(0x2844a4b8,0x2844a458)
> >> 70559 ls 3.004318 NAMI "COPYRIGHT,v"
> >> 70559 ls 4.004300 STRU struct stat {...}
> >> 70559 ls 4.004318 RET lstat 0
> >>
> >> When i immediately re-execute the command in the same directory it looks
> >> normal:
> >>
> >> 78007 ls 0.004665 CALL lstat(0x284472f8,0x28447298)
> >> 78007 ls 0.004673 NAMI "Mk"
> >> 78007 ls 0.004686 STRU struct stat {...}
> >> 78007 ls 0.004693 RET lstat 0
> >> 78007 ls 0.004708 CALL lstat(0x2844a1b8,0x2844a158)
> >> 78007 ls 0.004715 NAMI "README,v"
> >> 78007 ls 0.004728 STRU struct stat {...}
> >> 78007 ls 0.004735 RET lstat 0
> >> 78007 ls 0.004742 CALL lstat(0x2844a2b8,0x2844a258)
> >> 78007 ls 0.004749 NAMI ".cvsignore,v"
> >> 78007 ls 0.004761 STRU struct stat {...}
> >> 78007 ls 0.004768 RET lstat 0
> >> 78007 ls 0.004775 CALL lstat(0x2844a3b8,0x2844a358)
> >> 78007 ls 0.004782 NAMI "CHANGES,v"
> >> 78007 ls 0.004795 STRU struct stat {...}
> >> 78007 ls 0.004802 RET lstat 0
> >> 78007 ls 0.004809 CALL lstat(0x2844a4b8,0x2844a458)
> >> 78007 ls 0.004817 NAMI "COPYRIGHT,v"
> >> 78007 ls 0.004828 STRU struct stat {...}
> >> 78007 ls 0.004835 RET lstat 0
> >>
> >> System is a HP DL360 G3 with a Compaq Smart Array 5i controller. There
> >> is no evidence of a RAID controller or hard disk problem in the system
> >> logs. Also writing to a file and reading from a file looks normal.
> >> The running kernel is a GENERIC kernel from Juli without debugging options:
> >>
> >> # uname -a
> >> FreeBSD tinderbox.chruetertee.ch 9.0-CURRENT FreeBSD 9.0-CURRENT #5
> >> r209980: Tue Jul 13 11:25:50 CEST 2010
> >> root at tinderbox.chruetertee.ch:/usr/obj/usr/home/beat/dev/src/head/sys/BEASTIE
> >> i386
> >
> > no problems here.
>
> I haven't had this problem the first ~166 days since I rebooted the box
> the last time. Then the problem suddenly occur in all directories on all
> partitions. The box was pretty much under load all the time as it builds
> packages almost 7x24. I forgot to say the used filesystem is UFS.
>
> # diskinfo -ct da0
> da0
> 512 # sectorsize
> 299992412160 # mediasize in bytes (279G)
> 585922680 # mediasize in sectors
> 0 # stripesize
> 0 # stripeoffset
> 36472 # Cylinders according to firmware.
> 255 # Heads according to firmware.
> 63 # Sectors according to firmware.
> # Disk ident.
>
> I/O command overhead:
> time to read 10MB block 0.333161 sec = 0.016 msec/sector
> time to read 20480 sectors 3.392359 sec = 0.166 msec/sector
> calculated command overhead = 0.149 msec/sector
>
> Seek times:
> Full stroke: 250 iter in 1.202862 sec = 4.811 msec
> Half stroke: 250 iter in 1.120656 sec = 4.483 msec
> Quarter stroke: 500 iter in 2.109077 sec = 4.218 msec
> Short forward: 400 iter in 1.892342 sec = 4.731 msec
> Short backward: 400 iter in 1.399378 sec = 3.498 msec
> Seq outer: 2048 iter in 0.399352 sec = 0.195 msec
> Seq inner: 2048 iter in 0.385460 sec = 0.188 msec
> Transfer rates:
> outside: 102400 kbytes in 2.325967 sec = 44025 kbytes/sec
> middle: 102400 kbytes in 2.157681 sec = 47458 kbytes/sec
> inside: 102400 kbytes in 2.717089 sec = 37687 kbytes/sec
>
> I also observed that the cpu output of vmstat is a little bit confusing
> on this system:
>
> # vmstat
> procs memory page disk faults cpu
> r b w avm fre flt re pi po fr sr da0 in sy cs us sy id
> 0 0 0 1663M 1120M 117 0 1 0 120 21 0 172 27 245 -29 -10 139
>
Check the output of sysctl kern.maxvnodes and vfs.numvnodes. I suspect
they are quite close or equial. If yes, consider increasing maxvnodes.
Another workaround, if you have huge nested directories hierarhy, is
to set vfs.vlru_allow_cache_src to 1.
You did not specified how much memory your machine have, but I assume it
is > 1GB. Anyway, increase of maxvnodes on i386 should be done very
cautiously, since it is easy to exhaust KVA.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20110101/fe72994f/attachment.pgp
More information about the freebsd-current
mailing list