Hi,
Thanks to every one who replied.I got the following replies. Most
probably we will start with the patch suggested by Ed Murphy
and see the results before we go for other suggestions.The
following people send me their replies. Many thanks.
bingwersen_at_traverse.com
Bryan.Lavelle_at_digital.com
Claude_at_genoscope.cns.fr
N.M.Hill_at_rl.ac.uk
rajeshar_at_swecexc.xko.dec.com
ed.murphy_at_ussurg.com
Benjamin Ingwersen wrote:
=========================
An idea, swap out your 3x 400Mhz to the 2x 600Mhz, save bandwidth
add an open slot.
Bryan wrote:
===========
# script
# dbx -k /vmunix /dev/mem
dbx> p vm_perfsum
Send the results.
Claude Scarpelli wrote:
======================
Join the club !
We have this problem for months on ours 4 4-CPU 8200 w/ 2Gb
mem. Reporting to DEC never help. However, we are still working on
it. Last week, we have been told by DEC to replace 4 kernel modules
(arch_alphapmap.mod, std_kern.mod, vfs.mod and vm.mod), and install
them on top of 4.0D + kit #3.
I do not have the result yet.
Can you give me the DEC case number attached to this problem, in order
to help me convince DEC support in France that this is not an isolated
problem ?
Join the club !
Nick Hill wrote:
===============
Unfortunately I do not have the answer but I do have the same problem! It
doesn't happen very often but when it does I see similar symptoms on my 8400
machines. When free memory gets very low
the system appears to lock up as you mentioned. Again I see no disk activity
so the system is not thrashing in page/swap mode and interactive sessions
just freeze. I have seen it happen while running top or monitor and they
just stop dead. The machine responds to a ping from another host but that is
about all it will do. After a while if left alone the system recovers and
carries on. I have not seen 10 hour duration's, at most about 45 mins I
guess. I notice you have increased the vm-page-free parameters, I have done
the same but to higher levels than you have. I have the
vm-page-free-target at 8000 or 62.5Mb. This seems a reasonable target for a
machine with 4Gb memory. Using the system defaults I used to a lot more
performance problems.
If you get an answer then I would be grateful to know the solution.
Rajesh wrote:
============
Why don't you try the "sys_check" utility ?.It will show all the
tunning suggestions.
It is available at
ftp://ftp.digital.com/pub/DEC/IAS/sys_check
The .tar file is a SETLD kit and contains the sys_check script, GZIP,
and additional binary utilities that sys_check uses to collect Disk I/O,
Scheduler statistics, and console variables.
Ed Murphy wrote:
===============
We had seen similiar behavior under 4.0D BL11. The patch was
vm_perform_v40dbl11.
The problem report:
==================
> Hi,
> One of our best tru64 user has noticed the following behaviour of one of our Alpha4100(having 3 processor). If any one can help us
> I will be very thankful.
>
> The following is the present configuration of proc and vm:
> =========================================================
>
> proc:
> maxusers = 256
> max-proc-per-user = 256
> max-per-proc-address-space = 5368709120
> per-proc-address-space = 5368709120
> max-per-proc-data-size = 5368709120
> per-proc-data-size = 5368709120
> max-per-proc-stack-size = 1048576
> per-proc-stack-size = 1048576
>
> vm:
>
> vm-vpagemax=33554432
> vm-maxvas = 5368709120
> ubc-minpercent = 1
> ubc-maxpercent = 3
> ubc-borrowpercent = 2
> new-wire-method = 0
> vm-aggressive-swap = 0
> vm-page-free-target = 1024
> vm-page-free-swap = 296
> vm-page-free-hardswap = 2048
> vm-page-free-min = 80
> vm-page-free-reserved = 80
> vm-page-free-optimal = 296
> vm-page-prewrite-target = 2048
>
> Problem: System locks up when running programs with large memory needs
> ============================================================ ========= =
> My system is a Alpha server 4100, presently running with 3 400MHz processors
> and 2GByte of RAM under Digital Unix 4.0D.
> When running programs whose RAM needs are below about 1.8 GByte, there is
> no problem with the system. However, when the RAM needs of a program exceed
> about 1.8-1.9 GByte the system gets essentially locked up: no logins are
> possible and previously running foreground jobs do not respond (top or iostat
> e.g. cease to print out system activities).
>
> I made sure that in my programs which produce the above problem, not all of
> the allocated RAM is active at once, indeed in the code which produces these
> problems, only 2 out of 3 very long vectors are used simultaneously.
> Indeed, I can avoid the memory-management bottleneck by moving one of the three
> vectors to disk and freeing the corresponding memory.
> When the system locks up, it stays locked for many hours, but after a long
> time (10-20 hours) it 'heals'. While locked, there is no disk activity
> no swapping or pageing.
>
> On a Linux-Intel system I have not been able to reproduce the problem
> (no locking-up occurs).
>
> The problem has been reported to Digital/Compaq repeatedly. Some system
> parameters have been modified without success.
>
> Suggestions are welcome!
> ============================================================ =======
>
> Thanks in advance
>
> Please send the mail in the following address. I will summarize.
>
> PADIYATH Sreekumar | System Manager | Paul Scherrer Institute
> CH-5232 Villigen PSI | Switzerland | Tel: +41 56 310 36 43
> FAX : +41 56 310 36 49 | E-Mail: kumar.padiyath_at_psi.ch
Received on Mon Mar 29 1999 - 07:25:51 NZST