RE: Where do you put your swap partition?
On Jan 23, 2008, at 1:40 AM, Ron Johnson wrote:
> Rick wrote
>> On my own systems, I make swap huge (10 GB or more for 1 GB RAM --
>> Disk
>> is cheap!) so I can mount /tmp on a tmpfs file system.
>
> ????
>
> Is this for apps that say "if malloc() fails, I create a tmp file"?
> IOW, you pretty much ensure that malloc() will never fail?
That's one way of looking at it. It may be my old fashioned UNIX
based superstitions, but I remember some benchmarks from ten years or
more ago that showed putting /tmp on a tmpfs filesystem dramatically
sped up things like compilers shell scripts and other programs that
wrote small short-lived temporary files to communicate between passes.
If you have /tmp on physical disk (e.g. an ext3 filesystem) the
process of opening a file for writing, writing it, closing it, re-
opening it for reading, reading it back in, closing it and deleting
it, hits the disk several times, even with a large buffer cache. But
if that file is in a tmpfs filesystem and you've got enough ram, the
disk never gets involved. If it's in a tmpfs filesystem but you
don't have enough ram, you have to swap, but you're no worse off than
you were with the disk-based filesystem.
Given that logic, and the fact that tmpfs is limited by the size of
swap plus the size of ram, and the observation that disk is cheap and
getting cheaper, why not make swap as big as you're ever likely to want?
Of course, now-a-days the gcc compiler does its thing entirely in
core -- swap if you must but no temporary files ever. So the
benchmarks may not apply.
I'm gettin' old...
Rick
Most things stated in this chain are true. But a couple notes. First, a
swap partition is not the same as a normal partition, i.e. ext2 or ext2.
That is, in Window's speak, it's not formatted. Process chunks that are
swapped in and out of swap does not go through the filesystem manager. The
kernel directly manages that space. It treats that disk space as a raw
disk. Much faster than going through the read/writes to a normal file. You
can create a swap file, but that's much slower than swap space, because it
has to go through the file system. That's one of the reason MS Windows is
so damn slow. In this case bigger isn't always better. I would prefer a
system with multiple disks that a system with giant disk. As an example,
that would allow me to have the root partition on one disk, /usr on another
disk and /var on a third, and have swap space defined on all three. This is
just an example, but you should be able to catch my drift.
If speed is a concern using swap space, then more speed can be had if you
create multiple swap spaces on different disks. That is, as an example, 2
separate swap 1 gig partitions, of the same priority, on 2 separate disks is
faster than 1 2 gig partition on 1 disk. Here, the key is spindles. In the
method I suggest, swap is written interleaved between the 2 swap spaces,
than just serially written to a single swap space.
And one other thing. Virtual memory has not always been in unix. That came
quite a few years after Unix was first created in the mid '60s. It has
always been noted, to speed up a unix system, add more ram. But even with
the low cost of ram, it's always good practice to have swap available. It's
better to have it and not need it, then to need it and not have it. It's
rather difficult to manage an unresponsive system when it has exhausted
memory. There isn't a Unix SA, worth his salt, that would run a system
without swap space.
And I'm curious, what's the reason for encrypting swap space when swap only
contains code and data fragments, in no particular order, known only to the
kernel? Seems to me that you are only slowing down what's already
indecipherable anyway. Now keep in mind, I'm not talking about something
like /tmp configured in a tmpfs.
The 1 1/2 to 2 times ram for swap space is a good rule of thumb. If it's
good enough for Unix, it's good practice for Linux. But then again, a home
user doesn't anywhere come close to approximate the business environment.
But if it works for business, it'll work in the home.
-mike
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: