Delay when executing commands

[idainfront]

I've got a HP-UX 11.11 machine.

Whenever some of the users runs commands on it it delays the execution of said command for like 5 seconds. Any subsequent executions within reasonable amounts of time are executed normally.

Logged in as root I don't have the exact same problem, but I do get the same delay whenever I misspell a command, the "command: not found" dialog will take quite a few seconds to appear instead of doing so immediately.

What might be wrong? I figured it might have something to do with the path, but I tried doing du -s on every path in the $PATH and there was no delay what so ever.

[R.O.]

Do you have some slow NFS paths in $PATH?

Regards,

[John Guster]

a couple of things may cause this:
1. check if there is any hung NFS mount, kill it if there is
2. if "find" command is still running
3. if there are many small files, but many many of them, "ls" will let you feel delay, it this is true, one mya want reorganize the file system through fsadm.

[Pete Randall]

When you experience the delays, run "vmstat 1 5" and take a look at the "po" column. A number greater than single digit i the po column indicates a fairly significant amount of page-outs so your command is waiting to be paged in to memory but, once there, can be re-executed quickly.


Pete

[singh sanjeev]

check eventlog for any disk failure message ..may be vg00 disk.

[Bill Hassell · Accepted solution]

Long delays like this almost always indicate a networking problem.

> Logged in as root I don't have the exact same problem, but I do get the same delay whenever I misspell a command, the "command: not found" dialog will take quite a few seconds to appear instead of doing so immediately.

That pretty well identifies the problem. You very likely have one or more NFS mountpoints in $PATH -- not a good idea at all. As you have seen, this is causing a problem for everyone including root. The reason root is fast is that the NFS mounts are at the end of root's $PATH, while the users have probably customized their .profile to push the NFS paths to the front of the $PATH list.

When an NFS server fails or runs very slowly, it will affect every computer and every user that has these paths in their $PATH. That's why you never want NFS mounts in $PATH. It is far more reliable to use aliases for the few commands that are found on NFS servers. If the NFS server is broken, it will not affect local operations.

[idainfront]

Thank you all for very good answers!

Seems the users paths are pointing into their homes and said homes are automounted over nfs.

To keep on asking for help though, what might have screwed up the performance on the automounts? These path-settings are old, but the problem is new, suddenly the NFS-mounts are just alot slower than they used to be.

The NFS-server is also HP-UC 11.11.

[Hakki Aydin Ucar]

You can also use time/timex command to measure;check the man page of timex:
timex - time a command; report process data and system activity . . .

# timex

[Bill Hassell]

> To keep on asking for help though, what might have screwed up the performance on the automounts? These path-settings are old, but the problem is new, suddenly the NFS-mounts are just a lot slower than they used to be.

You need to troubleshoot each NFS server to find the slow one(s). Was the server recently patched? Is the server running in half-duplex on the network? Does the server have DNS delays? I am assuming that most of the NFS servers are OK and only certain servers are causing the delays.

I would probably look at changing /etc/PATH to never include NFS mounts. To do so can cripple the system when network or NFS server issues occur. Never allow root to have an NFS mount in $PATH. You don't want problems on other machines to cripple the ability to administer the local machine.