Re: freezes... (aka. taming the OOM killer)

Actually, just edit /etc/sysctl.conf and add the line:

    vm.overcommit_memory=2

At the bottom, save it, and then issue the following command as root:

    sysctl vm.overcommit_memory=2

And that will set it for the current session. =o)

On 11/7/06, Michael Blatt <[email protected]> wrote:
> Actually, reading man 5 proc reveals this:
>
> In mode 0, calls of  *mmap(2) <http://www.tin.org/bin/man.cgi?section=2&topic=mmap>*  with  MAP_NORESERVE  set  are  not
> checked, and the default check is very weak, leading to the risk
> of getting a process "OOM-killed".  Under Linux 2.4 any  nonzero
> value  implies  mode  1.  In mode 2 (available since Linux 2.6),
> the total virtual address space on the system is limited to  (SS
> +  RAM*(r/100)), where SS is the size of the swap space, and RAM
> is the size of the physical memory, and r is the contents of the
> file //proc/sys/vm/overcommit/*_*/ratio/.
>
> So setting it to 2 would be useless in this case since we are not on kernel 2.6, or have I missed something?
> :-/
>
> Shame that power management is still a problem in 2.6...
> Kristoffer, since you are playing with 2.6 on the J720, maybe you can confirm whether touchscreen and PM work?
> That has held me off using it for myself.
>
> Michael
>
>
>
> Michael Blatt wrote:
> > I suspected the OOM killer in 2.4 wasn't the smartest bit in the
> > kernel :)
> > Very clever trick, I should have thought about looking at possible
> > sysctls.
> > In fact I'm going to set it now (remotely) and check it out tonight.
> > The thing about the qpf fonts I need to check though. I think my fonts
> > are only qpf, but we shall see.
> > Keep us posted on how things are on your side after trying that tweak,
> > I shall do likewise.
> >
> > Michael
> >
> > June Tate-Gans wrote:
> >> Unfortunately the OOM killer in v2.4 of the Linux Kernel isn't exactly
> >> /intelligent/. Generally it tries to kill off the "least active" or
> >> "lowest priority" process first, and then moves down the line to the
> >> one with the largest consumption of memory at that moment.
> >> Unfortunately, Konq/E, OPIE, and ipkg are  (relatively) heavy in terms
> >> of resource usage (espeically ipkg -- it's a shell script that forks
> >> out to quite a few sub-processes just to function).
> >>
> >> I have the same issue when I'm running kdrive X, ion3, minimo, rxvt,
> >> bash, and apt-get. Interestingly enough, if kdrive is killed off with
> >> the OOM, the Jornada's screen seems to "freeze up" instead of cleaning
> >> itself up and returning me to a console.
> >>
> >> You might look into trying to reduce the amount of RAM that Konq/E
> >> uses by reducing the existance of varios BDF and TTF fonts on your
> >> disk. From the Konq/E FAQ:
> >>
> >> "The startup time of Konq/E is very slow when using Qt/Embedded. Is
> >> there a hidden turbo-boost configure switch to accelerate it to
> >> lightspeed?
> >>
> >> A lot of time on startup is spend on parsing the available fonts. To
> >> optimize this make sure Qt/E only uses the .qpf font files for fonts
> >> and no .bdf or .ttf fonts . This will decrease startup time
> >> dramatically and reduce memory usage. See the Qt documentation of
> >> details about .qpf font files and how to generate them."
> >>
> >> Also, to reduce the randomness and insanity that the OOM killer is on
> >> an embedded device like the Jornada, you might want to set the
> >> vm.overcommit_memory sysctl to 2. This has the effect of preventing
> >> the Linux kernel from "over allocating" RAM, freaking out when it runs
> >> out, and then using the OOM killer to free up memory by randomly
> >> killing processes. See <http://lwn.net/Articles/104179/> for more
> >> information on this trick. The end result is that instead of the OPIE
> >> main process being killed, whichever process is trying to allocate
> >> more RAM than is available in the system will kill itself since it
> >> won't be able to allocate any more.
> >>
> >> Much more graceful on an embedded device, IMHO -- and I'm going to try
> >> out that tweak this week, myself. =o)
> >>
> >> On 11/7/06, Michael Blatt <[email protected]> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> Which makes me think, since we were talking about the amount of RAM
> >>> on the
> >>> machine:
> >>>
> >>> I have a J720 with 32MB RAM, and, well, OPIE and apps do run out of
> >>> memory
> >>> on a regular basis.
> >>>
> >>> All it takes is a konq/e with a blank page, an opie-console and ipkg
> >>> running
> >>> at the same time, usually. What happens then, I reckon, is that the
> >>> kernel
> >>> decides to kill the qpe/opie main process and the UI freezes
> >>> completely.
> >>>
> >>> What's the best way of dealing with this, short of pulling the plug and
> >>> battery out?
> >>>
> >>> I can ssh into the box and restart opie almost every time this
> >>> happens, but
> >>> that is not always practical (and if I had another keyboard nearby I
> >>> wouldn't be using the Jornada at that precise moment, would I?).
> >>>
> >>> I haven't been able to think of a way to get the display and input
> >>> back to
> >>> the console when qpe/opie dies, which would be the lesser evil.
> >>>
> >>> Anyone with any idea how this could be done, or whether there is an
> >>> alternative?
> >>>
> >>>
> >>>
> >>> Cheers
> >>>
> >>>
> >>>
> >>> Michael
> >>> _______________________________________________
> >>> jornada mailing list
> >>> [email protected]
> >>> https://handhelds.org/mailman/listinfo/jornada
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>


-- 
June Tate-Gans    | Don't try to outweird me, three-eyes. I get stranger things
www.theonelab.com | than you free with my breakfast cereal. -- Zaphod Beeblebrox