From: J G Miller on
On Mon, 12 Jul 2010 10:44:18 -0500, Ignoramus15939 wrote:
>
> 50%

That should be fine then.

> I think not, not that I could find, but I will look.

Something else to consider -- is the exported file system the
only file system on that disk, or does it share with another
filesystem which may be busy and thus causing contention on
that disk?

> top - 10:42:41 up 484 days

No kernel updates in over a year? ;)

> root 10 -5 0 0 0 S 0 0.0 96:37.46 kswapd0 206

Anything of concern here? Maybe not in view of the long up time.

> All fstab lines say 'nfs', it may be nfsv4.

If it is nfs then it will be v3. You can also do a

showmount -e hostname

and look at what is being exported.

If it is nfsv4 then you will see in /etc/exports the options
including fsid=0, with directories grouped under the mount
points for each fsid.

As it is appears to be nfs v3, did you check for statd?

> Yes, that's the plan for later today, restart nfs daemon on A
> and see if it helps.

<speculative mode>

In view of the long time that the system has been up and perhaps the
NFS daemons running, it may just be some old mount has got stuck and
is degrading performance.
From: Ignoramus20495 on
On 2010-07-12, J G Miller <miller(a)yoyo.ORG> wrote:
> On Mon, 12 Jul 2010 10:44:18 -0500, Ignoramus15939 wrote:
>>
>> 50%
>
> That should be fine then.
>
>> I think not, not that I could find, but I will look.
>
> Something else to consider -- is the exported file system the
> only file system on that disk, or does it share with another
> filesystem which may be busy and thus causing contention on
> that disk?

It does share, but with a very low volume drive.

>> top - 10:42:41 up 484 days
>
> No kernel updates in over a year? ;)

That machine runs Debian Etch (clients are Ubuntu). It is not exactly
the first freshness.

>> root 10 -5 0 0 0 S 0 0.0 96:37.46 kswapd0 206
>
> Anything of concern here? Maybe not in view of the long up time.
>
>> All fstab lines say 'nfs', it may be nfsv4.
>
> If it is nfs then it will be v3. You can also do a
>
> showmount -e hostname
>
> and look at what is being exported.
>
> If it is nfsv4 then you will see in /etc/exports the options
> including fsid=0, with directories grouped under the mount
> points for each fsid.
>
> As it is appears to be nfs v3, did you check for statd?

Yes, statd is running.

>> Yes, that's the plan for later today, restart nfs daemon on A
>> and see if it helps.


><speculative mode>
>
> In view of the long time that the system has been up and perhaps the
> NFS daemons running, it may just be some old mount has got stuck and
> is degrading performance.

I have a feeling that the path to the answer lies in finding out, just
WHY nfsd processes are so often in uninterruptible sleep like this:

:/proc/3005# top -b -n 1|grep ' D '
2884 root 10 -5 0 0 0 D 2 0.0 819:02.36 kjournald
3002 root 15 0 0 0 0 D 2 0.0 1306:26 nfsd
3001 root 15 0 0 0 0 D 0 0.0 1300:14 nfsd

I have a feeling that something is slow with drbd and that, and not
NFS software, causes this slowness.

i
From: Greg Russell on
In news:8a1928Fu2aU2(a)mid.individual.net,
General Schvantzkoph <schvantzkoph(a)yahoo.com> typed:

> Have you done a reboot yet?

<sigh>

# /etc/init.d/{nfs,portmap} restart

Individually, of course (or your distro-cpecific location) ... reboots are
for $lusers.




From: Ignoramus20495 on
On 2010-07-12, Greg Russell <grussell(a)example.con> wrote:
> In news:8a1928Fu2aU2(a)mid.individual.net,
> General Schvantzkoph <schvantzkoph(a)yahoo.com> typed:
>
>> Have you done a reboot yet?
>
><sigh>
>
> # /etc/init.d/{nfs,portmap} restart
>
> Individually, of course (or your distro-cpecific location) ... reboots are
> for $lusers.
>

My expectation is that the problem is not with nfsd, but with drbd
(because nfsd spends so much time in uninterruptible sleep writing to
drbd).

I will give it a try and restart nfs after hours, but I am far from
certain that it will help.

i


From: Ignoramus20495 on
An update, as I was afraid, restart ing nfsd did not help.

i