Re: [K12OSN] Random logouts, inability to log in

[Les Mikesell <les futuresource com>]

Which value do think indicates a problem?  I don't run a
lot of ltsp terminals but under other conditions I never
see any memory-related issues until most of swap has been
consumed which doesn't seem to be the case for you.  That
large inactive buff value should be memory available for
reuse if anything needs it.  I wonder if there is some
kernel tuning value that is inherited from the old system
that would be different in a fresh install?  If you
haven't downgraded yet, can you try running the kernel
tuning tool (system tools/more tools/kernel tuning)
and under virtual memory/swapping, check the
"overcommit memory" box.  Also see if the other memory
related settings look reasonable.  The overcommit
change will defer the 'kill some process' syndrome until
programs actually access all of your virtual memory instead
of when the first malloc() it which they sometimes do just
to see if it is available.

  -Les 


On Thu, 2004-01-01 at 09:12, Julius Szelagiewicz wrote:
> Norbert,
> 	the values are real, so is the problem. julius
> 
> On Thu, 1 Jan 2004, norbert wrote:
> > Julius,
> >
> > You made up those values, didn't you ? :-)
> >
> > norbert
> >
> > julius turtle com wrote:
> >
> > >On Wed, 31 Dec 2003 jam mcquil com wrote:
> > >
> > >
> > >>I've been watching your story, and it seems like we should change
> > >>your name to Julius Murphy.  Cuz you've shown that whatever can go
> > >>wrong will go wrong.
> > >>
> > >>How about you hop on the IRC channel and we can discuss what's
> > >>going on.
> > >>
> > >>I don't know anything about evolution, but sometimes just
> > >>talking about it in realtime will bring new things to light.
> > >>
> > >>The channel is #ltsp and the server is irc.freenode.net
> > >>
> > >>I'll be around most of the weekend (including right now).
> > >>
> > >>
> > >>
> > >Jim,
> > >    thanks for the invitation, I'll bother you, since you ask nicely
> > >;-)
> > >    I am planning to play some more on weekend - tonight is already
> > >spoken for, so's most of tomorrow (wifes are people too, you know). I will
> > >give you a half a screen from to to ponder - it shows that either top is
> > >broke or that memory allocation / deallocation procedures are not healthy.
> > >this is top from the production system that has *nobody* actively working,
> > >9 users forgot to log out. take a look at this scary values:
> > >
> > >127 processes: 126 sleeping, 1 running, 0 zombie, 0 stopped
> > >CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
> > >           total    0.0%    0.0%    4.8%   0.0%     0.0%    0.0%  394.8%
> > >           cpu00    0.1%    0.0%    1.9%   0.0%     0.0%    0.0%   97.8%
> > >           cpu01    0.0%    0.0%    1.9%   0.0%     0.0%    0.0%   98.0%
> > >           cpu02    0.0%    0.0%    0.9%   0.0%     0.0%    0.0%   99.0%
> > >           cpu03    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  100.0%
> > >Mem:  3878512k av, 3843396k used,   35116k free,       0k shrd,  197988k
> > >buff
> > >       242972k active,            3383200k inactive
> > >Swap: 1831368k av,   22572k used, 1808796k free                 3341956k
> > >cached
> > >
> > >
> > >_______________________________________________
> > >K12OSN mailing list
> > >K12OSN redhat com
> > >https://www.redhat.com/mailman/listinfo/k12osn
> > >For more info see <http://www.k12os.org>
> > >
> > >
> >
> 
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>