#60 NFS Performace issue

[Anonymous]

Hi,

In order to simplify things i will first describe the items:

fileserver - does only nfs sharing under 2.6.7[realhost]
host-01 - contains all the uml hosts 2.6.8.1[realhost]
uml-01 - first uml instance under 2.4.25 [uml]
uml-02 - second uml instance under 2.6.8.1 [uml]

NFS mounts from 'realhost' systems, thus no uml, have
normal transfer rates over NFS, no timeouts reported. All
OK. TCP and UDP traffic also OK.

It seems thus that NFS over normal systems works fine.

uml-02 [kernel v2.6 uml] can mount the nfs filesystems
and access the files, though when one starts doing
heavy activity i.e. copy action on the filesystem it
causes the 'standard' warnings on console:

"nfs: server 192.168.0.36 OK
nfs: server 192.168.0.36 not responding, still trying
nfs: server 192.168.0.36 not responding, still trying
nfs: server 192.168.0.36 OK
nfs: server 192.168.0.36 OK
nfs: server 192.168.0.36 OK
nfs: server 192.168.0.36 not responding, still trying
nfs: server 192.168.0.36 OK"

uml-01 [kernel v2.4 uml] does not give these errors, but
will have eventually the same effect on the system:
lousy performance and stutters. No log or other errors
seen.

I have looked for any other errors/warnings or issues
inside the uml's. But all other uml systems running ldap
or mysql can fill up the bandwidith without issues....

I have been running uml for some time now on various
systems and havent had any major issues till i hit my
head against this one.

The really major changes done is that i was forced to
upgrade to v2.6 uml hosts due to ipvs and therefore also
upgraded the realhosts to v2.6.8.1.

The other upgrade done is to fileserver that is now
running v2.6.7 instead of v2.4.20.

Havent had this issue before.... Be nice to be able to do
normal nfs transfers in the umls :)

Attached a sample build script for the uml hosts.

[Nobody/Anonymous]

UML host build file example

[Nobody/Anonymous]

Logged In: NO

Hi,

Did some more digging today and found out that the action
happens due to the fact that nfs copy actions now use a
larger amount of memory forcing swapping to take place and
kswapd to eat cpu and resources.

Could this be related to not including the /dev/anon patch in
relation to previous 2.4 kernels?