>If you have 500MB of memory, you must be intending to run some
>serious applications or will be putting the system into a
>server role. If the memory is not overkill for what you
>are intending to do, then having more swap may be extremely
>useful and you should consider an additional 500MB-1GB of swap
>For example, a 500MB machine may be excellent as an application
>server for a small workgroup, but you still want a good deal of
>swap space in case your users grow accustomed to being able
>to iconize and suspend applications when not in use, instead
>of closing the applications. Usage habits adjust to available
Actually, you don't tend to run end-user applications on a
server; It's primarily there to deal with delivering files.
Mind you, you can also run a database server, too, but 500MB
would provide a sh*tload of cache space for indices (assuming
you can talk the DB engine into maintaining that kind of a
cache in memory).
Quote:>I believe the x2 rule comes from the theory that any additional
>swap space above x2 is not useful - the system will spend all its
>time page faulting instead of being useful. So, you should
>consider x2 as the upper bound, and not a suggested minimum.
In Linux, the paging space isn't shadowing the main memory
(unlike older Unix systems and XENIX); The paging space is
in addition to the main memory (I keep wanting to say "core").
So, 500MB or RAM + 500MB of paging space = 1000MB of virtual
Unfortunately, however, things get worse quickly; If you're
gonna go for a 2:1 overcommitment ratio, well, have lots of
drives and distribute the paging spaces across them as flatly
as possible (the larger an individual space, the more latency).
Latency in paging space is more poisonous than elsewhere since
we're stalling a LOT of regular I/O pending this one fetch.
BTW, a memory OCR of 1.5:1, if used, is real close to thrashing.
While 2:1 can be nice, it only buys you a little bit of time
to bring a thrashing system under control.
Oh, yes, please remember (assuming my memory is correct) that
the code segment of each executable that is running is part of
the paging space; Since code is nominally read-only, it doesn't
get stored to the paging volume but, when needed again, gets
sucked in from the executable program file. Heck, when you
start up a program, the process only loads one code page (the
first one) and the rest of the program is loaded via page faults.
This is one reason you can't delete a running executable (or
write into it, either).
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
Disclaimer: I'm just a consultant at the bottom of the food chain, so,
if you're thinking I speak for anyone but myself, you must
have more lawyers than sense.