[vox-tech] Three Install Questions

[Karsten M. Self]

on Fri, Feb 18, 2005 at 07:34:13PM -0800, Mark K. Kim (lugod at cbreak.org) wrote:
> On Fri, 18 Feb 2005, Wilson Shealy wrote:
> 
> > 1.  Are there any disadvantages (except disk space) to having an
> > oversized Swap partition?  I've decided to double mine so that I can
> > double my RAM at a future date.
> 
> I'm just gonna tackle question #1.
> 
> First off, most people don't think there's a problem having too much swap
> partition, but I don't think anyone here really has hard data.  I don't
> have hard data here either, so take everyone's remark with a grain of
> sand.
> 
> Second, Rod is right -- you'll end up using more RAM for page tables.  In
> this particular case, it's not going to impact your system that much since
> you're only doubling your swap size.  So don't think it's okay to just
> keep increasing swap partition size and not impact your system.  There's
> some OS notion of paging the page tables but I'm not sure if Linux uses
> it.

Speaking to this specifically:  used to be that if you specified too
much swap, you'd actually chew significantly into usable RAM to support
the (in-memory) references to swap space.  This is probably back in 2.2
kernel days, my understanding is the situation's improved markedly, but
I'm well out of my depth discussing this.

My own recommendation is that you:

  - Run with typically 1x - 2x RAM for SWAP, modulo edge cases.  If
    you've got little RAM on the system, (say, < 96 MiB) you might want
    to allow for 4x RAM in swap.  If you've got gobs (currently, say, >
    4 GiB) RAM, you might allow somewhat less.  More on this.

  - Create sufficient SWAP partitions (or files) to allow 1x-2x your
    system's *max possible* RAM, not the current configuration.

  - Create multiple swap partitions, sized to roughly the amount by
    which you'd increment RAM.  So if you've got 512 onboard, and max at
    2BG, create from 2-4 512 MiB swap partitions.

  - You don't need to mount all your swap.  It *is*, however, easier to
    edit your /etc/fstab, or run a 'swapon' command from shell, than it
    is to repartition your disk to add swap later.  So create additional
    swap partitions even if you don't plan on using them immediately.
    Or ever.  You can always repurpose them to auxiliary storage.  The
    cost, at current disk prices, is only a few dollars worth of
    storage.

Finally:  regardless of how much memory you've got:

   Your system will run better with swap than without it.

The short explanation is that swap allows the kernel to better balance
VM usage.  See Martin Pool's excellent essay on this subject, "Is Swap
Space Obsolete?"

    http://sourcefrog.net/weblog/software/linux-kernel/swap.html

 
> Third, as the size of the swap space increases, its usefulness drops.
> The only way for you to utilize all the swap space is if you end up with a
> really large program/data, or lots of small programs, or a combination of
> both.  

I keep seeing people say that.  I keep experiencing the opposite:
regardless of how much RAM I've got, I pretty much start filling it.
Currently, with 1 GiB RAM:

               total       used       free     shared    buffers     cached
  Mem:        972336     958792      13544          0     119980     130676
  -/+ buffers/cache:     708136     264200
  Swap:      1060208     554116     506092

That is, I'm using > 72% of my RAM, and nearly half my swap.

What's running?  350 processes, lots of spamd, a couple of browser
sessions, mutt, apt-get.

My point:  you'll eat RAM for lunch.  Sure, you can tune your system and
get rid of processes.  But your system's there for you to use, and even
basic activities --  web surfing, mail, graphics, office tools -- will
go through a lot of it.

The nice part is that GNU/Linux seems to do more with, and behave better
with  less, memory than 'Doze.

> You wouldn't want to run lots of small programs together to fill up
> your swap space since you'll either end up having to put most of them to
> sleep, or each small program will constantly swap in-and-out and bring
> down your system to a scratching halt.  

Again:  my experience is that this isn't the case.  Running vmstat, I
find that paging in and out of swap is relatively infrequent.  For small
programs, the hit taken by paging a few blocks in and out of swap will
be small anyway.  A large program -- sure, you're going to wait a few
seconds while it comes up, if you haven't been working with it for a
while.  Most people's work habits involve cycle times between tasks
which are much larger than swap cycles.


> A large program (or several large programs) will probably utilize
> large swap space better since most of the program will stay in swap
> space and only the portions you do use will load up in memory.  But
> even in that case, you'll want all the used portions of the program in
> RAM.

GNU/Linux paging, as I understand, is demand-based, and programs don't
page in and out fully, only the parts which are/aren't being used, in 4K
chunks (Martin's essay covers this).

My undestanding is also that paging is opportunistic.  Borrowing from
_In Search of Clusters_ by Gregory Pfister (which deals with clusters,
not Linux VM specifically, but distributed memory management is a big
part of cluster management), it's like making space for a new project on
a dirty desk by randomly grabbing a file and parking it in the credenza
across the room.  Turns out that randomly grabbing a file is more
efficient than spending a lot of time figuring out which files won't be
used.  If a file (memory page) _is_ needed, well, you'll just re-fetch
it.  If it's not, it stays in the credenza.  Eventually, over time, you
end up with frequently-used materials on the desktop (in memory) and
infrequently used materials in the credenza (in swap).

...unless you don't have enough desktop space (insufficient memory), in
which case you're spending a lot of time running between the desktop and
credenza (swapping).


> So let's look at the scenario where you have several large programs
> running concurrently on your system.  To get the best performance out
> of your computer configuration, you would want all the used portions
> of the programs in RAM and the rest in swap.  Assuming that 30% of all
> the running programs (or more accurately processes, shared libs, etc.,
> except for the kernel which you have to count 100% because it never
> gets swapped) are actually used and the rest are not, you'd want your
> ideal swap partition to be (100%-30%)/30% = ~3 times your RAM size.
> Speaking really broadly, any more than that and there will be some
> sluggishness or wasted swap space; any less and you'll be running out
> of memory.  Of course, some sluggishness is okay, but too much will
> definitely make the computer unusable.

I'm not sure that logic holds up, though I don't disagree with the
results.  I'm not sure that your list of swapped processes is
necessarially fixed.  In my case, *most* of my 350+ processes are
hanging out on swap, most of the time.

My rule of thumb is this:

  - I want sufficient swap that I rarely if ever run out of VM.  On my
    desktop, keeping issues down to > 1 per month or two is probably a
    reasonable incident rate.  In a larger shop, you're going to balance
    support needs with memory costs...

  - I want sufficient memory that I'm rarely stuck in a high-paging,
    high-iowait state.  Again, a few minutes every month or so is
    acceptable, beyond that is going to start getting annoying.  Again,
    business environments vary, but if you've got users spending minutes
    waiting for different tasks to swap in or out (a situation I've seen
    frequently on legacy MS Windows XP), there's a problem.

  - Once I've met these goals, with a margin for slop, allocating
    additional swap is waste.  Given price for disk (cheap, cheap,
    cheap!), you can err on the high side, slightly.

I come up with about the same numbers (1-3x RAM)

> I'm just speaking broadly and those numbers are just made up.  I'm
> just saying you DO have a reason to stop increasing your swap
> partition size at some point -- just keep increasing won't give you a
> proportional return for your investment because you'll either end up
> with a really slow computer or wasted investment.  

More likely the latter.

Adding swap isn't going to slow you down -- *that* is caused by
insufficient RAM, and constant swapping (paging) of data between memory
and disk.  Been there, done that, it's ugly.  GNU/Linux's OOM is still
somewhat poor in this regard.

> At some point, you'll want to actually invest in RAM rather than your
> swap space.

Agreed.  For desktop use, 128 MiB (light browsing / email) / 512 MiB 
(typical browsing / email / office) to multi-GiB (multimedia work).

Light-use file / print / firewall servers (typical SOHO use) can
actually get by on markedly less.  96 MiB should be plenty for most
needs.  Adding shell or X/VNC sessions would increase that markedly.


Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    The revolution will be no re-run brothers;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20050220/4a334f29/attachment.bin