find / command hang

[jasonK_1]

I just got a new server, rp3410 (HPUX 11.31). Sometime when I run whereis command, it hangs so I open another session to run a "find " command. It's also hangs, runs, then hang, then runs... until it finished. Then I open another session to run top and it also hangs. Then all of suddenly the three commands return. The system is under zero load. Disks are not bad because I did a dd test on them. The system doesn't have any NFS.

[Adam Winebaugh]

Performing a 'find' from the root directory ('/') is brutal. You should attempt to divide-and-conquer. If you know, for instance that what you are looking for resides in '/usr' or '/opt' you could do:

# find /usr /opt -type f -name ...

If you believe that what you want is in the root filesystem and *don't* want to visit mountpoints, do:

# find / -xdev -type f -name ...

[Steven Schweda]

Where are you sitting when you do all this?

> [...] I open another session [...]

Session? How? From what?

How much network hardware is between you and
the new server? (And how much of it works
properly?)

[jasonK_1]

Steven,

I am one switch away from this server. Another session means ssh. A couple days ago, I actually connected the network cable directly from the server (gigabit lan0) to my laptop (also gigabit) and the find command still hanged.

[john D_3]

Is this server has NFS filesystems. Sometime because of NFS filesystems, some basic commands hang. when commands hang pls. check NFS filesystems status.

[Tim Nelson]

This is just a shot in the dark but anytime I hear idle system performance issues I ask...

What is your file buffer cache set to ? The default ?

kctune|grep filecache_max

A good number is around 500-600MB not 50% of physical RAM.

[jasonK_1]

Tim,

That seems to solve the problem. I am quite happy but not celebrating cause I need to make sure the problem actually go away. I'll assign point when I close this thread.

Thanks,
Jason

[Tim Nelson · Accepted solution]

Sweet !!

That darn default buffer cache setting has been at 50% of RAM and causing problems since HPUX 10.20 was released.

Maybe some day. I would have thunk that when the HPUX gods changed the name of the kernel parameter that they would have gotten rid of that "stupid" ( yes I said it ) default of 50%.

Think of it this way. Let me queue up 1GB, 2GB 10GB of data in RAM then force the flush to disk a couple seconds later.

Unless you are using the server for some static file intensive processing. Keep it low (based on situation). Buffer caches were to be a benefit not a hinderance. ( I also experienced this in Windows and MAC world, IE, Safari, Firefox ) with increasing physical RAM sizes buffering and managing itself has become self defeating.

[jasonK_1]

Hi,

Reducing the filecache_max to a lower number solves the problem

Thanks everyone
Jason