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."
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.
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.
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!
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.
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.
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 !
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
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.
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
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...).
There is one beginning, and one end. With multiple platters, the disk doesn't write one platter until it is full, then go on to the next.
It writes in parallel. That, plus higher media densities, plus higher rotational speeds == faster disks.
Put your swap on the lowest numbered cylenders that you can if you want the fastest swap. I have yet to hear of a modern drive whose cylenders are not marked starting from the outside of the disk working into the center. There are two reasons the outside of the disk is faster.
1. Rotational Speed -- More media passes the heads in one rotaion on the outside tracks. The media density is constant accross each platter, so the amount of disk real estate passing under the heads at any position is relative to the heads' distance crom the center of the spindle. If you think of each track as a line, then the length of each track is 2 * the_distance_from_center * PI.
All this means the disk's maximum throughput is realized when readin/writing to the outermost tracks.
2. Relative position -- It is obvious that the majority of the data on the disk resides near the outside edge of the disk. Also it is obvious that an equal sized partition will will take up more physical cylenders if it is positioned toward the center of the disk. More physical cylenders = more average distance for the heads to travel when seeking from one block to another when reading/writing non-contiguous blocks.
This means that the lowest average seek times for a given partition will be realized if that partion is located at the outer edge of the disk.
If you think that position doesn't make a difference, I have bonnie (a disk benchmarking program) data to back my words up. On some drives, the difference can be huge. That is why the Mindcraft benchmark, where they had both OSes on the same drives, was such a joke as far as disk IO was concerned. Can you guess which OS was on the outside of the disks (first cylenders)? (I'll give you a hint, it is not the OS that allows you to put its / partition at any location on the disk. Another hint, the OS's name starts with an 'N')
Two more things that others have said, and I would like to reiterate and add to. Put swap on multiple disks, even if there is a disparity in disk speed from one to another, and even if you only want 32MB of swap. And SET THE SWAP PRIORITIES TO AN EQUAL NUMBER BETWEEN SWAP PARTITIONS ON SEPERATE DRIVES! Some folks seem to think Linux does RAID0 for swap automaticly, but it does not. You must set the priorities or swap will be written in a serialized manner. (i.e. -- Filling up one partition before starting to fill the next.)
And finally, no matter how much RAM you have, have at least a little swap. Why? Every inactive process Linux swaps out makes more room for disk cache and buffers. On a box with 512MB that you are using as a workstation, 32MB of swap is probably fine. Linux has a real memory management system, don't tie its hands by not giving at least a little swap.
And that is my sermon for the day.
-Paul
"Life is life." --Laibach
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
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 would hope that such university and corporate environments are using real system adminstrators (or students supervised by experienced sysadmins). They will know how to tune swap and real memory for their specific needs.
My point addresses the vast majority of SOHO users who either have a single user, or at most a family or small department. They should be hitting swap infrequently, if ever.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
/etc/limits is where you can place your system limits.
You can limit how many processes can be run, how much memory can be used (total I think).
-xk
If you have 128M of ram, for now, create two 64M (or 128M if you can spare the space, but I wouldn't) swap partitions on two different drives. If you have only one drive, make it a 128M partition near the beginning ...
...
/etc/fstab:
:) ...
... (or to quickly partition and back up data to if another partition craps out).
Partitions:
/boot
SWAP
... others
... this way your kernel files are always in the first 1024 cylinders but your swap is at the fastest part of older disks (newer disks use scattering to make all reads and writes the same speed).
If you use two disks, and assuming the load on both is about the same, set the priorities to be equal in
/dev/hda2 swap swap defaults,pri=1 0 0
/dev/hdc2 swap swap defaults,pri=1 0 0
This way the Linux kernel automatically uses both partitions simultaneously for faster reads and writes. If your hard drive isn't doing anything else, you'll get twice the speed out of this.
Again, with 128M of ram, you only need 128M of swap, even for most mid-level server apps. If you want to run Slashdot on your PC, you might need more
... leave some unpartitioned space in the middle of your drive to add swap to later if you need to
- Michael T. Babcock (Yes, I blog)
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.