Correlation between Psudo-swap and Buffer-cache

[Jerry Zhang]

Once both Psudo-swapping and dynamic buffering are turned on, I see a large amount of memory are used for "swap" and "buffer-cache". The sum of them is over the installed physical memory. For example, I have 1GB of physical memory. But see over 700MB of psudo swap and 450MB of buffer-cache are used. How?

[Byron Myers · Accepted solution]

Default HP buffer cache will allow 50% of RAM. Use kernal parms dcb_max_pct and dcb_min_pct to tune these. These are maximum and minumum allowable amount of RAM for buffer cache. Lower them.

For Psuedo, swap, look at the white paper located in /usr/share/doc/mem_mgt.txt. This is a rather involved topic, but for the most part, allocate device swap that is two to three times your RAM - in this case, allocate two to three GB of device swap. If you still see a large amount of pseudo swap being used, then allocate more device swap. Basically, you are running out of device swap, so HP-UX is using RAM as "pseudo-swap". Even if swapinfo shows that device swap is not being used, much of it is actually being reserved for running processes.

[Vic Parker]

Hi Jerry,

I deal with this memory/DBC issue a lot. Here's the deal, by default the kernel parameter dbc_max_pct is set to 50% which means, if your system has a lot of filesystem I/O you could use up to half of your physical memory 500MB for filesystem buffer, THAT A LOT of MEMORY. You know what happens to your users processes or the applications running on this system if they require more than the 500MB of remaining memory? They must use swap! The reason for this is that, once dynamic buffer cache has been allocated it is not quickly return if needed by the other applications for data space. In fact, in addition to your applications running slower because of the demand for memory being answered with swap, the system is running slower because it has to manage this large amount of dynamic buffer cache.

Now, with that said, you should reduce the maximum buffer cache down to a reasonable number. Whats reasonable? Well that depends on the amount of memory on your system, 10% in your case is 100MB, if you had 8GB of RAM... well you get the picture.

Reduce dbc_max_pct to a number below 10%, maybe 8 or 9. dbc_min_pct can be 4 or 5 percent. Afterwards come back and tell us how much better you system is running.

Vic

[Jerry Zhang]

By my understanding, buffer cache has a lower priority comparing to system and user (application) memory requests. That means, if sys/apps request more memory, then buffer cache will give some back - that's why it is called "dynamic buffering". I will reduce dbc_max_pct and watch how it affect the system performance.

But my real question was:
from command "swapinfo -atm", I see 700mb of psudo swap out of 1GB of physical memory. From gpm, I see 450mb of buffer cache.
What is the correlation between those two numbers: 700mb (psudo swap)and 450mb (buf cache)? or no correlation at all?

Some pages been swapped out in psudo swap, also been counted in buffer cache. Some pages are not. Why?

Thanks

[Mladen Despic]

Jerry,

I think the numbers you are seeing are all about swap reservations. When a process starts up, it must reserve swap space, either on swap device or in pseudo-swap. If there isn't enough swap space to reserve, the process won't even start.

With psuedo-swap enabled, if a process tries to start up, but there is no more swap device to reserve (this is possible even if no pages are actually swapped out), the process can still start up if there is enough pseudo-swap to RESERVE.

Pseudo-swap can only be reserved. No pages can be swapped out to pseudo-swap (swapping pages from physical memory to the same physical memory wouldn't even make sense). When a process reserves pseudo-swap, its pages are actually locked in physical memory.

Swap reservations are more or less a number game. In particular, pseudo-swap reservations are tracked by a counter, called swapmem_cnt. Effectively, a process reserves pseudo-swap by lowering this counter. Pseudo-swap reservations are exhausted if this counter is at 0.

The thing that complicates the picture is the fact that the counter swapmem_cnt can also be lowered by the operating system (for dynamically allocated memory).

In my experience, if you are running a database that locks large amounts of memory, you will see high utilization of pseudo-swap (which just means that the counter swapmem_cnt is close to 0).

I am not sure how buffer cache fits into all of this, but I wouldn't be surprised if some or all of your buffer cache is actually included in your pseudo-swap!

You may want to take a look at the section "Reservation of Pseudo-Swap Space" in the document /usr/share/doc/mem_mgt.txt on your system.

HTH

Mladen

[Vic Parker]

Jerry,

Sorry, I saw the 50% DBC and zero'ed in on that without addressing the issue of psuedo swap. To answer your original question with some background info.

Psuedo Swap and DBC has no relationship at all.

Background Info.

Pre-HP-UX 9.x a system would not use all physical memory unless there was an equal amount of swap. In other words the kernel would pre-allocate an equal amount of device/filesystem swap space to match the swappable mem regjions of a process. If you had 1GB of phys mem and 500MB of swap, the system would only use 500MB of phys mem.

With psuedo-swap the system does not allocate device or file swap, it simply tracks preallocated swap in counter. Psuedo swap is a decremented counter, so it starts of at an amount equal to: SWAP_SPACE + 3/4 PHYSICAL_MEM.
The counter is decremented an amount equal to the swappable regions of each proc running, the amount of buffer used is not taken into account at all.

One more note on DBC, it is dynamically scalable which is why it is refered to as DBC.
However, DBC is based on the intensity of I/O; if you have a lot of I/O in conjuction with you request for additional memory, DBC does on scale down immediately. Reducing the max will be a good thing for you and I don't think there is a need to be concerned about P-swap. It is a normal reservation funtion with Virt-mem.

Hope this is more helpful,

Vic