system performance

[AUJ]

I have a D class server with 1 GB memory. When I run a command "find", the machine uptime goes high, it reach for about 40. This only started when I upgrade the system to HP-UX 11. I think this should be handled by kernel parameters. Can you help me on this?

[Steven Sim Kok Leong]

Hi,

Do you run additional pipes or -exec's into your find?

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Magdi KAMAL]

Hi Angelo,

How much swap do you have on your system ?
You need to have at least 2GB since you have 1GB memory.

Magdi

[AUJ]

The swap is size is 2 GB.

[Sridhar Bhaskarla]

Hi,

I can think of few things regarding the uptime and the find command.

1. Run the find command in each file system and see how the uptime is looking like. This will tell you if you have problems with any particular disk/file system.
2. Make sure you don't have bad disks or disks that have bad response times. While doing the find, take another window and run sar -d 2 100 and see the disk utilization particularly the last column avserv (average time to process the request)
3. Make sure if you don't NFS related problems on the server. Make sure your bdf doesn't hang.
4. I don't expect kernel parameters to be culprit in this case. "sar -v 2 200" will give you some of the kernel parameter utilizations.
5. Make sure you have resonably latest patches installed on the system.

-Sri

[AUJ]

Hi Sri,

I don't think this is a disk related problem because when the system is still in HP-UX 10.20, we haven't encounter this problem and only after the upgrade to HP-UX 11, this problem arised. And also, we already installed all patches needed. That's why I'm thinking of Kernel Related problem, but don't know which of the kernel parameters, do I need to check or update.

Thanks.
Angelo

[Steven Sim Kok Leong]

Hi,

Verify the checksum, if not, then the size of your find command. It is always possible that a malicious attacker could have compromised your "find" binary to run trojan code in the background while legitimately performing the find in the foreground.

Check out its attributes:

# file `which find`
# what `which find`
# ll `which find`

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Mark Greene_1]

Do you see this behavior for every "find", or just when using exec or other specific options?

In addition to verifying the integrity of the find binary, run the same check on uptime as well (which uptime)

Also, in another telnet window run a vmstat, use something like "vmstat -S 1 1000" and then run a find at the root directory to look for a file that does not exist (e.g. "find / -name "does_not_exist" -print") and watch the vmstat output. Notice how quickly or slowly the find process climbs to the top of the process list, and what other system processes start consuming cpu, or not. The -S option on the vmstat will report swap stats.

HTH
mark

[AUJ]

Thanks for you time GUYS!