Originally Posted by elishac
May I ask a quick question : what happens if the memory and swap are full ?
To discuss that topic, you should first understand the distinction between "committing" memory and using it. The system normally commits significantly more memory than it uses.
When any process requests use of memory, the kernel must decide whether to commit memory for that request, but it doesn't actually allocate any specific memory at that point. If too much memory has already been committed, the kernel will reject the request, which normally causes the process that made the request to fail.
For various reasons, processes typically use only a fraction of the memory they request. Actual memory is allocated (possibly forcing previously allocated memory out to swap space) only as the process actually uses each 4KB page of memory.
Most systems are configured to allow significant over commit of memory, so as processes use memory that they previously requested, the swap space might fill up and the system might need to push still more pages out to swap and be unable to do so. At that point the "Out of Memory Killer" component of the OS will select and kill some process in order to prevent the whole system from deadlocking.
So the common symptom of filling up ram plus swap is some process will get killed. This usually will not
be the process whose recent increase in memory use pushed the system out of memory.
But sometimes the limiting factor will be the commit level, rather than the actual use of memory. So a process will fail when requesting memory, possibly when actual use of memory is far short of full.
In theory, a process could be coded defensively to deal with a failure when requesting memory. So in theory it is better to fail that way than to invoke the out of memory killer. But in practice programs don't deal well enough with memory request failures to show any real benefit. So failing a memory request is just as bad as invoking the out of memory killer.
would it be better to have a specific number for the swap space, (like 10^n or 2^n), or does it not matter ?
it is said that the partition sizes are in megabytes (10^6 bytes)
Partitions are normally allocated in whole cylinders rather than in exactly the number of MB you request. Swap space is used in whole 4KiB blocks. So there is likely a little waste that you can't reasonably control. But disk space is normally cheap enough that you shouldn't care at all about that level of detail.
Deciding on swap partition size is usually a wild guess. The best size depends on the way you will use the system and almost no one knows that level of detail about their intended use of their computer.
The various common rules, such as "twice ram size" for small ram systems, or "2GB is usually enough" for large ram systems, have no real validity. I guess it is easier to follow such a rule than to make a wild guess yourself when you have no real basis for an informed decision.
The amount of swap space you need depends on the memory use of the processes you will be running. You don't know their memory use in advance, so you're stuck guessing.
I think the size and expected use of your disk space should be a bigger factor in making that guess:
If you have a 30GB drive, then selecting a 4GB swap partition when you only needed 1GB would be wasting 10% of your disk drive. If you have a 600GB drive, the same mistake would only be wasting half a percent of the disk drive. I would rather waste half a percent of the disk drive than even think about the question of whether 4GB is too much swap. But I'd rather risk killing some process and then needing to reconfigure the partitioning (once I understand memory use better) than wasting 10% of the disk.