'ps' behavoir in Linux - Was - Re: array limits

[Fairlight]

Y'all catch dis heeyah?  Jerry Rains been jivin' 'bout like:
> 
> Ok, the main problem I seem to have is with the desktop Linux I am using.  
> This morning I rebooted the system to shut down any extra processes and 
> logged into tty1 and tty2 to start a dclerk process then see what was going 
> on.  I did a 'free' command and there was no swap memory being used, however 
> with only the two text logins dclerk was still swapped out on my system.  The 
> logon header confirmed that my system is indeed SuSE 8.2.  Since I only use 
> this system for my Desktop needs, I'm not going to worry about why.
> 
> My problem is at work so I dialed back in this morning.  The system was idle 
> and ps aux worked fine.
> 
> SuSE Linux on iSeries -- the spicy solution!
> Have a lot of fun...
> filepro at as400linux1:/var/appl/filepro> w
>   9:13am  up  3:22,  3 users,  load average: 0.07, 0.03, 0.05
>   USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
>   root     pts/2    -                 8:50am 23:33   0.00s   ?     -
>   filepro  pts/3    -                 9:13am  0.00s  0.64s  0.02s  w
>   filepro at as400linux1:/var/appl/filepro> free
>                           total       used       free     shared    buffers   
> cached
> Mem:       1001668     261940     739728          0      51004     127036
>                -/+ buffers/cache:      83900     917768
>                Swap:       996020          0     996020
>                filepro at as400linux1:/var/appl/filepro> ps aux | grep dclerk
>                filepro  14020  7.0  0.1  2480 1204 pts/0    S    09:14   0:01 
> /appl/fp/dclerk vregstr -s1 -h Vregister -d
>                filepro  14038  0.0  0.0  1740  656 pts/3    S    09:14   0:00 
> grep dclerk
>                filepro at as400linux1:/var/appl/filepro>
> 
> So the answer is, even though we have 1Gb of memory, we don't have enough 
> memory to prevent swapping during operations.  I'll look into seeing if I can 
> move some of the memory from the OS400 side to the Linux partition.
> 
> Thanks to all who helped.

But that doesn't make a heck of a lot of sense, unless you've confused the
issue.  You're saying on SuSE 8.2, you can have zero swap used, and dclerk
is still swapped out.  That's what you said.  At least, that's what I read.

Then you said that the system at -work- has a gig of memory, and you point
to ps auxww working fine there, and showing arguments, etc.  IOW, the
process is not swapped out--on a totally different system.

The question is, why did you show stats from the iSeries that -isn't-
having problems instead of stats from the system that -is- having problems?

FWIW, I'm seriously questioning why 8.2 would be swapping out dclerk.  What
kernel revision comes up in `uname -a` on the 8.2 system, out of curiosity?
If it's old enough, it could be a mutant <2.4.15 system, and then this
would start making a hell of a lot more sense, given the VM model issues
extant through that period.  Indeed, I heard many reports of processes being
swapped out in favour of disk cache (a la Windows) in the earlier days of
the 2.4 tree's new VM, notably from 2.4.3 through 2.4.16.  "Have you done
an update of the kernel on that system to the latest revision?" would be my
next question.

Show the `free` output from -that- system.

You have a gig of memory available on the iSeries, that's apparently -not-
having issues, and you want to toss more at it, even though you're saying
the problem is your desktop 8.2 system.  This makes less sense to me by the
minute.  Could you please clarify the situation, and/or give the relevant
output from the problem platform rather than the good one?

Something isn't adding up--either through misinterpretation on my part, or
because something's gotten confused somewhere.  Let's make sure we address
the right problem.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html