NFS file system really slow on ICSAM file

[tom quach_1]

Dear all:

I ran cobol program connect to oracle 9i to generate ICSAM file.
if the output was on local file system, it only took 2 mins, but if the output was on NFS file system, it could take 1 hr and it happens very consistent throu all my servers.
i am using HPUX 11.11
Please help

Regards,
Tom

[Uday_S_Ankolekar]

I would check the speed settings on your Lan card and network switches.

-USA..

[Steven E. Protter]

Shalom tom,

Checklist:

NFS on the back end is version 3 or above.

NFS server back end is configured for good write performance.

lanscan

lanadmin -x 0

Change zero to correspond to the actual lan number in lanscan that connects to the network with the nfs server.

You should be at least 100 Base T full duplex depending on your LAN card.

You need to make sure your lan switch port settings are consistent with your card. Manual configuration for 100 BaseT autonegotiate for 1000 BaseT and faster.

SEP

[tom quach_1]

Hello:
thanks for the replies
forgot to mention that the local and NFS file systems reside on the same server.
I did check the NIC setting and it was 100Mb
Full duplex.
it only happens to CISAM files not regular files.

Regards,
Tom

[A. Clay Stephenson]

NFS being 30X slower than local files does not sound too surprising especially with random i/o. You should run nfsstat to gather data and identify the bottlenecks. Because of the large amount of random i/o that is done in building indices, you would probably find it faster to build the files locally and then copy them via NFS. You could also try increasing the number of NFS daemons and playing with the rsize=, and wsize= NFS mount options.

[tom quach_1]

Hello:

Thanks for the advice!
Below is a list of nfsstat.
Would someone please give me some advice on this output.

Regards,
Tom

#nfsstat

Server rpc:
Connection oriented:
calls badcalls nullrecv
3809440 0 0
badlen xdrcall dupchecks
0 0 1268949
dupreqs
0
Connectionless oriented:
calls badcalls nullrecv
4171 0 0
badlen xdrcall dupchecks
0 0 0
dupreqs
0

Server nfs:
calls badcalls
3813603 0
Version 2: (4173 calls)
null getattr setattr
4173 100% 0 0% 0 0%
root lookup readlink
0 0% 0 0% 0 0%
read wrcache write
0 0% 0 0% 0 0%
create remove rename
0 0% 0 0% 0 0%
link symlink mkdir
0 0% 0 0% 0 0%
rmdir readdir statfs
0 0% 0 0% 0 0%
Version 3: (3809430 calls)
null getattr setattr
14 0% 99 0% 19 0%
lookup access readlink
158 0% 24 0% 0 0%
read write create
2540132 66% 1268926 33% 0 0%
mkdir symlink mknod
2 0% 0 0% 0 0%
remove rmdir rename
0 0% 2 0% 0 0%
link readdir readdir+
0 0% 2 0% 14 0%
fsstat fsinfo pathconf
36 0% 2 0% 0 0%
commit
0 0%

Client rpc:
Connection oriented:
calls badcalls badxids
3857637 29 4
timeouts newcreds badverfs
9 0 0
timers cantconn nomem
0 13 0
interrupts
7
Connectionless oriented:
calls badcalls retrans
1520 0 0
badxids timeouts waits
0 0 0
newcreds badverfs timers
0 0 5
toobig nomem cantsend
0 0 0
bufulocks
0

Client nfs:
calls badcalls clgets
3859131 29 3859131
cltoomany
1
Version 2: (1494 calls)
null getattr setattr
0 0% 1493 99% 0 0%
root lookup readlink
0 0% 0 0% 0 0%
read wrcache write
0 0% 0 0% 0 0%
create remove rename
0 0% 0 0% 0 0%
link symlink mkdir
0 0% 0 0% 0 0%
rmdir readdir statfs
0 0% 0 0% 1 0%
Version 3: (3857637 calls)
null getattr setattr
0 0% 1651 0% 98 0%
lookup access readlink
27356 0% 2538 0% 0 0%
read write create
2546416 66% 1276933 33% 5 0%
mkdir symlink mknod
1 0% 0 0% 0 0%
remove rmdir rename
2 0% 1 0% 0 0%
link readdir readdir+
0 0% 0 0% 2268 0%
fsstat fsinfo pathconf
309 0% 6 0% 2 0%
commit
51 0%

[Mark Ellzey]

Tom,

Check your switch port for a duplex mismatch. If the port setting doesn't agree with the NIC settings, this will cause exactly the problem you are experiencing.

Regards,
Mark