Date: Tue, 21 Mar 2006 17:09:16 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: alc@freebsd.org, stable@freebsd.org Subject: Re: more weird bugs with mmap-ing via NFS Message-ID: <200603220109.k2M19GVS007470@apollo.backplane.com> References: <200603211607.30372.mi%2Bmx@aldan.algebra.com> <200603211858.02801.mi%2Bmx@aldan.algebra.com> <200603220025.k2M0PmCt007240@apollo.backplane.com> <200603211948.28178.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:The file stops growing, but the network bandwidth remains at 20Mb/s. `Netstat
:-s' on the client, had the following to say (udp and ip only):
If the network bandwidth is still going full bore then the program is
doing something. NFS retries would not account for it. A simple
test for that would be to ^Z the program once it gets into this state
and see if the network bandwidth goes to zero.
So if we assume that packets aren't being lost, then the question
becomes: what is the program doing that is causing the network
bandwidth to go nuts? And if it isn't the program, then what is the
OS doing that is causing the network bandwidth to go nuts?
ktrace on the program would tell us if read() or write() or ftruncate()
were causing an issue.
'vmstat 1' while the program is running would tell us if VM faults
are creating an issue.
If neither of those are an issue then I would guess that the problem
could be related to the NFSv3 2-phase commit protocol. A way to test
that would be to mount with NFSv2 and see if the problem still occurs.
Running tcpdump on the network interface while the program is in this
state might also give us some valuable clues. 50 lines of output from
something like this after the program has gotten into its weird state
might give us a clue:
tcpdump -s 4096 -n -i <interface> -l port 2049
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603220109.k2M19GVS007470>