[comp.unix.ultrix] Ultrix 4.0 swap problem on RISC.

bni@modulex.dk (Bent Nielsen) (10/17/90)

Is there still a swap problem in Ultrix 4.0 or another problem that look
like a swap eating problem?

I'm running:
ULTRIX V4.0 (Rev. 179) System#1: Tue Aug 28 08:08:06 EDT 1990
UWS V4.0 (Rev. 164)
on DECsystem 3100 and DECstation 2100.

Configuration:
Server:	    DECsystem 3100 with 2xRZ55, 24Mb memory and 64Mb swap.
Clients:    DECstations 2100 diskless with 12Mb memory and 36Mb swap.
Connection: Ethernet TCP/IP.

Our problem is that we have to reboot the DECstations often more than once
a week, because available (free) swap is reduced, but we don't have
the problem with the DECsystem.

After starting and stopping a number of programs the free swap is reduced and
we will get error messages like "not enough core" when starting a new program
or malloc error message "can not malloc".

If it isn't a swap problem can it be a problem with the display server?
We are running Xcfb.

Please reply by email.
Thanks.

--
Bent Nielsen		<bni@modulex.dk>
A/S MODULEX		Phone:    +45 44 53 30 11
Lyskaer 15		Telefax:  +45 44 53 30 74
DK-2730 Herlev
Denmark

grr@cbmvax.commodore.com (George Robbins) (10/18/90)

In article <700@modulex.dk> bni@modulex.dk (Bent Nielsen) writes:
> Is there still a swap problem in Ultrix 4.0 or another problem that look
> like a swap eating problem?
> 
> Our problem is that we have to reboot the DECstations often more than once
> a week, because available (free) swap is reduced, but we don't have
> the problem with the DECsystem.

I'd suggest analyzing the situation after things seem to have become constipated
to see where the swap space is being used.  DEC X servers have been known to
start big and grow over time.  You may also have a problem with swap space
getting fragmented or having idle/disconnected X sessions lying around sucking
up swap space.

pstat -s / pstat -p and ps are can be used to try to account for swap
space usage...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)