Hi,
We recently upgraded our nfs server to SXCE b56. Since then, we've had a few
occasions when nfsd stops responding, and can't even be kill -9'd. We can't
even reboot the server with reboot -q, it has to be power cycled. truss and
dtrace report "no such process" when attatching (although I haven
James;
If things stop. Please run this following command as root.
echo "::pgrep nfsd | ::walk thread | ::findstack -v" | mdb -k
This will show us what the NFS threads are upto..
Robert.
On Feb 26, 2007, at 9:35 PM, James Andrewartha wrote:
> Hi,
>
> We recently upgraded our nfs server to SXC
James Andrewartha wrote:
> We recently upgraded our nfs server to SXCE b56. Since then, we've had a few
> occasions when nfsd stops responding, and can't even be kill -9'd. We can't
> even reboot the server with reboot -q, it has to be power cycled. truss and
> dtrace report "no such process" when
Robert Gordon wrote:
>
> James;
>
> If things stop. Please run this following command as root.
>
> echo "::pgrep nfsd | ::walk thread | ::findstack -v" | mdb -k
>
> This will show us what the NFS threads are upto..
stack pointer for thread 3000203b620: 2a1014a9051
[ 02a1014a9051 cv_wait_si
Check
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6513020
it might be related. I see that the workaround of that bug is to free up space.
-r
On Feb 27, 2007, at 2:02 AM, Roch - PAE wrote:
>
> Check
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6513020
>
> it might be related. I see that the workaround of that bug is to
> free up space.
>
You're correct that freeing up space helps, though it only helps
*before
Hello, gurus
I need your help. During the benchmark test of NFS-shared ZFS file systems at
some moment the number of NFS threads jumps to the maximal value, 1027
(NFSD_SERVERS was set to 1024). The latency also grows and the number of IOPS
is going down.
I've collected the output of
echo "::pgre
