High load vs. dbc_max_pct

[Timo J]

System: RP2470 with 1GB Memory
OS: HP-UX 11.00

dbc_min_pct: 5
dbc_max_pct: 50

We're getting weird crashes on our own application on that above-mentioned system.
That application is not so CPU-intensive (usually <10% of %WCPU) nor I/O-intensive.

System loads are somewhere between 3-4 but still eg. 'sar' shows that CPU is idling almost 100%. There isn't so much device swapping (see attachment).

Has that high load something to do with the default dbc_max_pct value? (Yes, i've read about that the default value is way too high). So where is the possible bottleneck on this system? Attachment also contains output of 'top'

[Sridhar Bhaskarla]

Hi,

High load doesn't have to do anything with your dbc_max_pct. While dbc_max_pct is at high value, it may not be the case for your system crashes. It can cause unnecessary memory pressure but lacking free memory wouldn't result in crashes on HP systems.

There is little device swapping which means either it is due to your memory mapped files or the system is low on memory itself. Looks like you have less free memory on the system.

I suggest you perform Q4 analysis on the crashdump and provide HP with the results. It may be a hardware failure.

-Sri

[Timo J]

It's not the kernel that's crashes but our own application, which runs ok on other system configurations.

[Steve Lewis]

HP-UX 11.00 gives equal priority to buffers as it does to processes when it encounters memory pressure. So if your dbc_max_pct is too high, you can end up with a maximum-sized buffer cache thats hardly used, but a whole bunch of process pages swapped out. 11.00 is a bit like Windows in that respect.

This can cause a high load, because the processes have to wait for pages to be brought back in, increasing the run queue. By the way, I don't think that 4 is particularly high. >6 may raise a flag depending on how many cpus you have.

To monitor this, use vmstat -S 5 20

Note that this is not the only cause of a high load. The other one is simply having a lot of concurrent processes running that are not doing much or are waiting for resource.

The solutions to this are:
1. Decrease dbc_max_pct to 20 (in your case with 1Gb of RAM).
2. Upgrade to HP-UX 11i.

HP-UX 11i does not have this silly pageout strategy.

[Fred Ruffet]

1GB of RAM and dbc_max_pct of 50 means that your IO cache will grow with some IO to 500MB. If your system+apps are already using more, your system will start to swap, and vhand process will use a huge percentage of your CPU.

Depending on the IOs you have on your system, even 20 percent of 1GB may be big. You can start with a lower value (maybe 5 or 10%), and increase if IOs are two slow (system spending too much time on IOs)

Regards,

Fred