[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Query about existence of way to free up unnecessary RAM usage



Don Armstrong <don@debian.org> writes:

> On Tue, 09 Sep 2014, lee wrote:
>> Why would 40GB be too much?
>
> It's probably too much, unless you have processes which allocate lots of
> memory and then use it very infrequently or you have incredibly fast
> disks.

It works fine, only can slow the system down very much --- which is the
purpose.  It doesn't matter much when a bit of the swap space is used in
terms of performance, that's "normal operation".  But when some
process(es) suddenly require lots of memory, I *really* prefer it
becoming slow over it going down or becoming unstable.

When you have "incredibly fast disks", you want to have only a
relatively small part of your swap on those (like 8GB, for example)
because the swap space on them can also fill up "incredibly fast".  I
would put the remaining 56GB on slow disks.  (You can set priorities for
swap partitions.  First use the fast ones, then the slow ones.  That
does work fine.)

>> I have 8/64 so I can use swapping to slow down the downfall of the
>> system.
>
> The system won't go down unless you've disabled the OOM killer or
> discovered a kernel bug. [Granted, processes will be killed off, but
> that's to be expected.]

Yes, and the killing can result in the system becoming unstable, or it
might go down.

"Go down" can have various meanings.  When you run a server and a server
process (like an MTA or an IMAP or web server) is killed because the
system runs out of memory, the server is effectively down.  It may not
be unstable (though I consider a system without an operational MTA as
non-functional), yet you never know what process will be killed.  You
could have ZFS with fuse, and what prevents such processes from being
killed?  I have seen it happen, long ago, that my system became unstable
because it ran out of memory.

> Generally speaking, you want enough swap so that infrequently used
> memory can be offloaded to disk, but not so much swap that your
> computer stops being responsive when you begin to run out of free
> memory.

It doesn't work that way.  When your system just begins to run out of
memory, it will swap out a bit as needed, no matter how much swap space
you have, unless you have none.  What is swapped out at that point may
be infrequently used data.

The system doesn't swap out more than otherwise when you have more swap
space (see below).  At some point, you either still have enough swap, or
the system may go down.  With 64GB of swap (see below), it's less likely
to run out, and before it does, it becomes so slow that I will notice
(when I'm using it) and have a chance to do something about it before it
does run out.  When I'm not using it, the 64GB may yet be enough for the
system not to run out of memory.

Doing something may take a while because the system will be slow when it
swaps out lots of data.  It's nice to have a cushion because it may
(will) continue to fill the swap space while I'm trying to do something.
(I start to notice when something between 7 and 12GB are actually used
in total.  My disks are rather slow.)


[~] uptime ; free -m
 01:30:55 up 5 days,  6:00,  3 users,  load average: 0.04, 0.04, 0.09
             total       used       free     shared    buffers     cached
Mem:          7982       5303       2679          0         82       3790
-/+ buffers/cache:       1430       6552
Swap:        65535         67      65468


This is from a VM, and you can see how it kinda gets tight already:


root@gulltop:~# uptime ; free
 01:31:24 up 4 days,  4:38,  2 users,  load average: 0.06, 0.03, 0.05
             total       used       free     shared    buffers     cached
Mem:       2050596    2003600      46996          0      60084     855408
-/+ buffers/cache:    1088108     962488
Swap:       975860       2604     973256
root@gulltop:~# 


The system and all the VMs are on rather small disks, or they would have
more swap (the server should have more RAM, too).  Those are 2x15k RPM
SAS disks in a hardware RAID-1, which is fast and thus does fill fast.
The web browser (seamonkey) running on this VM (display is on my
desktop) just eats ridiculous amounts of memory.  Yet it takes only 1/2
second to start :))

Open too many tabs, and the VM --- or least the web browser --- will go
down --- *before you notice*.


-- 
Knowledge is volatile and fluid.  Software is power.


Reply to: