subscribe alpha-osf-managers
SUMMARY:
Current Situation:
The problem is due to across NFS open files.
The files being open by a Fortran code (called "mgal") are asciis
and binaries and the job updates the files about every 3-4 minutes
writing a 500x50 matrix. The problem only exists when this "mgal"
job runs on both client and server Alphastations at the same time,
probably due to wait time for writing to disk by both AlphaStations.
solution that will be done: Make the job less often in writing to disk
so this two jobs do not wait each other to write to disk.
how do i know the problem is due to NFS:
After all good sugesstions have been checked and the problem still
persists, this causes frustration. Fortunately if we keep trying to solve
it, we find the cause of the problem.
I found it by accident. Usually the server (Alpha Jensen 200)
which was thought does not have the performance problem ran 3 jobs at
the same time, which means each job got about 31% cputime. Finally two
of the jobs finished and left with the "mgal" that causes performance
problem. Finally when I run this "mgal" job on both client and server
at the same time, I notice that the job only gets a maximum of 50% cpu
usage in the NFS server and a maximum of 25% of cpu usage in the
NFS client Alphastation when there is no other job in both Alphastation
except "mgal".
The problem in the server was not noticeable before because it uses 100%
cpu when there are 3 jobs (31% each) and "mgal" only uses less than 50% of
cpu. "mgal" job gets 100% cpu usage when "mgal" job does not in the client
Alphastation. Only when "mgal" runs in both client and server Alphastations
then "mgal" gets only 50% in the server and gets only 25% in the client
and probably this is due to wait writing to the disk and causes cpu idle.
Acknowledgments:
I thanks alan_at_nabeth.cxo.dec.com (Alan Rollow),
Kurt Watkins <watkins_at_hhmi.swmed.edu>,
Hellebo Knut <Knut.Hellebo_at_nho.hydro.com>,
Oyanarte Portilho <portilho_at_tritium.fis.unb.br>,
"James D. Zelenka" <jz1j+_at_andrew.cmu.edu> and
rioux_at_ip6480nl.ce.utexas.edu (Tom Rioux)
for their helps and suggestions who suggest the following commands:
% limit to check shell limitation
# /sbin/swapon -s to check the use of swapspace and change /etc/fstab
# removing /sbin/swapdefault to change lazy/normal swapping
# vmstat 1 to check virtual memory swapping
I learn a lot more about memory use and swapping from their suggestions.
I apologize if I miss to mention some individuals who helped me.
Sincerely,
lihsin
+--------------------------------+--------------------------------------+
| Lih-Sin The | Email: lihsin_at_astro.phys.clemson.edu |
| Dept. of Physics and Astronomy | tlihsin_at_clemson.bitnet |
| Clemson University | Phone: 803-656-1644(O), 646-6026(H) |
| Clemson, SC 29634-1911, U.S.A | Fax : 803-656-0805 |
+--------------------------------+--------------------------------------+
==========================================================================
THE PROBLEM: THE PROBLEM: THE PROBLEM: THE PROBLEM: THE PROBLEM:
==========================================================================
Hi,
We have a problem with our Alphastation 400/4/233 that when we run a
certain fortran code, we only get 20% of cputime even when there is no one
or no job running other than our fortran program. The same program can get
about 98% cpu time on other DEC Alpha Jensen 200.
On the alphastation that we have problem (Alphastation 400/4/233),
DEC OSF/1 V3.2 Worksystem Software (Rev. 214)
DEC OSF/1 V3.2A (Rev. 17); Tue May 21 13:56:33 EDT 1996
"ps aux" command output:
USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND
lihsin 925 21.0 16.6 55.7M 217 ttyp4 R + 10:27:47 0:13.78 mgal
root 0 0.0 7.5 263M 9.5M ?? R < 13:59:43 0:05.48 [kernel
root 17 0.0 0.0 184K 32K ?? S 13:59:51 0:14.01 /sbin/up
root 395 0.0 0.2 1.39M 224K ?? S 14:00:13 0:00.20 /usr/sbi
"top" command output from the Alphastation 400/4/233:
load averages: 0.53, 0.46, 0.34 10:43:19
58 processes: 1 running, 1 waiting, 22 sleeping, 33 idle, 1 stopped
Cpu states: 13.9% user, 0.0% nice, 12.3% system, 73.7% idle
Memory: Real: 84M/118M act/tot Virtual: 47M/499M use/tot Free: 24M
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
925 lihsin 42 0 57M 22M WAIT 0:12 20.80% mgal <<==== problem
526 hartmann 44 0 11M 2285K sleep 0:31 1.20% dxterm
458 root 42 -2 22M 5193K sleep 1:21 0.90% Xdec
937 lihsin 44 0 2776K 401K run 0:00 0.40% top
842 hartmann 44 0 2744K 581K sleep 0:02 0.30% vi
499 hartmann 44 0 2792K 491K sleep 0:11 0.00% fvwm
the "mgal" job started with about 90% performance, than it decreases and
stays at about 20% cpu used. The job is in WAIT state most of the time.
While on the other alpha (Jensen 200MHz),
DEC OSF/1 V3.2 (Rev. 214); Sun Jul 2 10:59:43 EDT 1995
DEC OSF/1 V3.2 Worksystem Software (Rev. 214)
"ps aux" command output:
USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND
lihsin 28871 31.0 14.6 54.9M 119 ttyp1 R N May 20 19:00:48 mgal
pmilne 24081 31.0 0.4 2.96M 336K ?? R N May 12 3-13:24:57 snw7n
jbrown 29477 31.0 1.6 5.66M 1.3M ?? R N 21:06:13 07:31:28 jason.ex
lihsin 24575 1.0 8.9 15.7M 6.9M ?? S May 13 12:02.34 /usr/loc
root 460 1.0 7.1 10.3M 5.6M ?? S < Apr 28 56:43.95 /usr/bin
lihsin 21803 0.0 0.5 2.73M 384K ?? S May 06 2:37.37 /usr/bin
root 21773 0.0 1.5 10.7M 1.2M ?? S May 06 2:18.88 /usr/bin
root 20922 0.0 1.4 9.96M 1.1M ?? S May 06 4:13.71 dxterm -
On this Alpha Jensen 200MHz we see the "mgal" can have 100% performance
if it is the only job and becomes 31% as it shares cpu with other two jobs.
On the alphastation where we have problem, we just installed another
64MB RAM to make it has a total of 128MB RAM and this alphastation
has 500MB swapspace. We reconfigured the kernel after the additional
RAM installation and the increase of swapspace. The additional RAM is
from CAMINTONN P/N 545774.
While in the other Alphastation (Jensen 200) it has 80MB RAM and
has a total of 400MB swapspace
Could you tell me how I can get the performance that it should be?
I run other fortran programs and I can get 100% performance on both machines,
only for this big memory usage code ("mgal") the results are different in cpu
usage. Actually the Alphastation which has the problem has larger RAM and
swapspace than the other alpha that gives 100% performance on the code.
Is this problem related to cache and slow memory chips?
Thanks,
lihsin
==========================================================================
SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS:
SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS: SUGGESTIONS:
==========================================================================
On Mon, 27 May 1996 alan_at_nabeth.cxo.dec.com (Alan Rollow) wrote:
> On the odd chance the waits are the result of the process doing
> I/O, I'd look at that. From the sound of it though that seems
> unlikely. May be it is the memory speed of the 3rd party
> stuff.
the 3rd party memory is CAMINTONN P/N 545774 which is supposed for
Alphastation 400/4/233.
> It is worth noting that the system that we built having the
> internal code name Jensen never came in a 200 Mhz version as
> far as I know. Two variants of the system were built; the
> DEC 2000 Model 300 and the AXP150 or something similar. Looking
> at the SPDs, there was a Model 500 of the 2000 as well, but
> I think was a server system. At the time, the 200 Mhz chips
> were only used in the high end systems.
we bought the Alpha Jensen 200 from Carrera called Hercules 200.
it is true that DEC does not sell Alpha Jensen 200, DEC sells
DEC 2000 Model 300 and the AXP150 or something similar.
> See if you can find a comparible system that uses entirely
> Digital supports parts. Depending on where in the world you
> are there may be a Digital Benchmark Center or something
> similar near by. Other customers may also be able to loan
> you time on a system. I'd filter out any chance of paging,
> application I/O, network bottlenecks, etc before looking
> at memory, but it seems odd that the system is so idle
> on something that sounds CPU bound. If you're getting
> contention on cache lines, changing the size multi-dimensional
> arrays may help.
----------------------------------------------------------------------
On Mon, 27 May 1996, Kurt Watkins wrote:
> Maybe a shell limitation? If you're a csh user, try
>
> % limit
On the Alphastation 400/4/233 that has the performance problem (14%):
%> limit
cputime unlimited
filesize unlimited
datasize 131072 kbytes
stacksize 2048 kbytes
coredumpsize 0 kbytes
memoryuse 121360 kbytes
descriptors 4096 files
addressspace 1048576 kbytes
and on the Alpha Jensen 200 without the problem:
%> limit
cputime unlimited
filesize unlimited
datasize 131072 kbytes
stacksize 2048 kbytes
coredumpsize 0 kbytes
memoryuse 73760 kbytes
descriptors 4096
the numbers seem to show that the alphastation 400/4/233 should not have
the problem. what do you think?
> Also, I noticed in your ps output the process consuming all available
> resources on the 200 had been niced. Does nicing the same job on the 400
> change the way it runs, say decreasing the rate at which resource
> utilization falls off?
i tried with many different priority of the job from lowest to highest,
and all the trial end up at the same usage of cpu when there is no one
or no other job in the alphastation.
> If these don't work, dig into the virtual memory configuration a bit
> further.
i am not an expert in the virtual memory configuration, i'll appreciate
very much if you can give more specific/detail instruction if you have time.
> Me neither :( I've had some trouble with some FORTRAN codes that had very
> large data structures, most of which were not used simultaneously. The
> kernel doesn't seem to realize that and becomes very stingy w/ resources.
> Increasing swap space seemed to cure the problem, though neither the
> original swap nor the increased size swap was ever utilized. It just
> seemed to keep the scheduling algorithms happy.
> The presence/absence of the /sbin/swapdefault link seems to have some
> bearing on this. I think there are some notes about it (lazy mode?) in
> the list archives. You might have a look at the swapon(8) man page. Sorry
> I'm not more help,
On Tue, 28 May 1996, Kurt Watkins <watkins_at_hhmi.swmed.edu> wrote:
> Yes, they look very similar, probably the default values as shipped. This
> makes me think there's something quite different about (the configuration
> of) your memory subsystems between the 200 and 400. What does swapon -s
> show?
On the Alphastation 400/4/233 that has the performance problem (14%):
# /sbin/swapon -s
Swap partition /dev/rz0b (default swap):
Allocated space: 16384 pages (128MB)
In-use space: 752 pages ( 4%)
Free space: 15632 pages ( 95%)
Swap partition /dev/rz1b:
Allocated space: 47500 pages (371MB)
In-use space: 644 pages ( 1%)
Free space: 46856 pages ( 98%)
Total swap allocation:
Allocated space: 63884 pages (499MB)
Reserved space: 3802 pages ( 5%)
In-use space: 1396 pages ( 2%)
Available space: 60082 pages ( 94%)
Conclusion: Seems the Alphastation does not need more swapspace.
On the Alphastation 400/4/233 that has the performance problem (14%):
# ls -aslt /sbin/swapdefault
0 lrwxrwxrwx 1 root system 11 Jan 11 1995 /sbin/swapdefault -> ../dev/rz0b
On the Alpha Jensen 200 where we can get 100% performance:
# /sbin/swapon -s
Swap partition /dev/rz1b (default swap):
Allocated space: 50000 pages (390MB)
In-use space: 5078 pages ( 10%)
Free space: 44922 pages ( 89%)
Total swap allocation:
Allocated space: 50000 pages (390MB)
Reserved space: 7163 pages ( 14%)
In-use space: 5078 pages ( 10%)
Available space: 42837 pages ( 85%)
----------------------------------------------------------------------
On Tue, 28 May 1996, Hellebo Knut <Knut.Hellebo_at_nho.hydro.com> wrote:
> Check out your swapping policy on the system. Try removing
> /sbin/swapdefault, add all swapareas to /etc/fstab and reboot if the
> /sbin/swapdefault file is present.
it had /sbin/swapdefault as:
# ls -aslt /sbin/swapdefault
0 lrwxrwxrwx 1 root system 11 Jan 11 1995 /sbin/swapdefault -> ../dev/rz0b
Following the suggestion above, we delete /sbin/swapdefault,
and write /etc/fstab as:
/dev/rz0a / ufs rw 1 1
/proc /proc procfs rw 0 0
/dev/rz0g /usr ufs rw 1 2
/dev/rz1d /users ufs rw 1 2
/dev/rz1b swap1 ufs sw 0 2
/dev/rz0b swap2 ufs sw 0 2
and reboot the system. then ps aux output gives:
grb:/keck/users/lihsin/mgal> ps aux
USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND
lihsin 507 13.0 6.9 55.6M 8.7M ttyp1 R 08:55:07 0:53.33 mgal
root 0 0.0 6.3 263M 8.0M ?? R < 08:50:46 0:04.27 [kernel
root 465 0.0 2.4 19.6M 3.1M ?? S < 08:51:27 0:03.68 /usr/bin
root 1 0.0 0.0 296K 56K ?? I 08:50:47 0:00.16 /sbin/in
root 3 0.0 0.7 1.12M 896K ?? I 08:50:47 0:00.10 /sbin/kl
root 17 0.0 0.0 184K 32K ?? S 08:50:54 0:00.15 /sbin/up
root 121 0.0 0.1 1.34M 160K ?? I 08:51:04 0:00.03 /usr/sbi
"top" command output gives:
load averages: 0.13, 0.19, 0.23 09:01:40
36 processes: 1 running, 1 waiting, 9 sleeping, 25 idle
Cpu states: 5.7% user, 0.0% nice, 10.8% system, 83.4% idle
Memory: Real: 52M/119M act/tot Virtual: 499M use/tot Free: 59M
^
|
strangely change from before we change the swapdefault
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
507 lihsin 42 0 57M 9232K WAIT 1:02 14.20% mgal
537 lihsin 44 0 2776K 401K run 0:00 0.50% top
470 root 44 0 6840K 991K sleep 0:00 0.10% xdm
465 root 42 -2 20M 3227K sleep 0:03 0.00% Xdec
460 root 44 0 2432K 720K sleep 0:00 0.00% nsrd
494 lihsin 44 0 2000K 368K sleep 0:00 0.00% csh
493 root 44 0 1464K 286K sleep 0:00 0.00% telnetd
473 root 44 0 2640K 270K sleep 0:00 0.00% nsrindexd
173 root 44 0 1400K 147K sleep 0:00 0.00% routed
119 root 44 0 1376K 139K sleep 0:00 0.00% syslogd
17 root 44 0 184K 32K sleep 0:00 0.00% update
changing the swapdefault(normal/lazy) does not change the performance on "mgal".
"mgal" stays at the WAIT state most of the time.
----------------------------------------------------------------------
On Tue, 28 May 1996, Oyanarte Portilho <portilho_at_tritium.fis.unb.br> wrote:
> We have faced the same kind of problem with fortran codes
> that use more than ~ 50% of the machine memory. The same with
> maple processes. I have asked help to the osf-managers list
> but no suggestion solved the problem. Hope you are luckier now!
do you use third party SIMMS for your Alphastation?
----------------------------------------------------------------------
On Tue, 28 May 1996, "James D. Zelenka" <jz1j+_at_andrew.cmu.edu> wrote:
> Sounds like you're paging most of the time. The wait state generally
> means that you're waiting for an I/O to complete- either due to a page
> fault, or waiting on a filesystem or device access. Since the machine
> that runs the app fine has an extra 16 MB of memory, this suggests that
> it's vm-related. On the bright side, you know that the app runs
> comfortably in 80 MB of memory.
--------
on the Alpha Jensen 200 (keck) that does not have problem with performance:
when running "mgal"
keck:/users/lihsin> vmstat
astro> rsh keck "vmstat 1"
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 71 14 6786 100 1890 14M 860K 9M 30K 3M 12K 8 231 292 91 3 6
5 71 14 6751 135 1890 236 42 114 0 29 0 239 730 464 37 63 0
5 71 14 6751 135 1890 67 0 67 0 0 0 223 625 332 37 63 0
5 71 14 6751 135 1890 67 0 67 0 0 0 243 616 357 37 63 0
5 71 14 6751 135 1890 67 0 67 0 0 0 323 853 479 37 63 0
4 72 14 6751 135 1890 67 0 67 0 0 0 206 920 392 43 57 0
5 71 14 6749 137 1890 67 0 67 0 0 0 179 1K 491 43 57 0
6 70 14 6749 137 1890 67 0 67 0 0 0 232 1K 584 30 70 0
6 70 14 6749 137 1890 67 0 67 0 0 0 212 1K 656 36 64 0
5 71 14 6749 137 1890 67 0 67 0 0 0 225 1K 443 38 62 0
5 71 14 6749 137 1890 67 0 67 0 0 0 207 867 410 41 59 0
4 72 14 6749 137 1890 67 0 67 0 0 0 191 374 384 47 53 0
5 71 14 6749 137 1890 67 0 67 0 0 0 249 897 508 49 51 0
--------
In the Alphastation 400/4/233 with the performance problem:
grb> vmstat 1 when no job is running
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
2 70 15 8361 5167 1229 146K 19K 88K 0 15K 0 13 65 262 2 1 97
2 70 15 8376 5152 1229 122 14 79 0 7 0 3 43 260 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 3 37 251 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 2 37 255 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 2 37 249 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 2 49 256 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 5 130 277 2 3 94
2 70 15 8376 5152 1229 55 0 55 0 0 0 5 37 259 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 2 37 253 0 3 97
2 70 15 8376 5152 1229 55 0 55 0 0 0 3 37 249 0 3 97
grb> vmstat 1 with "mgal" job running at 22-28% cpu usage.
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 75 16 11K 2431 1186 129K 17K 76K 0 14K 0 11 61 258 2 1 97
2 75 17 11K 2415 1186 131 15 96 0 8 0 240 312 672 15 15 70
2 73 17 10K 2527 1186 103 0 78 0 0 0 292 552 777 14 24 62
2 73 17 10K 2527 1186 69 0 69 0 0 0 235 200 666 15 14 71
2 73 17 10K 2528 1186 70 0 70 0 0 0 242 390 698 12 15 73
3 72 17 10K 2527 1186 71 0 71 0 0 0 333 310 774 16 17 67
3 73 16 10K 2528 1186 71 0 69 0 0 0 238 354 677 14 15 71
2 74 17 11K 2478 1186 72 0 72 0 0 0 272 677 767 18 18 64
2 74 16 11K 2496 1186 154 19 110 0 18 0 238 216 658 14 17 69
2 74 16 11K 2496 1186 72 0 72 0 0 0 272 334 738 16 14 70
3 74 15 11K 2497 1186 71 0 71 0 0 0 243 991 820 15 18 67
2 73 16 10K 2551 1186 70 0 70 0 0 0 292 583 783 17 17 66
2 73 16 10K 2551 1186 88 0 76 0 0 0 272 345 737 14 16 70
2 73 16 10K 2551 1186 68 0 68 0 0 0 251 559 730 17 16 67
grb> /usr/local/bin/top
load averages: 0.16, 0.43, 0.55 10:57:38
59 processes: 1 running, 2 waiting, 17 sleeping, 38 idle, 1 stopped
Memory: Real: 89M/118M act/tot Virtual: 499M use/tot Free: 19M
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
1109 lihsin 42 0 58M 23M WAIT 1:13 20.80% mgal
465 root 42 -2 21M 4825K sleep 2:56 5.80% Xdec
1246 lihsin 44 0 1984K 327K sleep 0:00 4.00% csh
1220 root 44 0 1464K 327K sleep 0:00 1.60% rshd
1247 lihsin 44 0 2752K 278K run 0:00 1.50% top
612 hartmann 44 0 11M 2252K sleep 0:38 0.90% dxterm
712 hartmann 44 0 2088K 557K sleep 0:01 0.60% tcsh
395 root 44 0 1424K 229K sleep 0:00 0.10% inetd
--------
===========================================================================
Wed, 29 May 96, rioux_at_ip6480nl.ce.utexas.edu (Tom Rioux) wrote:
> I suspect swapping;
> try "swapon -s" as follows:
> alpha1:root:/etc# swapon -s
> Swap partition /dev/rz3b:
> Allocated space: 25585 pages (199MB)
> In-use space: 1965 pages ( 7%)
> Free space: 23620 pages ( 92%)
> Total swap allocation:
> Allocated space: 25585 pages (199MB)
> In-use space: 1965 pages ( 7%)
> Available space: 23620 pages ( 92%)
> alpha1:root:/etc#
Below is the output of swapon -s commands on the Alphastation 400/4/233
while we run the fortran job which only gets 20-28% performance with no
other job runs in the Alphastation:
astro> rsh grb "/sbin/swapon -s "
Swap partition /dev/rz1b:
Allocated space: 47500 pages (371MB)
In-use space: 1 pages ( 0%)
Free space: 47499 pages ( 99%)
Swap partition /dev/rz0b:
Allocated space: 16384 pages (128MB)
In-use space: 1 pages ( 0%)
Free space: 16383 pages ( 99%)
Total swap allocation:
Allocated space: 63884 pages (499MB)
In-use space: 2 pages ( 0%)
Available space: 63882 pages ( 99%)
Conclusion: the Alphastation does not need extra swapspace.
> If the In-use space becomes high, then you are swapping too much.
> Also try "vmstat 1"; look for high "fault" that is associated with "pin"
> and "pout" as opposed to "zero".
> Also check out normal/lazy swapping:
> normal swapping has /sbin/swapdefault symbolically linked to /dev/rz3b or
> some other swap partition and allocates swap space upon process creation
> lazy swapping does not have /sbin/swapdefault defined and allocates swap
> space upon a process needing swap space.
it had /sbin/swapdefault as:
# ls -aslt /sbin/swapdefault
0 lrwxrwxrwx 1 root system 11 Jan 11 1995 /sbin/swapdefault -> ../dev/rz0b
we delete /sbin/swapdefault,
# ls -aslt /sbin/swapdefault
and write /etc/fstab as:
/dev/rz0a / ufs rw 1 1
/proc /proc procfs rw 0 0
/dev/rz0g /usr ufs rw 1 2
/dev/rz1d /users ufs rw 1 2
/dev/rz1b swap1 ufs sw 0 2
/dev/rz0b swap2 ufs sw 0 2
and reboot the system. then ps aux output gives:
grb:/keck/users/lihsin/mgal> ps aux
USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND
lihsin 507 13.0 6.9 55.6M 8.7M ttyp1 R 08:55:07 0:53.33 mgal
root 0 0.0 6.3 263M 8.0M ?? R < 08:50:46 0:04.27 [kernel
root 465 0.0 2.4 19.6M 3.1M ?? S < 08:51:27 0:03.68 /usr/bin
root 1 0.0 0.0 296K 56K ?? I 08:50:47 0:00.16 /sbin/in
root 3 0.0 0.7 1.12M 896K ?? I 08:50:47 0:00.10 /sbin/kl
root 17 0.0 0.0 184K 32K ?? S 08:50:54 0:00.15 /sbin/up
root 121 0.0 0.1 1.34M 160K ?? I 08:51:04 0:00.03 /usr/sbi
Conclusion: Changing normal/lazy swapping does not solve the problem.
the "mgal" still runs at only 13-20% cpu usage.
=======================================================================
Received on Fri May 31 1996 - 17:53:54 NZST