Sorry for my late reply. Many thanks for the replies. I got only very few answers. Compaq and myself are still looking to this problem. Iam running the ASE services on the second machine and it is running more or less stable. I used sys_check and looked the output. Unfortunately I could not find anything which can produce this problem. Compaq suggested me certain steps: 1. Exchange the cable connections to the Giga Switch. 2. Take a crash dump and send to them. 3. Reinstall the OS (?) on the problem machine. Answers I received: =================== Balaji Chandrasekar wrote: I earnestly hope you have a solution for the problem. If not , I will like to take a jibe at it. Well, could you mail me the daemon.log for the machine when this error occurs. May be this is some other underlining error. You said the problem is there for last one year, what changed during that period of time ? Balaji./ Answer:...Except the System Upgrade(4.0D) in 1998 Dec. we have made any changes till 1999 December..... Udo de Boer wrote: ================== Hi, I don't know what is wrong with your systems but it is very strange. I suggest looking if the "swapon -s" command and the "vmstat -M" show values growing over time. It is problably not anything to do with maxusers. Also how full are the file systems / and /usr. Hope this helps regards Udo de Boer Tom Brand wrote: =============== Have you used SYS_CHECK to review your system setup? # sys_check -all > /tmp/syscheck.html It is available at: and also on the new CD's (4.0F and higher I believe>) Cheers, Tom Davis, Alan wrote: ================== Kumar, maxusers = 128 is /really/ low for any kind of server. If your support person only mentioned ubc-maxpercent and maxusers to solve this problem, find another support person. There are several parameters that interact to correctly size kernel structures. Read the system tuning manual to familiarize yourself with the parameters and call support again. Alan Davis Original Question: =================== On Tue, 8 Feb 2000, Sreekumaran Padiyath wrote: > > Since beginning of this year we are having serious problems with our > ASE > cluster. There are 2 HSZ40 controllers connected to a raid array with > raid > level5. We are running Tru64 V4.0D with Patch level5 including > cluster > patches. The message I receive on the console is the following: > > Feb 8 10:07:40 psw223 vmunix: malloc_mem_alloc: no space in map > <--------- > > Afterwards I cannot execute any commands till I reboot the system(By > pressing > the reset button on DEC3800). The 2 machines in the cluster are > DEC3800 with each > 196Mb memory. As our compaq support person suggested I added the > following values > to vm and proc parameters without success. > vm: > ubc-maxpercent = 90 > > proc: > maxusers = 128 > > According to support person I have to reduce to 80 of vm which Iam > doing next time. > > The output from "sysconfig -q vm is": > vm: > ubc-minpercent = 10 > ubc-maxpercent = 90 > ubc-borrowpercent = 20 > ubc-maxdirtywrites = 5 > ubc-nfsloopback = 0 > vm-max-wrpgio-kluster = 32768 > vm-max-rdpgio-kluster = 16384 > vm-cowfaults = 4 > vm-mapentries = 200 > vm-maxvas = 1073741824 > vm-maxwire = 16777216 > vm-heappercent = 7 > vm-vpagemax = 16384 > vm-segmentation = 1 > vm-ubcpagesteal = 24 > vm-ubcdirtypercent = 10 > 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-zone_size = 0 > vm-kentry_zone_size = 16777216 > 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-page-prewrite-target = 256 > dump-user-pte-pages = 0 > kernel-stack-guard-pages = 1 > vm-min-kernel-address = 18446744071562067968 > malloc-percpu-cache = 1 > contig-malloc-percent = 20 > vm-aggressive-swap = 0 > vm-map-index-count = 64 > vm-map-index-rebalance = 128 > vm-map-index-enabled = 1 > vm-map-index-hiwat = 4 > vm-map-index-lowat = 2 > 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 > private-cache-percent = 0 > > proc: > > proc: > max-proc-per-user = 64 > max-threads-per-user = 256 > per-proc-stack-size = 2097152 > max-per-proc-stack-size = 33554432 > per-proc-data-size = 134217728 > max-per-proc-data-size = 1073741824 > max-per-proc-address-space = 1073741824 > per-proc-address-space = 1073741824 > autonice = 0 > autonice-time = 600 > autonice-penalty = 4 > open-max-soft = 4096 > open-max-hard = 4096 > ncallout_alloc_size = 8192 > round-robin-switch-rate = 0 > round_robin_switch_rate = 0 > sched-min-idle = 0 > sched_min_idle = 0 > give-boost = 1 > give_boost = 1 > maxusers = 128 > task-max = 1045 > thread-max = 2088 > num-wait-queues = 128 > num-timeout-hash-queues = 128 > enable_extended_uids = 0 > enhanced-core-name = 0 > enhanced-core-max-versions = 16 > > > I would like to know: > > 1. How can I get rid of this problem? > 2. Which system parameter I have to tune now? > (vm-mapentries or vm-vpagemax or ubc-nfsloopback or something > else?) >