Select ~4,000 image files in file manager (to delete)
- but with 'Show
As Thumbnail' selected - managed to kill an E6300 (Dual-Core 1.86GHz
w/2GB RAM and 2GB SWAP).
Should be ~4GB - but 'top' was only showing
2GB in-use/useable - should
I have split the 4GB into 2x 2GB SWAP partitions for GNU/Linux to
utilise it all?
In general, I'd say this much swap is not a good thing. Even 2 GB of
swap will give you problems, realistically. If you ever get to the point
where you are actively using that much ram and are paging out to 2GB or
4 GB of swap, your system will probably be useless anyway, due to heavy
paging to disk. Far better to let the oom-killer take effect earlier in
There used to be rules like "The kernel needs twice as much swap as
ram", but they only applied for early 2.4 kernels, and they certainly
don't apply any more, despite often being quoted as current. It's not
even really a good guideline these days, because systems with lots of
ram are so common. Between 512 MB and a gig of swap is probably good -
this will mean any applications which aren't being used at all can be
paged out of active ram, freeing up the ram they were using for actual
use, and it gives you a good tradeoff as processes that run amok, using
up lots of ram, get killed that much quicker.
c) Can anyone explain in nice laymans terms the
correct use of the 'Alt
+ SysReq' and 'Alt + S' and 'Alt + U' and 'Alt + B' key
sequence (I used
this to (I think) tell the machine to safely shut down).
I'm picking you needed to use this because the system was so
unresponsive... and that was probably because it was spending most of
time pushing things in and out of swap.
However, the oom-killer doesn't kill the system, or the kernel. It'll
kill processes that try to request memory when there is no more left -
which is why it killed the process "passkey-agent" in your pasted log
snippet. As I suspect all of your processes were running under your X
session, you could have killed X instead (via ctrl-alt-backspace, for
example). This may not have left your system in a usable state, due to
other processes having been killed, but it would have been safe to
reboot it normally from here.