Hello,
the OOM killer just killed some of my processes while the system still
had >2.5 GB of free swap. I'm running vanilla 2.6.15 on my desktop.
The machine is a single Athlon64, 1 GB RAM, 3 GB swap, x86_64 kernel,
(mostly) i386 userland. A few days ago I have set
/proc/sys/vm/swappiness to 0 to see whether it would increase the
interactive performance. This was successful to some extent but with
side effects as I just saw:
I was compiling QT4 in /tmp which is a tmpfs, size 2.5 GB, of which
~1.0 GB were used at that moment. This was when the OOM killer decided
to kill some (appearently random) processes.
I was able to reproduce this behaviour a few minutes later. After
setting /proc/sys/vm/swappiness to 10 everything is ok again. I have
attached the kernel messages of the oom killer.
Regards,
Jim
On 1/13/06, Jim MacBaine <[email protected]> wrote:
> Hello,
>
> the OOM killer just killed some of my processes while the system still
> had >2.5 GB of free swap. I'm running vanilla 2.6.15 on my desktop.
> The machine is a single Athlon64, 1 GB RAM, 3 GB swap, x86_64 kernel,
This is ok. When the swappiness variable is set to zero kernel does
not try to swap out processes. So once all memory is used up by
processes it can not free up memory by swapping and hence had to kill
process.
Regards
Ram Gupta
On 1/13/06, Ram Gupta <[email protected]> wrote:
> This is ok. When the swappiness variable is set to zero kernel does
> not try to swap out processes. So once all memory is used up by
> processes it can not free up memory by swapping and hence had to kill
> process.
It _would_ be ok if swappiness == 0 would mean that the kernel will
not swap at all. That's not the case. Even without an excessive use of
tmpfs the kernel found ~250 MB of unused memory which it swapped out
during the last days with swappiness == 0.
Regards,
Jim
On 1/13/06, Jim MacBaine <[email protected]> wrote:
> On 1/13/06, Ram Gupta <[email protected]> wrote:
> It _would_ be ok if swappiness == 0 would mean that the kernel will
> not swap at all. That's not the case. Even without an excessive use of
> tmpfs the kernel found ~250 MB of unused memory which it swapped out
> during the last days with swappiness == 0.
>
> Regards,
> Jim
>
I correct myself. swappiness == 0 does not mean that kernel will not try to
swap at all but this value decreases the swapping.
swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
swap_tendency depends on swappiness and affects the memory reclaimation.
Regards
Ram Gupta
In linux.kernel, you wrote:
> the OOM killer just killed some of my processes while the system
> still had >2.5 GB of free swap. I'm running vanilla 2.6.15 on my
> desktop. The machine is a single Athlon64, 1 GB RAM, 3 GB swap,
> x86_64 kernel, (mostly) i386 userland. A few days ago I have set
> /proc/sys/vm/swappiness to 0 to see whether it would increase the
> interactive performance.
I have to say I've noticed the same thing.
On my home workstation I do a lot of stuff with very large video
files, so set swappiness to 0 some time ago so using these large files
would stop all the applications getting pushed out into swap.
However I've noticed that ocassionally the kernel has killed large
memory processes (eg firefox!) even when there was lots of swap free.
Recently, I found I just could not use gimp to edit a very large image
(about 800MB on a 1 GB machine) without the OOM killer killing it.
When I reset swappiness to 60 I could then use gimp fine.
This doesn't seem like correct behaviour to me! (Though I note the
caveat I read somewhere that swappiness probably doesn't do what I
think it does - it probably doesn't!)
--
Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick
On 1/14/06, Nick Craig-Wood <[email protected]> wrote:
> On my home workstation I do a lot of stuff with very large video
> files, so set swappiness to 0 some time ago so using these large files
> would stop all the applications getting pushed out into swap.
My motivation was similar: My desktop usually runs 24 hrs and I leave
large applications which I use from time to time always open. Like
OpenOffice, Firefox, Emacs with large buffers, etc. In the night, the
machine performs two disk-intensive tasks. First a backup then
updatedb. And every morning about 650 MB of 1 GB RAM is used for
caches and all my application need to be swapped in before I can use
them.
Of course, the increase of disk cache is reasonable for those tasks,
but honestly, I don't care whether the updatedb process takes 10 or 20
minutes in the night. But I do care if switching between applications
needs >10 seconds in the morning.
Would it be possible to trigger paging in specific applications from
userspace? So I might run something like
echo -n firefox-bin > /proc/sys/vm/page-in
echo -n soffice-bin > /proc/sys/vm/page-in
...
after my nightly cron jobs have filled the memory with disk cache data
that won't be useful anymore, because in my daily work I rarely touch
10% of the filesystem.
Regards,
Jim
On Saturday 14 January 2006 15:53, Jim MacBaine wrote:
> On 1/14/06, Nick Craig-Wood <[email protected]> wrote:
>
> > On my home workstation I do a lot of stuff with very large video
> > files, so set swappiness to 0 some time ago so using these large files
> > would stop all the applications getting pushed out into swap.
>
> My motivation was similar: My desktop usually runs 24 hrs and I leave
> large applications which I use from time to time always open. Like
> OpenOffice, Firefox, Emacs with large buffers, etc. In the night, the
> machine performs two disk-intensive tasks. First a backup then
> updatedb. And every morning about 650 MB of 1 GB RAM is used for
> caches and all my application need to be swapped in before I can use
> them.
>
> Of course, the increase of disk cache is reasonable for those tasks,
> but honestly, I don't care whether the updatedb process takes 10 or 20
> minutes in the night. But I do care if switching between applications
> needs >10 seconds in the morning.
>
> Would it be possible to trigger paging in specific applications from
> userspace? So I might run something like
>
> echo -n firefox-bin > /proc/sys/vm/page-in
> echo -n soffice-bin > /proc/sys/vm/page-in
> ...
Crude, but may work:
swapoff -a
swapon -a
> after my nightly cron jobs have filled the memory with disk cache data
> that won't be useful anymore, because in my daily work I rarely touch
> 10% of the filesystem.
--
vda