[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange memory consumption
On Wed, 25 Feb 1998, Ariel Biener wrote:
PLEASE STOP CC-ING IF SENDING TO THE LIST.
> On Sun, 22 Feb 1998, Peter L. Peres wrote:
>
>
> > Just a wild guess: You are running an 'all-X' system. There was a bug
> > somewhere in init that made it go berserk if there was nothing open on a
> > console once upon a time. The bug caused very high load w/o reason, but no
> > memory leaks. The remedy was, to leave a login (getty whatever) in
> > inittab on the X-only runlevel. It's also possible that there is a problem
> > with the chipset and/or caching with that much ram. Dejanews ?
>
> Actually, that stupid bug manifests also when you do have a few vc's and X
> too. But, when it does, the process X is about 95%-98%, and that shows
> nicely on top. For example:
>
>
> 1:39am up 30 days, 6:31, 13 users, load average: 0.30, 0.29, 0.31
> 83 processes: 78 sleeping, 3 running, 1 zombie, 1 stopped
> CPU states: 17.8% user, 110.3% system, 118.5% nice, 0.0% idle
> Mem: 47032K av, 46024K used, 1008K free, 30128K shrd, 3756K buff
> Swap: 102812K av, 15156K used, 87656K free 11204K cached
>
> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
> 25460 root 19 0 12688 11028 872 R 0 99.9 23.4 16629:03 X
>
>
>
> So, if you have a more elegant fix (don't tell me to Install Accelx 4.1 :)
> please tell me.
The rules of the game say that first you have to find out WHAT causes the
load. My $0.02 hunch is a misconfigured pointing device, which is usually
read in a tight loop by X, and can cause this kind of ****. Can gprof or
such be run on X to find out what it is up to ? I think it can, because X
does not fork (but it's compiled with > -O2, so gprof can't follow it
there).
I think that backgrounding or renicing the processes run by X at this time
one by one should find the problem. (Tell the users, though, or you'll get
a BOFH award).
I've never really seen this on my own system, but that doesn't mean much.
Peter