Hi,
To sum up the problem: Free space as shown from vmstat gradually decreases
until the point that no more processess can start. The system is essentially
"frozen" or "locked up" then.
I've tried to include as much info as possible which makes for a rather long
message, because I realize you/we are not Clara Voyant.
Details:
I have a 3000/700 machine with 320 MB memory and ~ 2 GB swap space (overkill
I'm sure). I recently did a full install from scratch of Tru64 5.0 on it,
replacing 4.0D. It ran great with 4.0D, but now I have some problem with
memory not getting freed up. I can't seem to find an error messages or anything
relevant in log files.
Over the space of say 3-4 hours with it running very little non-OS programs,
it eventually shows "free" in vmstat going from 23K down to 600 or less, at
which time it cannot start new processes. Note that programs already running
seem to pretty much continue to run. Example: you can ping the machine,
getting an "alive" response, or get some banner info back from telnet (this is
at times of very low "free" values) but which does not respond with the
"login:" prompt. rsh commands from other computers are unable to execute; dumps
continue to dump.
I had trouble from the beginning with the default parameters in sysconfigtab
instituted after initial OS install setup, which I have several times told
dxkerneltuner to reset to default. I'm not really certain that it did,
though, after comparing the current sysconfigtab file with various versions
saved in /etc. (I surmise that "restore" only refers to answers present at
startup of dxkerneltuner, which are changed during that session only).
I've read through the "System Configuration and Tuning" docs at
http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V50_HTML/
... calculating values that seem in line with default values. I've searched
through
http://www-archive.ornl.gov:8000 without finding an answer in general
for 5.0, or for patches.
Both "vm_aggressive_swap = 1" and "vm_aggressive_swap = 0" have been tried
in combination with "vm_swap_eager = 1". I'm getting ready to try
"vm_swap_eager = 0" with
"vm_aggressive_swap = 0"
Note that I get:
vmstat:
Virtual Memory Statistics: (pagesize = 8192)
procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy id
5 141 27 42K 8998 4318 491K 55K 343K 1306 49K 0 553 1K 389 2 18 80
at the same time "dxsysinfo" says that I have "In-Use Memory" = 59% and "Available
Swap" = 94%. I would have thought that 8.99K divided by 23K (or 27K *immediatley*
after reboot) would have indicated something more like 38% or 33% - but maybe its
not that simple.
At a system reboot, "vmstat 60" shows:
vmstat 60
Virtual Memory Statistics: (pagesize = 8192)
procs memory pages intr cpu
r w u act free wire fault cow zero react pin pout in sy cs us sy id
3 100 22 19K 23K 3078 122K 26K 62K 1281 15K 0 632 440 225 14 12 74
2 101 22 19K 23K 3173 73 86 153 0 142 0 71 285 134 3 3 94
3 100 23 19K 22K 3195 370 52 147 0 89 0 236 300 402 2 5 92
2 103 22 19K 23K 3210 2013 443 565 8 382 0 344 349 601 1 8 91
2 103 22 19K 22K 3321 1063 226 394 0 154 0 46 132 91 0 3 97
2 102 23 20K 22K 3353 1924 386 601 0 386 0 161 317 235 1 6 93
2 103 22 20K 22K 3335 481 77 151 0 62 0 64 156 123 2 3 95
2 103 22 21K 22K 3350 1893 227 962 0 229 0 68 134 110 5 4 92
2 104 22 21K 22K 3350 795 212 173 0 164 0 18 87 77 0 3 97
2 103 22 21K 22K 3351 1295 183 618 0 198 0 32 147 95 5 3 92
2 103 22 21K 22K 3351 743 193 275 6 118 0 25 100 85 0 3 97
2 104 23 21K 21K 3369 491 33 47 0 48 0 15 210 74 3 3 95
2 106 22 21K 21K 3377 894 313 276 0 349 0 34 165 85 2 3 95
2 107 23 22K 21K 3417 1092 236 327 0 238 0 296 228 521 1 7 91
showing that "free" is disappearing rather quickly. (These are at 60 second
intervals, as you can see from above command of "vmstat 60").
=======================================================
The system:
from "uerf -r 300":
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 300. SYSTEM STARTUP
SEQUENCE NUMBER 0.
OPERATING SYSTEM DEC OSF/1
OCCURRED/LOGGED ON Tue Jul 25 10:49:25 2000
OCCURRED ON SYSTEM dec4
SYSTEM ID x00060004 CPU TYPE: DEC 3000
SYSTYPE x00000000
MESSAGE Alpha boot: available memory from
_0x1798000 to 0x14000000
Digital UNIX V5.0 (Rev. 910); Wed Jul
_5 14:13:51 EDT 2000
physical memory = 320.00 megabytes.
available memory = 296.42 megabytes.
using 1221 buffers containing 9.53
_megabytes of memory
Firmware revision: 7.0
PALcode: UNIX version 1.45
DEC 3000 - M700
=======================================================
syslog files:
vmunix: Alpha boot: available memory from 0x1798000 to 0x14000000
vmunix: Digital UNIX V5.0 (Rev. 910); Wed Jul 5 14:13:51 EDT 2000
vmunix: physical memory = 320.00 megabytes.
vmunix: available memory = 296.42 megabytes.
vmunix: using 1221 buffers containing 9.53 megabytes of memory
vmunix: Firmware revision: 7.0
vmunix: PALcode: UNIX version 1.45
vmunix: DEC 3000 - M700
vmunix: vm_swap_init: swap is set to eager allocation mode
vmunix: datalink: links=128, macs=6
=======================================================
ps -o vsz
VSZ
2.70M
2.70M
=======================================================
output of sysconfig -q vm:
vm:
ubc_minpercent = 10
ubc_maxpercent = 100
ubc_borrowpercent = 20
vm_max_wrpgio_kluster = 32768
vm_max_rdpgio_kluster = 16384
vm_cowfaults = 4
vm_segmentation = 1
vm_ubcpagesteal = 24
vm_ubcfilemaxdirtypages = -1
vm_ubcdirtypercent = 10
ubc_maxdirtywrites = 5
vm_ubcseqstartpercent = 50
vm_ubcseqpercent = 10
vm_csubmapsize = 1048576
vm_ubcbuffers = 256
vm_syncswapbuffers = 128
vm_asyncswapbuffers = 4
vm_clustermap = 1048576
vm_clustersize = 65536
vm_syswiredpercent = 80
vm_inswappedmin = 1
vm_page_free_target = 128
vm_page_free_swap = 74
vm_page_free_hardswap = 2048
vm_page_free_min = 20
vm_page_free_reserved = 10
vm_page_free_optimal = 74
vm_swap_eager = 1
swapdevice = /dev/disk/dsk0b, /dev/disk/dsk1b, /dev/disk/dsk6b
vm_page_prewrite_target = 256
vm_ffl = 1
ubc_ffl = 1
vm_rss_maxpercent = 100
anon_rss_enforce = 0
vm_rss_block_target = 74
vm_rss_wakeup_target = 74
dump_user_pte_pages = 0
kernel_stack_pages = 0
vm_min_kernel_address = 18446744071562067968
malloc_percpu_cache = 1
vm_aggressive_swap = 1
new_wire_method = 1
vm_segment_cache_max = 50
vm_page_lock_count = 0
gh_chunks = 0
gh_min_seg_size = 8388608
gh_fail_if_no_mem = 1
private_text = 0
vm_page_private_color = 0
private_cache_percent = 0
gh_keep_sorted = 0
gh_front_alloc = 1
delayed_swapon = 0
enable_yellow_zone = 0
Thanks for any help you can give. I really need to have this machine running
for more than a couple of hours at a time. Reboots are causing some nasty
problems for users, especially when the system freezes during edit sessions or
long simulation or image reconstruction jobs.
KG
Kim L. Greer klg_at_dec3.mc.duke.edu
Duke University Medical Center voice: 919-684-7223
Div. Nuclear Medicine POB DUMC-3949 fax: 919-684-7123
Durham, NC 27710
Received on Tue Jul 25 2000 - 20:10:35 NZST