swap space increasing

[Francois Rabe]

I have a client running a 5 member cluster on Tru64 Unix V5.1B-PK4. The swap space utilization keeps on growing to a point it is 100% full and the client has to reboot the sysytem to release the space again. It is currently growing at 3% per day!

Can anybody give advice on where I can look for what is using this space or how I can stop this from happening?

It looks like a memory leak of some sort.

[Venkatesh BL]

1) You could monitor 'ps' or 'collect' output to see the memory consumption of processes.

2) What is the swap 'mode' used? If it is 'eager', then swap space is allocated for all processes immediately (even if the process may not get swapped). Check out the man page of 'swapon' for more info.

[Francois Rabe]

The swap mode is set for eager at the moment. Do you think setting it to other mode will fix this? I will check what it is on the other members in the cluster.

[Michael Schulte zur Sur]

Hi Francois,

I have heard that the swapmode should be eager in a cluster. Check as BL says the usage of the processes. Can you post
sysconfig -q vm?
What kind of applications are you running?
Oracle perhaps?

greetings,

Michael

[Victor Semaska_3]

Francois,

The 'ps' command I recommend using is:

ps -eo "user,pid,vsz,rss,cmd"

Check the 'vsz' column, that's the process virtual address size.

Vic

[Francois Rabe]

Hi Michael, the output of sysconfig-q VM is:

vm:
ubc_minpercent = 10
ubc_maxpercent = 35
ubc_borrowpercent = 20
ubc_prewritemult = 2
ubc_approxlow = 60
ubc_approxhigh = 10
ubc_pgscan_drop_lock_cnt = 10
ubc_scan_pglock_cnt = 3
vm_max_wrpgio_kluster = 32768
vm_max_rdpgio_kluster = 16384
vm_cowfaults = 4
vm_segmentation = 1
vm_ubcpagesteal = 24
vm_ubcfilemaxdirtypages = 4294967295
vm_ubcdirtypercent = 40
ubc_maxdirtywrites = 5
ubc_maxdirtymetadata_pcnt = 70
ubc_kluster_cnt = 32
vm_ubcseqstartpercent = 80
vm_ubcseqpercent = 10
ubc_overflow = -1
vm_csubmapsize = 1048576
vm_ubcbuffers = 256
vm_syncswapbuffers = 128
vm_asyncswapbuffers = 4
vm_clustermap = 1048576
vm_clustersize = 65536
vm_syswiredpercent = 80
vm_troll_percent = 4
vm_inswappedmin = 1
vm_page_free_target = 256
vm_page_free_swap = 143
vm_page_free_hardswap = 4096
vm_page_free_min = 30
vm_page_free_reserved = 20
vm_page_free_optimal = 143
vm_swap_eager = 0
swapdevice = /dev/disk/dsk55b
vm_page_prewrite_target = 512
vm_ffl = 1
ubc_ffl = 1
vm_rss_maxpercent = 100
anon_rss_enforce = 0
vm_rss_block_target = 143
vm_rss_wakeup_target = 143
kernel_stack_pages = 2
vm_min_kernel_address = 18446741891866165248
malloc_percpu_cache = 1
vm_aggressive_swap = 0
new_wire_method = 0
vm_segment_cache_max = 50
gh_chunks = 0
rad_gh_regions[0] = 200
rad_gh_regions[1] = 200
rad_gh_regions[2] = 200
rad_gh_regions[3] = 200
rad_gh_regions[4] = 200
rad_gh_regions[5] = 200
rad_gh_regions[6] = 200
rad_gh_regions[7] = 200
rad_gh_regions[8] = 0
rad_gh_regions[9] = 0
rad_gh_regions[10] = 0
rad_gh_regions[11] = 0
rad_gh_regions[12] = 0
rad_gh_regions[13] = 0
rad_gh_regions[14] = 0
rad_gh_regions[15] = 0
rad_gh_regions[16] = 0
rad_gh_regions[17] = 0
rad_gh_regions[18] = 0
rad_gh_regions[19] = 0
rad_gh_regions[20] = 0
rad_gh_regions[21] = 0
rad_gh_regions[22] = 0
rad_gh_regions[23] = 0
rad_gh_regions[24] = 0
rad_gh_regions[25] = 0
rad_gh_regions[26] = 0
rad_gh_regions[27] = 0
rad_gh_regions[28] = 0
rad_gh_regions[29] = 0
rad_gh_regions[30] = 0
rad_gh_regions[31] = 0
rad_gh_regions[32] = 0
rad_gh_regions[33] = 0
rad_gh_regions[34] = 0
rad_gh_regions[35] = 0
rad_gh_regions[36] = 0
rad_gh_regions[37] = 0
rad_gh_regions[38] = 0
rad_gh_regions[39] = 0
rad_gh_regions[40] = 0
rad_gh_regions[41] = 0
rad_gh_regions[42] = 0
rad_gh_regions[43] = 0
rad_gh_regions[44] = 0
rad_gh_regions[45] = 0
rad_gh_regions[46] = 0
rad_gh_regions[47] = 0
rad_gh_regions[48] = 0
rad_gh_regions[49] = 0
rad_gh_regions[50] = 0
rad_gh_regions[51] = 0
rad_gh_regions[52] = 0
rad_gh_regions[53] = 0
rad_gh_regions[54] = 0
rad_gh_regions[55] = 0
rad_gh_regions[56] = 0
rad_gh_regions[57] = 0
rad_gh_regions[58] = 0
rad_gh_regions[59] = 0
rad_gh_regions[60] = 0
rad_gh_regions[61] = 0
rad_gh_regions[62] = 0
rad_gh_regions[63] = 0
gh_min_seg_size = 4194304
gh_fail_if_no_mem = 0
vm_bigpg_enabled = 0
vm_bigpg_anon = 64
vm_bigpg_seg = 64
vm_bigpg_shm = 64
vm_bigpg_ssm = 64
vm_bigpg_stack = 64
vm_bigpg_thresh = 6
vm_bigpg_factor = 1
vm_l3gh_anon = 1
vm_l3gh_shm = 1
vm_l3gh_ssm = 1
private_cache_percent = 0
gh_keep_sorted = 0
gh_front_alloc = 1
replicate_user_text = 1
enable_yellow_zone = 0
boost_pager_priority = 0
gsm_enabled = 1
kstack_free_target = 5
wire_audit_count = 0
vm_prepop_percent = 100

[Venkatesh BL]

You need to understand the type of processes running on the system and the system RAM capacity to determine whether changing the swap mode would fix this problem. 'vmstat' would tell you as to how often the system is swapping out stuff from memory.

Were you able to monitor the 'ps' output usng the options provided by Victor earlier?

[Han Pilmeyer]

First of all you need to set new_wire_method=1.

I guess this is an EV7 system? If it is, I suggest that you upgrade to BL26 (PK5) and install the ERP for vm_overflow. Then turn on vm_overflow by setting it to 1.

I suspect that the paging activity will be gone after you do this.