Slashdot Mirror
Ask Slashdot: Linux and Swap Optimization?
I found a nameless submission in the
submission box that asks a fairly good
question:
"I'm installing Linux for the first time on Intel
hardware (I've installed Linux for PPC and BSD for Intel
and 68K) but I am confused on how the swap partition
should be handled for optimum performance. The Linux
Installation Guide says I should have my swap at least as
big as my RAM and that the swap partition should not be
bigger than 127MB. Also a "rule of thumb" answer I got
from my BSD using friends is that my swap should be twice
the size of my RAM. Since I have 128MB of RAM should I
have two swap partitions? Also how will swap drive
performance affect system performance? Would a Fast SCSI
(20MB/s) swap drive be any different than a Wide SCSI
(40MB/s) swap drive? There seems to be little information
on how to 'tune' Linux swap for machines with 100+ MB RAM."
is the machine more workstation or server orientied.
what kind of apps are you (or the person) running.
that is a very good size of ram. I would personally start out with 127 mb on a HD that the swap would be the primary thing accessed on it with the most BW. Then I would monitor system performance and lead on from there
The 2X memory swap rule only applies to certain Unix systems which require swap space associated with a give amount of memory. I don't think this is true with Linux which has a different architecture. If drive space is plenty then I suggest making a 127MB partition and being over it unless you see more demand based on your applications.
Don't use a swap partition. Very hard to manage if u want to make changes later. Use swap file instead. Same performance. Of course use a seperate physical hd no bigger than 500MB.
See mkswap man page for details.
Size? Same as actual RAM.
Hmm. Why is this limit critical? I set mine to 128 MB, and ended up with 133+MB swap. Does this cause a performance problem?
For a machine that is used, buy a little more memory than you think you will use during heavy usage. Swap is pretty hard to say exactly but make sure you allocate enough. I was running wusage on some site logs and it ran out of memory after 20 hours of cpu time on a machine with only 64 meg mem and 64 meg swap. Not the kind of thing you want to see. If you have lots of processes that may sit around sucking up memory but not active all the time, they can sit in swap. Also if you want to be accessing lots and lots of files (especially from a CD changer), make sure to account for disk cache.
/etc/fstab. The manpage for swapon(2) has more info about the swapping but swaps with equal priority will be interleaved while one with a higher priority will be used before a lower priority. Maybe you could have a swap area on your main disk that is used for emergencies only which would have a low priority.
For multiple swap partitions, set 'pri=1' for all of them in
Also, I'm pretty sure this problem still exists but if your drive with swap fails and the kernel needs to get that page, the system will crash. For HA systems you may want to use an outboard raid array. I don't believe swap runs on software raid.
The new linux kernels (2.2 and above) do not have
the 128M size limit. You also need a new version
of mkswap to allow bigger swap (partitions or files). I don't recall what the new limit is,
probably around 2G bytes.
note that i use windowmaker and *not* KDE/GNOME and also note that netatalk serving files over afp is not exactly a memory hog. YMMV...
The biggest hassles I've had with linux have been corruption occuring in swap partitions. I put in two now just to give myself room to manuever if the problems begin.
Got imagick and a lot of mem stress test the system with 'convert xxx.mpg ppm'. Bring up 'top' and watch the 'magic00xxx' files in /tmp.
= == = ==
DO NOT DO THIS ON A PRODUCTION SERVER.
Never thought I'd see 4 127M swap's get eaten up!!! Kinda gives you a feel for the machines swapability factor (which probably varies lots with different ardware mixes).
===============================================
Time flies like an arrow, but fruit flies like a banana.
===============================================
Granted, if you don't expect swapping (like most single user boxes with 128MB) it could very well be worth using a swap file instead of a swap partition for the flexibility, but...
Doesn't using a swap file instead of a swap partition add the overhead of having to go through the filesystem layer of the kernel instead of going straight to the raw partition though, thereby reducing swap performance?
If not for Linux, I'm curious about other OSes if anyone else out there knows about whether swap files have to go through the filesystem layer. Recent Solaris, WinNT 4.0, Win 2k, other common OSes?
Also, what about swap file fragmentation? A heavily fragmented swap file will kill performance. I know this under NT all too well.
Ironically enough, for that reason I put my pagefiles at work under NT on their own partition (with tmp and browser caches too actually since they fragment the hell out of the hard drive too).
But then again, if you don't expect to swap...
strcat!
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
True, it can then run on top of software raid (which could of course stripe the swap file), but that's yet one more layer (the RAID layer). The flexibility would also be likely lost because RAID0 would be probably be wanted to be used (simple striping) to not incur the overhead of the redundancy (but reliability) of something like RAID5.
:). I'd be interested in seeing some actual benchmark comparisons of the two setups though.
Since most reasonable people wouldn't want to put their important data on a RAID0 set the RAID0 would have to be partitioned off from the rest of the data. So you're back to square one. Seperate partitions.
I can't remember where, but when I remember when I set up RAID at home I read somewhere that it's more efficient to unleash Linux on multiple partitions with the same priority and let the kernel handle the striping itself instead of RAID.
It makes sense to me
strcat!
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
I use another Unix besides Linux, but isn't it usually a good idea to make your swap as big as your physical memory inorder to improve chances of a kernel core fire being written to /tmp which is tied to swap?
First, Yes, WindowsMaker really is that light. It also does not provide all the same services that KDE or Gnome provide.
Back to the real issue - what are you doing to swap so much with KDE. I've only got 64meg ram and with KDE, Netscape and SO5.1 I only swap about 16meg.
Uh... recent drives can transfer twice that. I have a 9LZX LVD SCSI3 device that is on an Ultra Wide chain (not U2W) and it transfers at 19MB/s. The fastest is the Altas 10k which transfers around 22MB/s sustained.
My KDE desktop is only taking 14meg swap total. And that is because it has a file/web manager running...
Actually, you're quite wrong on your second point. Linux does memory overcommit (meaning that you can run far more than would actually fit into physical + swap).
You're right about Solaris not doing memory overcommit though. Couple that with the stupid tmpfs for swap space, and you have to be extra-careful that your swap is big enough under Solaris.
You might as well be using a 128meg swap partition because that's all that linux will use in a swap partition.
If the drive your normal swap partition is on dies, your system goes with it! I've had a drive fail under software raid-5 and it dumped an error in the syslog but everything kept running fine. Had it not been for the error, I wouldn't have known the drive went south.
Is it ok to use a logical partition?
Well, it sounds logical. [Oh god that was bad.. sorry] It really doesn't matter because Linux is just dealing with the drive by cylinders. Primary/extended/logical partitions are just a way to identify the start/stop of each partition and are only used at bootup.
Should you use a partition allocated near the middle of your drive?
Humm. I'm not really sure because there are arguments for every which configuration. The main thing I would say is do not add multiple swap partitions with the same priority on the same drive. This will cause the kernel to use them in round-robin mode which will certianly cause performance problems. However if your partitions are on different drives, make sure the priorities are set the same for max performance... unless one drive is used more than another one for some reason, but you get the idea.
I have 64MB of RAM and 128 swap. I use my machine for development at runlevel 3.
Even with X, fvwm, 4 xterms, netscape, gcc, rc5des, etc., I hardly ever use more than 200 K of swap. However, I normally use much more RAM than I would if I used 64MB swap. So, using too much swap actually makes my system have to swap more than it should. Am I mistaken ?
According toe the HOWTO, right now the limit is 2GIGs.. hehe most wont need to go that high.. If you do, make another partition..
2 gig should be enough swap for everyone (in the same tone of.. 640kb should be enough for all)
You'll always want swap on your fastest drive. This is a _big deal_. Don't just look at Fast SCSI vs. Wide SCSI, though (although this is important). Look at the actual performance stats of the drive. Having swap split up between multiple drives helps a little, but usually not a lot (not enough to merit placing swap on the slower drive). With identical drives, the computer can potentially access both drives at once, for twice the transfer rate at peak. Practically, you're rarely at peak, and you usually only grab data off of one of the drives.
This is not true. NTFS does fragment. See
Diskkeeper 3 from Executive Software (Defrag-SW).
The help file even states what (mulitple -
reboot) procedures have to be taken for the
fragmentation of the swap file to be fixed.
Majordomo@www-klinik.uni-mainz.de is addy not
Majordomo@www.klinik.uni-mainz.de
subscribe linux-perf
MemTotal: 38992 kB
:) )
MemFree: 788 kB
MemShared: 18964 kB
Buffers: 17892 kB
Cached: 4132 kB
SwapTotal: 77416 kB
SwapFree: 73656 kB
That's on a p90, actively doing some samba, httpd, ftpd, several irc users, print server, vgetty. (no X, or netscape
Top says 71 processes. It rarely goes over 4 meg swap. (only when some evil user runs pico on a big file, or trys to email a large file in pine)
This is one of the reasons I like Linux. Server doing tons of stuff, and very efficient memory useage.
Does Linux have any per-user resource limit/management ? It would be nice to have a way that the system won't die if some moron runs pico on a 200 meg file. (well, it doesn't die, it just goes nuts) Or protection from a fork 'exploit'. (haven't had a problem with fork exploits, but I tried it out myself, and it brought the system to a crawl)
Yep. I'm using a P200 with 128MB Ram as 13x (virtual) web-, 1x news- and 2x ftp-server. During business hours the stress on all webservers is pretty high, so I started experimenting with kernel settings and swap space. As it looks, using at least 2x RAM as swap space increases response time for connects.
My private machine is a K6-233 with 224MB Ram and just 128 of swap.
Running
- povray for creating images,
- gimp for modifying them,
- vi for creating webpages and
- Netscape and Amaya for viewing them
at the same time, however, doesn't really use swap at all.Oh, I'm running wm2 as my favorite window manager. Maybe that's why. KDE (sucks) and Gnome ARE memory hogs...
The amount of swap you use *should* be at least equal to the amount of ram you have. The reason for this is because the kernel can be configured to dump its memory contents into the swap partition during a panic. At the next boot up, it would then move the contents of the core dump off to /var/crash, where the core dump can be inspected. The 128 mb swap size limit doesn't exist in Linux 2.x.
Swap >= memory. If your machine panics during install, theoretically all of the RAM may be core dumped. So your swap should be able to hold that. Fats swapping is nice when needed. So a separate UW SCSI swap disk would be A Good Thin imo.
The rule appears to be... it all depends on the low level format of the drive which balances transfer rate and seek time. (remember you may have more than one disk plate)
Eg0r
I agree with your comment about what people think of as a "reasonable" machine. I mean, it's great that you can reuse an old 386 with 16MB of RAM on it, but in a corporate setting, Linux is going to run on much hotter machines. At work, I'm the administrator of a Linux server running on a Dell PowerEdge 1300 with dual 400 mhz Pentium II's and 512 MB of RAM; we run Oracle and Apache on it (an intranet application). I dutifully gave it 512MB of swap space (4 x 128 MB partitions - I didn't know the 128 MB limit was gone - aargh!) which I've never seen it use.
We also have a Dell 6300 with 4 Pentium Pro CPU's and 4GB of internal memory running NT4 and a big Oracle database. We might replace NT in the future with Linux on these big machines; but then how much swap space would we give Linux? 4GB?! (that's how much NT has at the moment on the 6300, but of course, it hardly uses any of it).
I thinking the same thing and almost posted
the same comment. Swap space sure comes in handy for
those 2Gx2Gx2G nuclear particle simulations
that are also computational intensive in this
3D world! This would be one humungous 3D array
in C. I wonder what's left for the other user?
I am running a Dual PPro system /w 128mb RAM and have each drive setup with a swap partition of 128mb (located at the end of the drive). However every time I look at the memory utilization, there is less than 16mb of swap being used. This is my primary workstation, and I am running GNOME and KDE interchangably. I also have a PostgreSQL database running on it.
I have always been under the impression that Linux will do a RAID0 stripping of all available swap partitions, thus boosting the read/write performance of the swap. If this is true, then all swap partitions should be the same size, and you should only put one partition per drive.
Also, wasn't one of the complaints against the MindCraft benchmark that since Linux and NT were on the same drive, by putting NT on the outer cylinders of the drive, and Linux on the inner cylinders, it was giving NT a big advantage due to the newer drives putting more sectors per track along the outer cylinders??
But I only have a 16mb swap partition, and its hardly ever used. I run Netscape, I compile, I play games, sometimes I do it all at once. True I don't run a server, heck, I even disable telnetd, but I've found 192mb of RAM with a 16mb swap is plenty for me.
Actually I have always heard that the best place to make your swap partition is in the middle of the disk.
The reason is that the heads (which are constantly moving) have less distance to travel when going between the swap partition and your other partitions and that this increases the overall seek performance of the drive.
It did seem to make a difference on my old Pentium system (which does a lot of swapping)
In Solaris 2.x it uses the UFS (Unix File System) without the use of any third party products (Veritas File System, etc.). It doesn't fragment and you don't defrag your HD. The FS is optimized so that it breaks data up into certain size blocks and has an organized layout so that everything is managed properly. Is slightly slower in respects to a FAT32 OS but you don't have to go down to bring the system to a grinding halt once a week or whatever and defrag... I assume Linux has an highly managed FS also.
I have 128Mb of RAM have never noticed RedHat 6.0 swap on me. I find it frustrating that RedHat insist on you creating a swap partition when installing RedHat 6.0. I would much sooner have a swap file that I can easily change the size of.
It may not need swap for performance reasons, true. BUT, you may need it for debugging reasons if your a developer. I am assuming Linux operates on the same principle of Solaris when it comes to Kernel crashes. All memory it dumped to /tmp (which is mounted on swap). When the system encounters a panic signal it dumps the memory stack to /tmp, which you need to be the size of your memory to do this. Upon your next reboot the crash dump is moved to /var/crash/`hostname` and you can run through it with tools like kadb, crash, etc. to see a still shot of what the system looked like upon crash and thus find out why it crashed so you can fix it and not have it happen ever again...
It doesn't matter how many platters you have. The heads all read from the same place on each platter every time. The first block will be spread over the same physical area on each platter and the drive reads/writes from all platters simultaneously. There is only one beginning.
That assumes that swap accesses are usually going to be mixed with other accesses. I don't think that is usually the case. Most of the reads and writes to swap partitions are large, multi-block sequential accesses (i.e. several pages are swapped in at once). This assumes that you are using one application whose data segment fits in RAM while other applications are swapped out and the swap accesses occur when switching apps. In this case you want the swap partition near the beginning of the disk. If this is not the case (i.e. the data segment of the main application doesn't fit into RAM and keeps generating frequent random page faults), then your performance is going to seriously suck no matter where the swap partition resides.
There *is* a clearly defined beginning to the disk. The beginning of the disk (sector 0) resides on the outermost track and the end of the disk resides on the innermost track. This is done so the disk fills from the fast end first. The number of sectors per track is greatest on the outer tracks. Since the radial velocity of the platter is the same no matter where the head is positioned, the head will sweep through sectors faster at the outside of the disk. This means that the media->buffer transfer rate is greater at the beginning of the disk and the seek time is less.
If you never use all of your 32MB, then don't increase it. However, some people need a lot more than that depending on the application (editing large images for example). The 2 X RAM rule of thumb is just a suggestion.
Hard drive space is cheap. Running out of memory is a pain. Someday you will try something "different", and will need all the virtual memory you can find. Then it will probably be too late to go back and change things (unless you want to rebuild the machine). A deep swap area might even give you enough time to control-z when you do something memorable and things start looking really strange.
Don't pay too much attention to your day to day needs when configuring swap. 2X ram is still a good minimum, even for a single user machine with plenty of ram. Someday you will do something that will use much more memory than you would have thought. Your needs may change so that you will do so repeatedly. Exhausting memory is a double spank hands no-no! If you can configure things so that is is NOT used ordinarily (and so it won't put a performance hit on the other drives in the machine), you can even canabalize an old slow drive (e.g., that 500 MB IDE from your old old machine) as "back-up" swap, to provide insurance against stupidity. Why waste it?
First of all, in Solaris tmpfs is a variable size RAM disk. /tmp is tied to RAM, not swap. Eventually, if you fill all your RAM, then Solaris will swap the tmpfs to disk as well. The tmpfs in Solaris is actually a really bad idea. It is much better for the OS to map the available physical RAM as a disk cache instead.
Your lucky CL even gives linux support. Your not paying for it. It was mentioned on the box so go away troll boy.
This seems to be a common misconception. In Solaris, /tmp is actually not mounted on swap. tmpfs is actually a variable size RAM disk in virtual memory. If you have /tmp mounted on tmpfs, then anything written to it is mapped into virtual memory. If you run out of RAM, then the pages of virtual memory holding /tmp get swapped to disk.
Consult the kernel doc (2.2.9 at least) .../Documentation/sysctl/vm.txt for lots of stuff one can play with to optimize memory and swap behavior of the kernel.
At least one gives a rather in depth description of the issue, the Multi Disk HOWTO which is very much about tuning in general. It is way to big to quote here so I' rather suggest the interested readers look at the following chapters listed below (straight from the Multi Disk HOWTO homepage):
Note that the swap partiotn limit in old kernels depends on the architecture of the processor, namely if it is a 32- or 64-bits processor.
If you have any comments to the HOWTO I hope you can take direct contact with the author so more people can benefit from your insight.
by intuition, though, it would seem to me that rm only removes filenames (hardlinks), and that the swapsystem holds a hardlink to the file. thus you'd end up with a file that hasn't got any filename. in that case, if you drop the swap using /sbin/swapoff, the file will be deleted (because no-one will know that file: no directory, no kernel service, no running process).
it would not be normal to me that the file would only be deleted after a reboot.
Isn't there a flag or something for programs that are commonly used by different users at the same time? I remember someone pointing this out to me on SunOS, where a hundred users would be in pine at the same time (this was at a university) but there was really only one copy of pine code loaded in memory.
tmpfs is covers the whole swap device. This includes both memory and physical disk on a standard install.
You can put more than 1 Gig in a PC but the 512meg pieces are very rare and ultra-expensive.
;-)
(There were problems with old Chipsets (LX ?) which couldnt cached more than 512megs or so)
Also, for Linux on Intel HW Virtual Memory Limit is 2 Gigs.
If You have 2 Gigs RAM, there is no more room for swap
Ciao,
Frank
- snip -
:)
Actually, your first point is incorrect (unless drive design has changed radically in the last couple of years). Here's an excerpt from my post (the rest is located above, concerning the topic postion on the disk).
- snip -
Actually, it's been longer than that. Ever since IDE drive manufacturers had to start using translation (LBA and other methods) to accomodate larger drives they could put how many sectors they wanted on each track. And SCSI HD's have been doing it for longer than that since SCSI controllers have never used C/H/S numbers to access a drive but logical sector numbers and the drive did the translation.
Besides, it's more cost effective. To get the same number of sectors on each track you either use a variable read/write clock to compensate for the faster rotational speed or you put more dead space between sectors.
Now put yourself in a HD manufactures shoes: the fixed clock is cheaper and less complex and by getting rid of that dead space (minor tweak in the already existing translation code) I can sell a bigger HD while keeping manufacturing costs THE SAME. Guess what I would do.
Of course it won't supply the same features as Gnome or KDE. Windowmaker is a window manager, not a widget set and set of associayted programs.
I can't believe how many people fall into this trap. It's similar to the misconception that "Drivers for Redhat" means that Debian, etc. can't use them.
The faster your swap disk is, the more system performance will be improved when swapping. Splitting your swap between multiple controllers (i.e., if you have two-channel SCSI, put a swap area on one drive of each channel) will also help, particularly with IDE. Several swap areas split between several controllers are better than one big swap area.
Amount of swap: Disk speed counts here as well. If you have fast disks, swapping does not degrade your performance as much as with slower drives. In any case, if you find that you need 128 MB of swap normally, your real problem is that you don't have enough RAM. Get more. In practice, 64 MB swap should be plenty, but it depends on what the machine does. Even with too much RAM, it will swap out a small amount. This is OK. If you are swapping IN (and out) a lot, you need more RAM.
If you have two controllers and two disks, go with two 32MB swap areas; if they are greatly different speeds, you may want to give them different priorities, experiment. If you have one controller, use one 64MB swap area. If you're really paranoid about it, add another 64MB swap area on another disk; that much disk space is an insignificant fraction these days.
on a 450MHz system with 20 users acting as an afp file server with light loads :
MemTotal: 156332 kB
MemFree: 102704 kB
MemShared: 13100 kB
Buffers: 20896 kB
Cached: 17636 kB
SwapTotal: 34236 kB
SwapFree: 28972 kB
my swap is around 1/4 the total RAM and my machine has never been able to fill it up. When i copy 8GB from one drive to another the RAM often fills with HUGE buffers but the swap seems to remain constant. My advice : use 127 MB of swap if you have it, but you shouldnt need it. normally try for a swap partition which is 1/4 the total RAM size if you have 128+ megs of RAM.
There are a few things to keep in mind.
The first and foremost is that no single hard drive can transfer more than about 10meg per second (at least when I last researched it a few months ago, I haven't heard of anything faster than 10k rpm drives so I think it's still accurate).
So, if using one hard drive the difference between the 20 MB/s and the wide 40 MB/s would make absolutely no difference - the 20 MB/s would never be exceeded.
That figure (20 MB/s or 40 MB/s) is the capacity of the SCSI bus. SO, if you put three drives in the box, then the possible total transfer rate of 30 MB/s _would_ make start kickin' in.
So don't waste your money on a Wide controller or Wide drives (40 MB/s) unless you plan to eventually have more than two drives on that controller.
As far as swap priorities go, use the same priority for multiple swap partions on different drives and different priorities for multiple swap partitions on the same drive.
For a single swap partition on each of different drives the idea is that with the same priority the kernel is supposed to automatically "stripe" the usage of the partitions (i.e. use all the drives at the same time and make the total transfer rate higher).
For mutiple swap partitions on the same drive the idea is to have different priorities to different partitions so that it is "guaranteed" not to try to write to the parititions at the same time (since on the same drive it would slow things down overall since the drive can not write to multiple areas of the drive simultaneously).
For multiple swap partitions on multiple drives you combine the above two. The first swap partition on each of the multiple drives should be given a priority. The second swap partition on each of the multiple drives should be given another priority.
(And yes if you want more than 128MB of swap space you need to create multiple partitions each of size 128MB or below.)
Lastly, the rule of thumb "swap >= twice the amount of physical RAM" assumes you'll swap and came about in the golden days when RAM was minimal and expensive.
If you don't expect to actually be using all of the 128MB you might not even need swap partition(s) at all.
Good luck,
strcat!
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
Don't listen to the morons who tell you 1x memory, 2x memory, etc. It's bullshit. How much swap you want, on any modern OS (Linux, Solaris, etc.) depends on what you're planning to do. With less RAM, you often want more. With more RAM, you often need less.
Basically, if you're liberal, you'll want to figure out how much memory you'll use at peak, multiply that by 1.5 to be safe, and make sure swap is at least that. More swap never hurts performance, so if you don't care about money, you may as well have an arbitrarily large amount.
For a (minor) performance benefit, you'll want swap to be the size of the total memory you use at peak, instead of having memory+swap be that size. Linux has fairly aggressive memory management; during idle cycles, it often writes out a copy of a page before it runs out of memory. It keeps a copy in memory and remembers if it's 'dirty.' That way, if it suddenly needs more memory, it can dump those pages from memory instantly without needing to write them out.
Likewise, if you accidentally allocate too little, you're also not too badly off. Like Windows, Linux supports swap files. Unlike Windows, you can add swap files dynamically as the system is running. Should you ever run out, you just make a swap file, and you're fine.
If you're conservative, or on a lower-end system, figure out how much memory you'll use at peak, and go with that as a total for memory+swap. Add/increase swap files as you need more.
Why use swap partitions instead of swap files at all? They're a bit faster than swap files.
Personally, I have 64mb RAM, 64mb swap, and I've never run out, but I only do e-mail, zephyr and light browsing locally. If you do more, you may want as much as 256mb total. If you do 3d rendering, animation, or work with large graphics, then you probably know how much more you need.
- pmitros
Majordomo@www-klinik.uni-mainz.de is addy not
Majordomo@www.klinik.uni-mainz.de
subscribe linux-perf
It would seem to me that the amount of swap
is really very dependent on the intended
use of the machine. I administer machines
being used as multi-user systems by physicists.
Unfortunately, this means that occasionally, and
quite unpredictably, I may have a user launch
a REALLY big job(~350+ MB). Or I may have
several launch moderately big jobs(10 users x
~50 MB). Needless to say the result would
not be pretty if I followed many of the
recommendations here.
What is far more useful than a simple recipe
would be some reasonable explanation for
new users of WHAT swap does, how it works
under linux, what user memory footprints tend to
be like, and bringing it all together to give
some notion of what your swap + memory needs
are.
For example, typical light users in my
environments can be expected to be running
netscape (footprint ~20MB), ghostview (~3MB),
and some other stray programs (~5 MB). So
my safe estimate on light usage is a 40MB
memory footprint per user. It's not
unusual for my more heavily used machines
to have 20 such users going at a time, so
I need to support a ram + swap in the 1 Gig
range. All of this is based upon a cursory
examination of the UltraSparcs I deal with.
What would be helpful would be for someone in the
linux community to start putting together
some carefully researched information
about program and user memory footprints.
/etc/fstab
/etc/fstab. Your primary drive on on the first IDE channel would be hda (or sda for the first scsi device) your old drive would be hdb (if its the slave on the first ide chan). /etc/fstab will have an entry /etc/fstab entry to look like
You partition the second drive to have a 128 meg swap partition and point the kernel at it in
Lets say you have 64 megs o' swap on the second partition of hda yer
/dev/hda2 swap swap defaults 0 0
like so.
If yer second drive has a 128meg swap on partition 2 youd change
/dev/hdb2 swap swap defaults 0 0
You could also just add an entry for the second swap partition then do
#swapoff
#swapon
and that would give you 64+128=192meg
you can grab it here:
http://www.klomp.org/mod_roaming/
-- Does Rain Man use the Autistic License for his software?
Slashdot's first reaction to VMware
Why should you put any swap space in when you have 128M of RAM? Here's why -- the kernel can agressively swap out programs and use that space for disk cache, which becomes a huge performance boost when your program footprints start approaching your memory size. I have a headless machine that only runs a few services (news, mail, web, etc) with 80M of ram, and it often swaps when I have less than half that RAM taken up by currently running applications. Disk is cheap, burn a little and get a big performance boost.
Actually, it does. Back when I still ran Slack 3.1 on my home box, I used RAID 0 to join 2 partitions on my 2 IDE hard drives (I know, I know) and used that as my swap space. It worked just fine.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Your last comment sounds like a job for swapd. Search freshmeat for it, and give it a spin.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Ok, in Solaris 2.x, most of your 4GB of memory is swap using tmpfs. You're only using the disk when you run out of room in tmpfs.
And, if you have only 2 drives and 4GB of memory, I suggest you spend a little cash on another drive.
_damnit_
_damnit_
It's my job to freeze you. -- Logan's Run
First of all, the ``twice the RAM size'' rule is a moronic leftover from operating systems which used swap in a backing storage manner. On these systems, the virtual memory size was equal to the swap size, with RAM serving as a sort of high-speed cache over that without contributing to the amount of swap. Meaning that there *had* to be at least as much swap as RAM for architectural reasons. In Linux, the total space available is the *sum* of the swap size and RAM size, so that rule of thumb, for what it may be worth, needs to be modified to: have as much swap as you have RAM.
:) will benefit from a large swap space (the leaking ones will be able to run longer, if not better :). Applications that periodically access large areas of memory will need actual RAM. For example, image processing or scientific simulations with huge arrays.
Of course, the problem with rules of thumb is that not all thumbs are the same.
Ideally, you don't want any swap space at all. In practice you have to look at how much virtual space your applications need, and then decide how much of that space you can afford to represent with real RAM.
If you need a peak value of 256 megabytes of memory to do what you want, and you have 64 megabytes of RAM, then you will obviously need 192 megabytes of swap space. If what you are doing won't run well unless all 256 megabytes are real RAM, then you will have to get 256 megabytes of ral RAM, in which case you then won't need any swap at all (but you can always have swap for the hell of it for for emergencies).
Whether or not it's efficient to meet needs with a large amount of swap depends on the locality of memory references within the applications you are going to be running. Some applications simply won't run well if you don't have actual RAM, others might. Applications that have a small access pattern, but large memory usage (because, for instance, they have nasty memory leaks
So there is no one-size-fits-all rule of thumb; you have to consider the nature of the application. First estimate the memory usage, trying to err on the side of too high rather than too low. Then based on the application type, determine how much swap is sufferable. Perhaps as little as one fourth of the total requirement needs to be physical RAM. Or maybe the whole thing has to be RAM.
Also, simply set a low cutoff limit based on the RAM market. For example, these days, you might want to assume that there will be 128 megs of real RAM no matter what and proceed from there.
You are.
Stating on Slashdot that I like cheese since 1997.
There's no need to go above 128MB under any configuration except ones that are already performing very poorly.
Think about it: What would you do with more than 128MB swap space? Swapping at all is very bad; swapping a couple hundred megs is pretty catastrophic!
On low-end machines, a 128MB swap would be 2x or 4x the size of your RAM. That's plenty of extra room for X, Emacs, whatever bloated thing you're running.
On medium-end machines, a 128MB swap might be double your RAM, and...well, why not?
On high-end machines and servers, you don't want to ever swap. Disk is just too slow. However, the algorithms in the kernel are kinda tuned on the assumption that you have at least a bit of swap space. The buffer cache, for example, might not shrink fast enough when you need the RAM for some fast-growing process. So stick a small swap (like 128MB) on the machine to keep some balance in the algorithms, but hope you don't have to use it too much.
Do you see a pattern? Just go with 128MB. It should be just fine.
The variable density of the data storage on platters makes the rotational velocity moot. On the outermost tracks, data is less dense than on the inner tracks. The image of the subdivision of a platter into sectors is a pizza cut perfectly into slices, and then concentric circles are cut through the slices.
/boot stuff is under the max cyl # barrier) and the rest would be application file system. When you install the OS, programs and data fill the partion from the outtermost tracks inward, which will be closest to the swap partition. As a result, the drive heads will never have to travel further than from the innermost sector containing data.
/usr and /usr/local on separate file systems, for instance, and you use programs/data installed in both directories equally frequently, then placing a swap partition between the other two partions is actually the better way to go.
Each sector (the individual pieces of pizza from the above illustration) is able to contain the SAME number of bits of info, NO MATTER WHERE IT IS ON THE DISK. This is done to make the rate of reading and writing from/to the disks a constant no matter where on the physical platter you are.
There IS a reason that putting the swap partition on the outter most sector increased performance...
Because sectors are almost allways numbered starting on the outermost tracks of a partition, if you have only 2 partitions then you can optimize the swap performance. The first partition would be swap (note this if for smaller disks, where the
This will not be all that effective however, if you have multiple partions that are all accessed frequently. If you have
The assumption that rotational velocity has anything to do with it is wrong; the placement of the swap partion is correct for basic partitioning scheams.
Actually, your first point is incorrect (unless drive design has changed radically in the last couple of years). Here's an excerpt from my post (the rest is located above, concerning the topic postion on the disk).
snippet begins------------------------
The variable density of the data storage on platters makes the rotational velocity moot. On the outermost tracks, data is less dense than on the inner tracks. The image of the subdivision of a platter into sectors is a pizza cut perfectly into slices, and then concentric circles are cut through the slices.
Each sector (the individual pieces of pizza from the above illustration) is able to contain the SAME number of bits of info, NO MATTER WHERE IT IS ON THE DISK. This is done to make the rate of reading and writing from/to the disks a constant no matter where on the physical platter you are.
--------------------end snippet
Forgive me for I cannot help myself...
My swap partition on a box with 128Mb RAM is a mere 32Mb and I've yet to see more than 2Mb swapped. So why waste the disk space?
Yet with KDE, I regularly swapped up to 48Mb and beyond.
Ok, so it's not NT (which bloody swaps even when no apps are loaded!) but why the huge differences? Is WindowMaker really that light?
In my never ending quest to try all the distros I can, I've made one partition for /home and regularly blown away everything else, including swap.
The largest I've had my swap file is a 128Mb partition and with WindowMaker, I've never seen it use more swap than with 32Mb.
You could well be right but in julesLand, it doesn't seem to be working that way!
...because there are many platters. It's been a long time since hard disks have been on a single disk. Not only that, but they're double sided. So you end up having 6 "beginnings" for a hard disk of 3 platters...it no longer seems like such a big deal where your swap partition is.
<tim><
also, putting the swap on a different controller and hard drive than the root filesystem...
ive heard of people getting up to 10% system higher system performance with this method
Global warming is good for you!
You should really check to see how much memory your application is using and make sure you have enough RAM to cover it.
If you are going in to swap then use about twice the amount of swap as you have memory and spread the partitions across as many disks/channels as you can.
Deleted
If you set the swap priority to two swap partitions to be the same in Linux 2.0 and later it will stripe accesses to them. By default however, it assigns swap priorities in decreasing order according to fstab
Unlike most, I'm one who believes in investing as much disk to swap as you can afford. 2xRAM is my minimal swap space.
/usr/src/linux/Documentation/Changes in 2.2.10 only states that the 128MB limit is gone, but doesn't list the new physical limit -- I've used up to 1024MB in one swap partition so I know that it can get pretty big. I wouldn't be surprised to find that the limit is 2048MB to conform with the 32 bit file size limit in ext2fs simply for parity with swap files in mkswap.
With Linux kernels previous to (I believe) 2.0.36 you must make each swap partition no larger than 128M, though you may have an arbitrary number of swap partitions or files (and yes, Linux can use swap files in the filesystem instead of individual partitions, but at a performance penalty).
Older 2.0.x, 1.2.x, and 1.0.x kernels must use individual 128MB swap partitions or files (actually, I seem to recall that 1.0.x kernels didn't support swap files, only partitions), but don't know if the larger swap partition support is limited to 2.2.x kernels or the later 2.0.36/37 kernels.
Now for why I like lots of swap: You don't have to use it, but when you need it you REALLY need it! Your VM space is only as large as core and swap. Yes, I know the kernel can address anywhere within the 4GB boundary, but the total number of usable pages is limited to your physical RAM plus swap space! This is important to consider if you ever want to run lots of processes which sleep until asynchronous I/O events wake them up. If you want to start lots of processes and let them go off to sleep, having plenty of VM space makes sense. The machine will only thrash if there's memory contention among processes in a run state, so it's safe (and desirable) to let sleeping processes page out to swap while the machine uses physical core for running code.
Also: consider the possibility of a small application using huge datasets. I run into this at work all the time. We have clustered machines each with 1/2GB of RAM and 1GB of swap. As long as each process only keeps dirty pages of the dataset in core, one can have multiple program instances crunching through different datasets even though together they're exceeding total physical core. Since these programs are stepping linearly through the data, instead of randomly seeking different pages like in a program doing long jumps, this can actually work well. Memory contention occurs not when you exceed total physical ram, but when running processes request pages that have been flushed to disk!
If you're careful and selective about how you use the extra swap space you can wildly exceed physical core without significant performance loss. Food for thought.
I don't know much, but having two swap partitions on the same drive sounds bad. Linux may be smart enough not to do this, but it is conceivable that it could try to write to both partitions simultaneously, thus reducing performance.
For maximum performance out of your swap space, you probably want it closer to the beginning of the disk. Of course, if you don't do much swapping to disk then filesystem performance may be more important to you, so in that case the swap partition should go closer to the end of the disk.
You probably won't really notice a difference either way, though.
I have no problem to force swapping (or actually paging :-) on a 96MB-single-user-client :-)
:-)
And memory gets even more important with a multiuser-system. My personal "internet-connected" computer eg has 48mb ram, 128MB swap, 30 users and needs around 70mb swap after one week or so even without X. (ok, squid, qwsv and up to 20 screen-session eat quite a lot
"Life is short and in most cases it ends with death." Sir Sinclair
http://www.nl.linux.org/linuxperf/.
If you want to help with the site, subscribe to the linuxperf@nl.linux.org mailing list by sending a message to Majordomo@nl.linux.org with "subscribe linuxperf" in the body of the message.
I've wondered this too. Especially since I don't own a machine that has less than 128 MB RAM.. most have in the range of 160-192... and every time I install Linux, sizing the swap partition has always been a big question... of course, now that question will be made easier now that the newer kernel supports larger swap files.
Note: The linux folks out there need to adjust what they think is a reasonable machine, and provide some guidelines for us who like max things out in a box. I can see the swap guidelines applying to people putting Linux on discarded Pentiums, 486's and non-G3 powerMacs... but there needs to be some guidelines for those of us who buy/acquire/build machines that have wicked fast CPUs, normal Hard Drives (even though they may be of capacities barely heard of a few years ago) and enough money to buy decent amount of RAM (Esp with 128 MB DIMMs going for around $100 a pop, it's easy to get large amounts in a desktop machine).
So basically, after reading all the posts, the concensus is: Use 128 MB no matter how much RAM you have if you're using a single user machine, and don't really worry about it (assuming the use of an old kernel that only allows a 128 MB swap file), or the same size as your RAM if you're using a newer kernel.
On server level machines, or machines that are to be used as servers, you need to do a little more analysis based on how the machine will be used.
Anyone want to verify this?
Reeses
One thing about swap that the previous posters haven't mentioned is to put your swap partitions in the lower cylinders of the drive, as they are capable of transferring data the fastest due to their location on the inside of the disc. I've got three discs with 128MB each of swap space and each is in the lower cylinders in my 512MB server.
To get better performances for Linux machines, subscribe to the Linux-perf mailinglist.
To subscribe, send email to majordomo@www.klinik.uni-mainz.de and put "subscribe linux-perf" (without the quotes) in the message body.
Muchas Gracias, Señor Edward Snowden !
I have found that my system, which has 128mb of ram, uses very little swap. 64mb should be fine, I currently have a 128mb swap. ("Very little" is 15% maximum)
Sincerely,
Nelson Rush
"God prevent we should ever be twenty years without a revolution." -- Thomas Jefferson
The real answer is that it's manufacturer dependant. The SCSI/IDE command set doesn't specify when I seek where the head will wind up physically. Right now I have queries in with both Seagate and Quantum over this issue because I'll be tuning a new server in the next few days.
--
--
I have no sig.
My recipy is this: 2xPhysical Ram for swap. If possible put each 128Mb swap partition on a diffrent disk.
Assign the same pririty to each partition on a diffrent disk....
ie:
3 disks with 6 partitions...
the first partition on each disk at priority 1 then the second on each disk at 2...
Hop this helps!
"There is no spoon" - Neo, The Matrix
"SPOOOOOOOOON!" - The Tick, The Tick
There is plenty of reasons for going above 128MB swap. I have (well, the department here has, but I take care of them) a cluster of dual-PII:s with 256MB physical memory and 1GB swap each. I have seen many programs here eating around 600-700 MB of memory, the top notation was a Matlab script using close to 1 GB of memory. Yes, the script was carefully written to avoid thrashing. On the other hand, I have also seen programs using "only" about 400 MB that thrashed like h*ll.
Yes, we're about to buy 1 GB of memory per machine, we really need it. Problem is that with these fscking PC:s you can't have more than 1 GB. We don't really want to buy a Sun Enterprise or an Alpha, since we're trying to move to all PC:s, so I guess we'll have to wait for the Xeon machines to become common.
Our department is into research in coding theory and cryptography among other things, and the simulations for this kind of stuff are huge. One of our professors want to run a program which needs 4 GB of memory and 20 GB swap, and so far we haven't found any machine which can manage that.
One thing you can do if possible is put your Swap on a different harddrive and if you have 2 swap partitions give the one on the separate drive higher priority.
Help fight continental drift.
Anyone who thinks they can go without swap space is kidding themselves or not running Netscape :)
In all seriousness my rule of them is:
Twice the amount of RAM or 256M whichever
is smaller.
My primary workstation has 256M of RAM and 256M of swap and I have actually allocated all of my RAM and half of my swap before. They occasions this happens are rare, but imagine if I didn't have the swap there!
I used to run Linux on a P90 with 16M of RAM and 32M of swap and I can rember programs crashing because of running out of memory. I don't ever want to deal with that again.
If possible use a high speed drive, but the most signifgant factor is haveing plenty of RAM. I will never build a box again with less than 64M and anything for development use will have a good 128M if not 256M.
-Alan
So if I'm running a 2.2.x kernel and a 64Mb swap partition, and say I wanted to make it 128Mb on the second drive, what would I need to do to change it?
make a new partition on the new drive (use fdisk or whatever), make that drive type 82 (correct me if I'm wrong but the correct type for linux swap anyway), format that drive (mkswap?) and swapon it (or put the appropriate entry in /etc/fstab).
there you go. easy peasy
If I remember correctly, there's a sysctl thing to turn off the overcommit. I just can't remember what it is off the top of my head. See the kernel docs :)
I think even if you have 128MB+ RAM, you still want swap. If you have at least some swap, inactive processes can be swapped out in favor of cache when there is heavy disk activity.
--Rob
I always found that partitions at the end of a disk were fastest to access... Maybe I was mistaken.
128MB seems to be more than enough for the server I'm running (with apache, ftp and >10 simultaneous telnets running gcc and debugging...). Admittedly, not the most mission-critical or demanding of tasks, but it might give you swappartitionformatting folks an idea of what is possible. It seems as if linux can, when it wants to, do some rather impressive garbage collect...
You asked three seperate questions, so I think I'll answer them in order:
First off, the 127MB limit was for the older 2.0 series of kernels. The new 2.2 series (and dists based on them) has a much higher limit (I can't remember exactly what is it, but it's ALOT bigger (maybe like 1GB or more)). So, you can make a single swap partition of 256MB or so. If you are using a 2.0-based dist, you should make multiple partitions, each no bigger than 127MB.
IIRC, linux is like the newer Solaris 2, IRIX, and HPUX systems in that swap space is added to physical RAM to come up with the Total Virtual Memory allotable on the system. Under older BSD4.2-based systems (I don't know about current Free/Net/OpenBSD stuff), swap space equal to physical RAM was used to "shadow" the physical memory (and improve swap performance), and thus your Total Virtual Memory was equal to the amount of swap space you had.
For Linux 2.2, the rule of 2x physical memory is perhaps a bit overkill. I prefer the Solaris guidelines: you should have at least 128MB of total swap+physical for a typical end-user system, with 256MB for a developer/power user, and 512MB for someone using high-end graphics (the X-server gets big) or doing serious work. The point here is: swap space is slow. You should have enough swap space to hold applications that you aren't currently using, but huge amounts aren't useful (unless you have an application that likes to map large amounts of Virtual Memory, but doesn't actually use it). For most of us, I think no more than 256MB of swap is best.
Swap being slow, putting your swap drive on the fastest possible disk is a good way to enhance performance. In your case, the performance characteristics of the drive are more important than the interface. Thus, a new drive (6.5ms / 10,000RPM) with a FastSCSI interface is preferable to using an older drive (perhaps 9ms/7200RPM) with WideSCSI. Striping swap is also a good idea, though you should use drives of similar speed.
Also, note that linux can swap to a file, as well as to a raw partition. However, swapping to a partition is faster, and preferable.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
I have RedHat 6.0 and 192megs of RAM... I have 200mb swap partition on another Hard Drive... I also run GNOME, and barley ever see it use all my RAM or even touch my SWAP... execpt when I use VMware, then it uses about 10mb of SWAP. A 50 - 100 mb partition is all you need.
Well I have 256MB RAM and I haven't swapped yet. That's with a 33MB X server, 35MB Netscape, KDE, a couple 10MB mySql severs, and all the "normal" services.
It only used 60MB with all this running and doing a full kernel compile with -j on my SMP box. (load up to 35, yikes). I did get some "gcc: vfork: Resource temporarily unavailable" messages during the make -k modules, but I had plenty of swap left so it must have been processes or something. Had to limit the concurent jobs to get it to go.
I'd say, tentatively, that if you have 256MB RAM you probably don't need more than 128MB unless you're doing some serious number crunching. And, you'll probably run into other issues also. I've got two 127MB partitions on separate SCSI channels just to be sure...
According to the mkswap(8) manpage that comes with RedHat 6.0, "The maximum useful size of a swap rea now depends on the architecture. It is roughly 2GB on i386, PPC, m68k, ARM, 1GB on sparc, 512MB on mips, 128GB on alpha and 3TB on sparc64." It notes that this is for the new swap area style, which it claims to be supported since 2.1.117. (I don't know if the support is in 2.0.37, but it could be.) It also notes that 8 swap areas are presently allocated, so it's not unlimited. (It can probably be changed fairly easily by recompiling the kernel with a different limit, if it's just a static array.)
All the guidelines for sizing your swap space based on your RAM size are misleading. On some old Unix systems (SunOS 4, I think), physical memory HAD to fit in swap (to do a core dump) and you usually wanted some extra. I think this is the origin of the "double the RAM size" recommendation for swap space. Under Linux (and I think Solaris and many other systems), the swap space is used for overflow for whatever doesn't fit in physical RAM. Your total Virtual Memory (VM) is the sum of your physical RAM and all the swap areas.
The best way to size your swap space is to decide how much total VM you want, then subtract your physical RAM. If you have 64 Meg of RAM, and you feel that's enough VM, nothing says you need to create a swap partition. If you want a gigabyte of VM, add enough swap to make up the difference. It all depends on what you want to do with the computer, and how much disk space you're willing to allocate.
Forget about RAM-to-swap ratios and just focus on total VM. Consider that an old Linux system with 16 Meg of RAM and 32 Meg of swap (double the RAM) had 48 Meg of total VM. Such a machine has less total VM than a newer machine with 64 Meg of RAM and no swap. Your limits will be determined by your total VM, not the ratio.
Ideally, you'd have enough RAM for your total VM needs and no swap -- it's the fastest. Realistically, you'll want far more than average occasionally, so it's best to have at least some swap. Since disk space keeps getting cheaper, allocating a few hundred megabytes doesn't usually hurt much...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Some people have sugested distributing swap partitions across disk drives. Now imagine one of these drives fail. It might look like pulling out a SIMM while the machine is running. I assume the system would collapse in this case. Has anyone tried such a scenario?
I'm building a small server here and all i want is reliability not speed. So how would it look like having a swap file on a raid5 partition?
All right. I run several servers at work, and a dual-boot box at home. The only thing I have to say is this: I have a measly 64MB of memory at home, and yet I have only a 16MB swap file. I used to have no swap file at all (the horror! the horror!).
Guess what? I've run out of memory once in the last two years. Once. That was when I was trying to use SNiFF+ to parse the 2.2 kernel...
I'm not advising you to use as little swap as I am. It's probably too little, especially considering the way app requirements are shooting up all around these days. However, if you're setting up a workstation here, fuggeddabout the multiple F/W LVD SuperSCSI VII Widgetco hardrives and just set yourself up a nice, comfy 64MB partition anywhere on the drive you want. I'm betting it doesn't get used 99% of the time anyway.
Servers, on the other hand, are a different story...:)
-k. ^-^ ^D
I don't understand why anyone would bother running with no swap space. I have about double my physical ram on my box at home(64 meg ram, 128 swap), and I believe my box at work has more than double(128 meg physical, can't remember how much swap)... I'm at home right now, and I seem to be using 10 meg of swap, probably left over from something I did the other day(seeing as how it never seems to deallocate). I also remember my box at work reading about 40 meg of swap used(it has 128 meg physical). Do I remember what I was doing that made it shoot up? nope :p. Why use this obese amount of swap space when so much is unused? Simple... I don't have the 120 meg drive my old 386 with running 1.2.13 had. I can get away with more than 8 meg physical, 16 swap :). Hard drive space is cheap... I was over at pricewatch today and a 17 gig ide is 180 bucks... just over 10 bucks a gig, or a buck per 100 meg... so if you have 128 meg of ram, it's gonna cost you 2 dollars and 50 cents for swap. Even if I don't use it, I aint gonna miss it... I spend more than that on lunch anywho...
when a program allocates memory, linux will free buffers and cache until enough is free, and only start swapping if it still doesn't have enough.
Remember: Free memory is wasted memory!
MemTotal: 517528 kB
MemFree: 4308 kB
MemShared: 24236 kB
Buffers: 11744 kB
Cached: 384104 kB
SwapTotal: 64492 kB
SwapFree: 48736 kB
I would have posted 'free' output, but it didn't fit right. Anyway, I have on the average, 110mb ram used on this 512mb machine. Usually about 8 xterms open with 10000 lines scroll back (not that much memory actually), netscape with a 30mb memory cache (no disk), still goes just fine.
I usually don't see swap until a few days of uptime and to be quite frank, I don't know why it would touch swap with this much ram (usually 400mb left over before buffers/cache)
--
Lab test show that use of micro$oft causes deadly cancer in lab animals.
A couple of questions:
Is it ok to use a logical partition?
Should you use a partition allocated near the middle of your drive?
Sheesh, evil *and* a jerk. -- Jade
Anyway, it depends on how much memory you have in your machine and what you plan do run on it. Here's my rule of thumb. For 8 MB up to 64 MB RAM, make a swap partition twice the size of the RAM. For larger RAM, just make swap 127 MB, since it's the limit for a single partition. If you have more than that amount of RAM, 127 MB swap is still fine - remember, you've got lots of RAM.
(One person's opinion was just go ahead and start off with 127 MB swap no matter how much RAM you have because it's too hard to increase the size after it's been created. I wish I had heard this before I configured my machine.)
However, if you really need to have several LARGE programs running at the same time (Netscape and StarOffice and KDE and... a few other big things) then you need more RAM than 64 MB (try 192 for starters). If you really need all that swap, adding more is only going to slow things down more, even if it's on another disk - after all, a drive is slower than RAM...
Still, I'd like to know myself what rules of thumb there are for large memory machines (256 MB and higher). I can't imagine the rules for swap in small RAM machines continues to hold.
Actually, no. Yes, the disk is moving faster, but the physical size of the bits are increased. Think of an old record player spinning at 33 1/3 RPM. The same length of sound was on the outer groove as on the inner groove. That implies that a 1 second sound bite takes up the same proportional amount of the groove. It works out to 10.8 degrees per second, whether you are on the inner groove or the outer groove.
The same applies to a hard disk (not CD-roms, most of them do have a variable spin). A hard disk spins at a fixed rate of speed. There are the same number of sectors on each track, therefore it will take the same amount of time to read a sector on the inner track as on the outer track.
This being said, there could still be some performance improvements on locating the swap file/partition at different areas of the disk. For example, placing it as close as possible to the most-often accessed data would certainly reduce the time it takes the head to seek to the appropriate track.
A good rule of thumb is to place a swap file on the most used partition of the least used hard disk (assuming a file and not a partition). For a swap partition, place it as close as possible to the most used partition on the least used hard disk.
I don't know how the ext2 filesystem allocates space, so I can't state whether the swap partition should be close to the outer edge of the ext2 filesystem or the inner edge. Perhaps someone who knows could respond.
Jonathan Bayer
-- Error: Cannot find file REALITY.SYS - Universe halted, please reboot!
I run a PII-400MHz 2.2.10 system, which is essentially single user. I have 128 MB RAM, and 128 MB swap space. I've never seen Linux use more than 1 MB of swap space, even when compiling the kernel. While running X. And Netscape. And X11Amp.
Oh course, if I were running a server, I'd keep the 128MB, just in case. But I don't. Next time I reinstall Linux, I'm reducing the swap to 32MB (just in case...).
I know this question was about Linux, but I wanted to put my 2 cents in about swap and Solaris as I often run into admins who are ardent supporters of the 2 x RAM rule. My experience is that a lot of people overdo swap on Solaris. The best way to gauge your need of swap is through trial and error. You need to look at what you are going to do with the box and you need to be familiar with the applications. Solaris 2.x deals with anonymous memory in a more efficient manner (it relieves the need for swap space when a process demands more space). The tools you can use to figure out your needs would be /usr/proc/bin/pmap, swap -s, vmstat and df. Sure bets that you will need sizable swap space are databases that rely on shared memory. Often their requirements exceed physical memory. (Check out the Solaris Performance and Tuning from Cockroft and look at Sunworld's swap article from January of `98.) The moral: KNOW YOUR APPLICATIONS. TEST, TEST, TEST! Run the application and peek at it with pmap. How much does it memory does it take? Is that what the peek is? Then do this with the other processes on the system and add them up. Look at swap with vmstat and df -k. Do you have a lot of /tmp and /tmp is swapfs? If you do, then maybe you have too much swap. Also, be sure to trim your system of unneeded processes. Why have automountd running when you don't automount? Why have nfs or rpc running if you don't need them? You will find a winning combination after trial and error. Nothing beats experience and testing in sizing a box.
In my experience, putting the swap file on the outer edge of disk has increased performance. The disk is moving faster under the head at the edges of the disk. Just a small tip.
LL
"If you are falling, dive." -Joseph Campbell
Adding Swap: 104416k swap-space (priority 2120)
This started when I went to a kernel level higher than 2.0.0. When I was at 2.0.0 and lower, I get a swap priority of -1.
Any idea why this might be happening?
My /etc/fstab swap partition is defined as such...
Thanks!
david
Placing swaps between other partitions is again a throw back to the days of less powerful machines. Back when disks had the speed of Fred Flinstone in his foot powered car, the time for a disk head to move between data and swap was considerable. Thus the advice was to alternate data - swap -data so that heads would move less when disk paging. Having a data - data -swap configuration could lead to a preformace hitch if the heads had to transverse the extra data partition in the middle. Now days as drives get faster, this consideration is minimal. Theoretically, one can still get a performance advantage by alternating types, but if preformance is this important you are better off just buying more RAM.
-Bigdaddy
"You can't get a blue screen on a monochrome monitor!"
You can't get a blue screen on a black and white monitor.
>HA! First reply to second post! Isn't that great >or what?
First reply to the first reply to the second post!
Opinionated Law Student Strikes Again!
Put one swap partition on each drive you have. The kernel will use whichever drive is less busy to swap on, spreading out the system load. They don't have to be the maximum size. Make whichever one is on the fastest disk have the highest priority.
You don't necessarily need 2x the size of your physical ram in swap - this is a throwback from the days when RAM was very expensive. 1x the amount of ram is perfectly fine, especially if this is going to be a single user machine - lots of swap is only useful when you either have a lot of users that are idle (i.e. stay logged in when they aren't there) or programs that take up more memory than you can afford.
I've also heard of ideas like putting small swap partitions inbetween normal partitions, so that the disk heads don't have to move as much. Anyone have luck with a setup like that?
Also, AFAIK the 127MB limit is a kernel 2.0.X an older requirement - 2.2.X supports bigger swap partitions.
I didn't see this mentioned here, but swap space is used up before the machine fills up the physical memory. This is useful so you have a couple of megs free to run a new program, instead of having to wait to swap crap out first. /proc/sys/vm/freepages. I can't remember where the documentation for this is, but it specifies the limits of when to start swapping and when there's so much memory free it can move it back out of swap even if its not yet been requested.
You can tune this by echoing 3 numbers to
I like to set these numbers big to force swapping out sleeping processes and leave plenty free RAM to speed up starting netscape or emacs, whatever.
For the record, tmpfs is not used for swap space and /tmp can be mounted on a real file system instead of mounting it on swap (ramdisk).
-- Creativity knows no medium
Memory is so cheap that I think there's no excuse to be using *any* swap space. Check your memory usage every so often, and if you're using swap space then buy more memory.
That said, I agree with the other poster that swap space can be useful for long-term idle programs. And a decent sized swap area is cheap insurance against some program taking up a lot more VM than you expect - I've occasionally run out of VM (thanx, Netscape!) and it is not pretty. But your active applications should never hit the swap disk.
Of course, this assumes that you're using a recent motherboard and additional memory is available. I still occasionally use a 386 maxed out with 20 MB of RAM. In that case I do have a very large swap partition (when compared to the amount of RAM) and accept the performance hit.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I've heard you can get some extra performance
out of swap partitions at the lower cylinders
of the hard drive. More so with the larger
drives coming out these days.
Can anyone confirm these rumor/theory?
That recommendation comes from Unices that tye a page of swap to each page of ram. Linux (and Solaris) do not work this way. They don't preallocate swap space to the existing physical memory. Any swap space increases your total virtual memory.
:) even on machines with a lot of memory. That allows the operating system to page out extremely idle processes (such as that big vi session you opened last week and forgot about) and use the freed physical memory for what would otherwise be a low priority task, such as mapping a couple of additional active files to memory.
Another issue comes from how the swap is accessed. Some Unices, such as Solaris, automatically alternate between their various swap partitions, resulting in distributing I/O over all the swap devices. It is my understanding that Linux uses them linearly by filling one, then the next. I have not tested this, however. If this is the case it reduces the performance penalty of putting more than one swap partition on a single physical drive.
As a general rule, I configure a swap partition (or several
Geeky modern art T-shirts
That was one of my first concerns when I first installed Linux as well. I tried it first without a swap partition (Caldera 1.1 mentioned that a swap partition "might be necessary with a low amount of RAM"), since I figured I would be OK without it, and the resulting machine wouldn't run. I had to repartition and reinstall a few times to get it right. Good pratice. :)
My current Linux machine has 192 M of RAM, and I've gotten away with using one single swap partition of the max size (127 M). I've never had a memory problem, and I have a tendency to run a lot of server stuff (for example, an LDAP server, a mod_perl copy of Apache for development, a mod_roaming copy of Apache to host my department's Netscape profiles, MySQL, and several other custom services), not to mention the many programs I use in the foreground at any given time (several copies of Netscape, several xterms (some running Emacs!), same-gnome, Gnumeric, etc).
With 128 M of RAM, you probably won't use a swap partition too much, so one should be sufficient. A swap partition is really most essential on low RAM machines (16 M or less) running X or serving a lot of users.
I say put it as the only partition on a fast disk (maybe a small dedicated SCSI drive... you must a few old ones lying around).
darren
(darren)
Go ahead and increase the swap size.. The reason you don't see more than 2 MB of swap usage is not because you have unbelieable light software - it's because you have too small swap size.
I myself used to have a "small" swap too, and linux almost never swapped more than 2MB. Then I increased it to be 160MB (I have 80MB memory), and even as we speak Linux has swapped out 26MB. This is because Linux behaves differently if it has lot's of space to swap on or if it hasn't. If Linux hasn't got a space to swap on and the memory becomes full, it simply throws some unused stuff "out". If it has enough swap space, it swaps in the same situation. And since when the stuff is again required it's faster to load it from the swap than from the disk (yes, I know, the swap is located on the disk too) this is the preferred method.
--
It has to work - rfc1925
Everybody likes to come up with their magical number or multiplier for swap. They don't really make sense. If RAM + swap = total mem, then just make sure you have enough swap to increase your total memory to that needed to run all apps you think you will be running concurrently. i.e., bring up every single think you *think* you might want to run at the same time, and then check you memory usage. Make your swap = used memory - RAM.
.5 RAM maybe .5 RAM
I really don't understand the 2x multiplier. Um, if I have 500 MB of RAM, that means that I need 1 G swap!!?? Right! The more RAM you have, the LESS swap you should need. Should be something like:
swap =
or
swap = N +
Striping is cool...you can do that with swap under NT too...heh, NT even gives you one big stripe of useless data down the middle of your partition for "recovery". That's what I call New Technology...
It's 10 PM. Do you know if you're un-American?
Yes, inactive processes get swapped out...then the disk cache caches the swap, then they can get read in faster.
This is sort of weird, but must happen. It sort of begs the question, what is the optimal tradeoff between swap and cache (i.e., the more swap you have = the more can be swapped out = the more disk cache can grow = the more swap can be cached) ???
Maybe Linux doesn't cache swap...should be a flag somewhere...
It's 10 PM. Do you know if you're un-American?
I've got a PPro 200 with 128 megs ram and 128 megs swap and I've had no problems. The machine is basically my workstation, but there are a few internet/multiuser services running on it (web server with a small rarely used site, FTP server, POP e-mail for 1/2 a dozen people, a couple MUDs). I'm also usually running X with the GNOME desktop, GIMP, Netscape, a 1/2 dozen xterms, and a couple other applications at any given time.
I rarely hit swap unless someone does something drastic on one of the muds (causes a new zone to be loaded is the most common reason).
This machine has been reloaded a lot (ahh the joys of experimenting), and I've tried putting swap partitions on different parts of the drives, varying the size of the partitions, using swap size of 2x ram, and I discovered that for what my box does a second swap partition was useless because it never got used. Also, I was never able to actually notice any difference in performance based on location of the swap partition on the drive.
If I were running a production web server, or an Oracle server than I would worry about it a lot more, but if you're just putting together a machine for your own use and don't plan on doing anything incredibly memory intensive, 128 megs of ram and a 128 meg swap partition should suit your needs just fine.
Although... now that I'm running Seti@Home my memory useage has gone up, but even so I still rarely hit swap.
My experience has been 2x RAM is safe, at least if for any reason that you hit swap you are safe. Also RedHat 6.0 and Mandrake 6.0 allow > 128MB swap partitions.
Alex DeWolf
Yep did it...
/swapfile
/dev/vg00/lvol2
Linux: dd if=/dev/zero of=/dev/hda1
almost all of the swapped processes died with strange signals but the systep keep running on
Linux with swapfile: rm -f
the file is no more here but the disk space is not freed 'till next reboot. system works fine...
HP/UX: lvreduce -L 1
biiiig mistake - system dumps regs and dies
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
In general, I never use swap on Linux. If you have 128Mb+ RAM and aren't doing anything spectacular, why bother with swap? The kernel often finds excuses to use it, bogging the sys down with disk access...
I generally locate my swap partitions at the beginning of the disk, starting at cylinder 1. This places the swap at the outer edge of the platters, where the read/write performance is up to 50%(?) faster, and there is a shorter average seek time from most of the data partition. The impact on the data partition's performance should be minimal, and performance in heavy swapping should actually be better due to the shorter seek times between the two partitions (someone should check this).
to my understanding, NT should keep the paging file from fragmenting, at least if you are using NTFS. if the size is locked, then there should never be a problem anyway. and if you put a paging file on every possible partion, as microsoft recommends, performance should be pretty good.