topic Re: Filesystem Swap problem in Operating System - HP-UX

Filesystem Swap problem

James Armstrong — Wed, 21 Mar 2001 13:44:23 GMT

I have a 5 Gb logiacl volume with a vxfs filesystem on it. I tried to add this entire LV as filesystem Swap through SAM but it only seems to be allocating 892Mb! Swapinfo -mat gives the following output:

Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 1024 0 1024 0% 0 - 1 /dev/vg00/lvol2
dev 4084 1019 3065 25% 0 - 0 /dev/vg00/lvol9
localfs 828 0 828 0% 2900 0 0 /temp_swap/paging
reserve - 3589 -3589
memory 1121 144 977 13%
total 7057 4752 2305 67% - 0 -

The filesystem is used entirely for swap and nothing else. We are running HP-UX 11.00 on a N4000. The reason I have to add filesystem swap and not device swap is because the disks are in a HP Autoraid 12H and device swap grinds them to a halt seemingly. Our SAP application requires this swap to be present else it won't start up properly.

Can anbody help????

Jim.

Re: Filesystem Swap problem

Thierry Poels_1 — Wed, 21 Mar 2001 14:20:15 GMT

Hi,
we are not using filesystem swap, so I just have 2 things to look at, but don't know they make sense ;)

- you might have reached the maxswapchunks kernel parameter
- filesystem swap is supposed to be dynamic, so no disk allocation if there is no (extra) swap space needed

Thierry.
don't shoot me if this is completely bogus.

Re: Filesystem Swap problem

James Armstrong — Wed, 21 Mar 2001 14:56:15 GMT

Hi,

We are nowhere near our max swap chunks kernel parameter, and although the swap space will normally be taken when needed, the -m option of 'swapon' allows you to state how much space to take from the offset.

Any other ideas???

Re: Filesystem Swap problem

John Palmer — Wed, 21 Mar 2001 15:41:41 GMT

Hi,

What arguments are you supplying to swapon for the filesystem?

As an aside, your output from swapinfo indicates that you are not using the filesystem swap and without it you would only be using 75% of the available device swap and memory. Was this prior to loading your SAP system?

I would also make the comment that if the system was actively paging from the swap space on the Autoraid then it wouldn't matter whether the swap space was filesystem or device. If the additional swap space is actually required, have you considered reverting to device swap on the Autoraid but with a higher priority?

A second observation is that you are allocating a lot of swap space considering that your server only appears to have 1.5Gb of RAM. Could it be that your real problem with the Autoraid performance is caused by excessive paging due to lack of RAM?

Regards,
John

Re: Filesystem Swap problem

James Armstrong — Thu, 22 Mar 2001 10:19:28 GMT

Hi,

I agree that we need more RAM but as this is a development box getting money spent on it is rather hard! SAP's own recommendation is that we have a minimum of 20 Gb of SWAP irrelevant of the amount of RAM we have!! I have questioned this philosphy but they are sticking by there guns. I seem to have alleviated the problem by removing the swap and then recreating it with the following command:

swapon -m 4048M -l 0M -p 2 /temp_swap

This has given me 4Gb of assisgned filesystem swap with trhe option to use the remaining space if and when needed. This seems to allow the 3 SAP instances to run together happily now (although slowly!).

Thanks for all your suggestions.

Jim.

Re: Filesystem Swap problem

Vincenzo Restuccia — Thu, 22 Mar 2001 14:40:26 GMT

lvcreate -L 5000 /dev/vg00/lvolx
edit /etc/fstab
/dev/vg00/lvolx swap ... pri 0 3

launch swapon -a, after verify with swapinfo.

Re: Filesystem Swap problem

Alexander Russell — Fri, 23 Mar 2001 17:32:30 GMT

If you have a few processes that try to use more than the available physical memory on the box, there is no substitue to physical memory.

These are some arguments to support this:

If you are not performing any disk I/O the operating system can shrink the buffer cache (down from anywhere as high as dbc_max_pct to as low as dbc_min_pct--you should not use nbuf or bufpages to fix the size, just set dbc_min_pct = dbc_max_pct), thus allowing the high memory utilisation processes to get more of their pages into memory (RSS--where the processes actual size is VSS. If RSS=VSS things are really hunky dorey! ; ).

(You are probably aware that:) The swap system needs to be able to allocate as much space on swap as all the processes' VSS (the swap space can include pseudo-swap, but if the O/S ever comes to need pseudo-swap--which it generally doesn't, the processes will be killed by the kernel!! It follows on (round about) that the amount of physical memory on the machine is NOT AN INDICATOR of how much swap you need. You MUST have as much swap (possibly including pseudo, so turn on pseudo swap in the kernel) as all the processes' VSS size (use: size /path/to/binary/binary) you want to load into memory. This is why SAP are sticking to their guns.

Your three(?) SAP processes will try to get as much of their VSS space into memory as they try to access ~quickly~. If they access data close together the vhand daemon can page out the pages not in use. If the SAP processes try to address pages all over their VSS far more pages will be brought back into main memory, thus greater memory pressure.

The problem is compounded when the SAP processes also try to do disk I/O since the filesystem requires buffer cache (which has been shrunk to accomodate the extra pages the processes are addressing). Obviously, the less buffer cache there is, the longer it will take to do disk I/O, and this memory is not available for the SAP processes.

Solution: "use less memory hogging processes, or buy more memory". This is the official line (don't quote me directly) taught on the HP-UX Tuning and Performance course H4262S. Therefore, it is important (and besides there is no benefit) to use device swap (I am also operating with FS swap, and am learning from my mistake), since the operating system DOES NOT REQUIRE BUFFER CACHE to write to the swap disk. You should make sure that the device swap is preferred over any filesystem swap (swap priority).

The SAP processes now have as much main memory and/or buffer cache as they can possibly get their hands on, because it is not being chewed up by swap I/O. If your SAP processes still thrash memory/swap, you REALLY WILL need to get more physical memory. This should be the foundation of your argument for investment in your development machine.

Aside: you can also check the I/Os per second and/or MB/s on your swap device. If you have more than 50 I/Os per second you could be in trouble, equally, if you have more than 5MB/s (on a standard SCSI device) to the swap disk you could be in trouble. You can have up to 10 swap devices (kernel parameter), they should ideally be the same size disks, and they should all be at the same priority. The operating system takes case of load balancing between the ('non-fs') swap disks.

I hope this has not been overkill, and you find this helpful, though it does not offer much solace.
"Don't shoot the messenger"--Anonymous.

Re: Filesystem Swap problem

Bill Hassell — Sun, 25 Mar 2001 02:32:45 GMT

I would strongly question the need for 20 Gb of swap and also the problem of thrashing when using device swap. Simply put, filesystem swap 2-3 times slower than device swap--assuming that ANY paging is actually taking place. If the VSS (virtual set size) of all the processes adds up to 4 Gb, then you only need 4 Gb of swap space...and it will get used if the processes are actually that big.

Perhaps SAP is doing a (poor programming technique) lookup in the kernel for the total virtual memory. I would be really surprised if more than a couple of Gb is ever occupied, which means the other 18 Gb is totally wasted space.

Paging (swapping) is always a bad thing unless it occurs just a few times per minute. Minimum recommended RAM for 11.0 using a 64-bit kernel is 4 Gb but since this is development, you can probably tolerate excessive delays due to swapping. Are you sure that device swap is actually being heavily used (hint: vmstat page out stats or use Glance, same memory metric: page outs).

Re: Filesystem Swap problem

Steven Sim Kok Leong — Sun, 25 Mar 2001 06:09:03 GMT

Hi,

The Oracle SGA has its own buffer cache as well and this SGA resides in the shared memory. It is advised to keep the OS buffer cache to a minimal since you will be using the database buffer cache anyway.

SAP R/3 has very stringent requirements on swap. But I recalled that the stringent requirements was only for the installation phase. Subsequently, you can reduce the device swap needed.

If you have sufficient physical memory, the swap space will hardly get utilised. Over the months, the graph was one flat liner.

Hope this helps. Regards.

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