Bug#517122: libc6: very slow access/open/... syscalls on NFS mounted files
reassign 517122 linux-2.6
retitle 517122 linux-2.6: very slow access/open/... syscalls on NFS mounted files
thanks
On Wed, Feb 25, 2009 at 02:06:55PM -0500, Yaroslav Halchenko wrote:
> Package: libc6
> Version: 2.7-18
> Severity: normal
>
>
> I am sorry if I should have originally filed it against kernel but I am not
> sure if it is actually an NFS client issue.. It seems to be not nfs server
> issue either since other clients of the same server perform fine. It shouldn't
> be issue bonded interface on this box, since other nodes in the cluster with
> bonded interfaces perform fine.
>
> 2 days ago I upgraded our cluster from etch to lenny.
>
> Yesterday I've mentioned (it could be that it wasn't that slow before) that it
> takes too long to start bash/zsh. strace showed that syscalls dealing with NFS
> mounted files:
>
> 13:10:46.301746 access("/home/yoh/.zsh/sourcedir", F_OK) = 0 <0.019635>
>
> whenever on other nodes it takes just 0.0001 or so
This time is the time the userland (ie libc6) waits before getting an
answer.
> I've done obvious checks of nfsstat and netstat -- no obvious reasons for
> slow-down.
>
> Here is an excerpt from my notes in tiddlywiki. I would appreciate any hints on
> what else to look at, since nfs client traffic seems to be going quite fast,
> but there is significant delays between transactions, which probably what boils
> down to slow syscalls.
>
>
> examples from main node
> {{{
> strace -fF -o /tmp/zsh2.strace -T -ttt zsh-beta
>
> 1235583796.011574 access("/home/yoh/.zshenv", F_OK) = 0 <0.023661>
> 1235583796.035416 munmap(0x7fd834c96000, 2100856) = 0 <0.000053>
> 1235583796.035562 stat("/home/yoh/.zshenv.zwc", 0x7fff3e262f00) = -1 ENOENT (No such file or directory) <0.009246>
> }}}
The time of the next syscall is roughly equals to the time of the
current syscall plus the time spend in the syscall. This shows thats
all the waiting time is spend in the kernel, not in libc6.
This is definitely a kernel issue, not a glibc one. Reassigning the bug.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: