Even smaller reconstructions, when several of them are to be processed concurrently on an MP system, have similar appetite for memory. Writing swap routines for intermediate data storage (as I have done in the past) definitely slows down development of these kind of high accuracy algorithms and should be avoided.

Interestingly, it seems that under those conditions – a swap space several times the size of RAM (say in the >100GB range) – some swap space management algorithms “paint themselves” into a corner and kill processes before they have made use of the available swap space (time delays/pauses in writing to virtual memory can save the day – avoiding process kills).

In summary – just filling the RAM to the physical MAX may not solve the issue for a given machine nor is it efficient in terms of computing resources. Thus the question remains – how much swap space may/should you safely allow for. Would that not remain a problem specific issue?

My desktop system has 4gb of RAM and an Ubuntu 10.04 variant. I forced it to use about 1.3gb once. I ran 2 VirtualBox session with Redhat and Fedora, Firefox, Gimp and VLC all at the same time. This was when I was using a 30gb SSD drive for swap space. I never even got the system to use 2gb of swap space. Ok, maybe it used more than 1.3gb for a few microseconds, but the average was much less. Typically, my desktop uses less than 500mb as well.

Try the command ‘vmstat -s’ to see how much swap space is used. Most of the time it’s 0 k on both of my systems. I tend to agree that swap space isn’t really needed if you have enough RAM. I think the Ubuntu default of 136% of RAM is more than enough.

OpenSuSe swap usage? How do I measure it?

Main op sys is VISTA (HP PAVILLION notebook DV6514TX, 320 GB HDD, 3GB RAM). Vista has a 4gb partition, with operating set swap drive. At the moment (48 processes, physical ram 78 %), it uses 1 gb swap disk. [Freeware: Process Explorer]. Linux is used to correct Windows crashes.

Windows is preferred because of better applications: Dragon Naturally Speaking, latest hardware, Servant Salamander, Cobian Backup, Omnipage, ….

Windows & applications make use of “temp” directories. I put all my temp folders (4 of them in Windows) on the first partition of my fastest drive. Being a common notebook, it has only one, not counting the slow external USB drives.

Greg Zeng, Australian Capital Territory

For server environments, it is a different story.

You see, while you never want to use swap space (in the I/O sense), the system has some interesting issues that it has to deal with when handing out memory, and the default choice Linux makes is very bad for reliable environments.

Here is a summary:

When a program asks for memory (via malloc, or indirectly via fork(), which has to make a copy of the running process), Linux assumes that the request is larger than it really needs. This is a reasonable assumption in the majority of cases. For example, in a shell, every time you run a command, the data set of the shell itself is marked copy-on-write, and is therefore a potential memory sink if that new shell were to continue running. In reality, the next thing that happens in 99% of the cases is an exec(2), so that those potential memory drains are immediately thrown out.

Basically, in order to run with little or no swap, the kernel has to lie and tell all comers that memory is available. If that turns out to be wrong, then it KILLS whatever program ends up actually needing the memory at some future time when none is available.

The problem is that there is no way to make a memory “guarantee” with this policy. It’s a bit like selling too many tickets for an airplane: you don’t know who is going to get bumped. So, say your Java VM calls a native method that does a fork() of a 1GB process, gets a bunch of copy-on-write pages, and then starts to to touch them like made…something is going to break, and it may not be the JVM. That is the problem. If the timing is wrong, it could be your production database that gets the axe!

People talk about “old” or “vintage” UNIX systems that made you have twice the amount of swap as RAM.

This had nothing to do with small memory systems. It had to do with guarantees.

Those UNIX systems were written to be very predictable in their runtime behavior, and the only way to do that is to cause memory allocation to fail in cases where there is nowhere to store the data. So, the idea is this: “Only tell me I can have the memory if it is really there (via RAM + swap)”, but the performance assumption was (as Linux assumes) that programs will ask for more than they need (which is common because of the whole fork()/exec()/copy-on-write model).

Classic UNIX requires predictability (and therefore a lot of swap space), and assumes that performance will be good because no one uses all of the RAM they ask for (e.g. swapping will be infrequent).

Linux, by default, assumes reliability, and hopes for good performance and behavior.

So, as an administrator of these other UNIX system, dealing with memory management goes like this: you expect to see swap in “use”…it means that allocations have been made against it. But it but does not mean any disk IO has happened!

What you have to do for monitoring is watch the actual swapping stats via sar or some other utility. If you are seeing swap I/O, then you need more RAM or you need fewer processes. The amount of swap “in use” is an almost useless number (other than if you run out, new memory allocations will fail on request).

Linux can be tuned to work in a fashion that is closer to this “more reliable” technique as of the 2.6 kernel line. Google on “Linux Memory Overcommit”. The basics are:

- Have at least 2MB + size of RAM. I’d recommend the old RAM*2 number…disks are cheap. This is independent of RAM size, since what you are using swap for is guarantees, not actual storage.
- Change the Kernel parameter vm.overcommit_memory to 2 in sysctl.conf

As your systems run, watch for swap I/O, which is a little difficult and misleading.

sar -B has numbers about paging, but unfortunately, paging is how all I/O happens. The vm;eff is a good indicator (you want it to be high).

If you use a swap partition then you can directly monitor the reads/writes from/to that partition itself via sar -d.

Although you can nowadays easily PLAN not to use any swap, someday, somehow, you’ll run some app that happens to use a lot of memory, and you’ll need some swap.

If you’re lucky, and you’ve got (enough) swap space configured the app will silently push some stuff to disk, when it needs the memory, and it will be almost-unused data, that you don’t notice when it has moved to disk for a while.

If you’re unlucky, you’ll notice your machine becoming slow to work with. You are then faced with a choice. You can stop the application that consumes “more than expected” memory. Or you can suspend it and continue it later. Especially if you decide to do this last option, having the swap space means a lot.

I have an FreeBSD 6.3 running on an old Duron 1Ghz, 256 MB RAM and although the computer has 256 MB of swap, it never used the swap because it only runs NAT, firewall, DHCP and Apache.

If I install more RAM, will I increase the size of swap space?
If I install more RAM, the swap should decrease, as more RAM will be available and less swap will be needed.

intelliginix.com

Thanks

My thoughts:
1. High-speed processes normally found on servers cannot actively swap anywhere near a gig and provide usable performance. Unless you typically load a lot of dead wood loaded that you can park, it will be tough to leverage much space. (Maybe a bunch of VMs that aren’t doing anything.) As server loads go up, programs that dynamically spawn processes or threads as needed require more memory because the processes run longer and thus more are needed at a time. Swap soon ends up being a performance governor since no matter how much physical RAM you have, the amount of virtual memory you can use will be limited by the speed at which you can move memory contents between disk and RAM, and the time it takes to manage the virtual memory. With the processor speeds vs. disk speeds today, the amount of useful virtual memory would be a pretty low number. You may be able to limit the number of threads or processes these types of programs can spawn so as not to render other applications unusable, however, that simply passes the delay to the service requesters in the form of timeouts in the client apps. This means the only way out is more memory and or CPU is required, and more swap space cannot help. Thus the a diminishing ratio between RAM and swap makes sense as RAM increases.

Let’s take this thought process to the next level. At one point in time, the biggest advantage of a hard drive over a floppy drive was not speed, it was capacity. Later, as processors and disks improved, there was a very big difference in speed. The hard drive felt as fast as RAM. The problem up to this point was the processor no matter how much people talked about “slow speed peripherals”. I remember the president of SUN confidently stating at a keynote at a COMDEX, “The 486 is the fastest CISC processor that will ever be made” That’s before he knew anything about it. His reasoning was no processor with varying length instruction sets could never be pipelined. The 486 dropped the bomb on that supposition and could do far more at 25 MHZ than the hottest AMD 386 could do at 40 MHZ. A CISC instruction that required 6 clock cycles could accomplish the same work that took the RISCs 200, which is why the CISC, even considering pipeline flushes, is still around today. Ever since the 486, feeding the processor from RAM has been a major problem. However, for the most part, all the way through the Pentium III, 512 megs of RAM is all they would support, and 256 was more common. Things have changed a lot since then. A few years ago AMD gave Intel in incredible beating when Intel couldn’t adequately feed their processors from memory. Intel has only recovered from that in the past year or so. So if feeding the processor at RAM speeds is such a huge problem today, how is it that we can somehow make use of gigabytes of disk space to compensate for RAM shortages? Either I’m missing something here, or the hard drive could only help for small snippets that need to be accessed very infrequently. Forget using the hard drive for swap, can you even imagine today’s processors getting anything done without using substantial RAM for disk caching? Is it possible that 2 times RAM was meant for the Pentium III and earlier where memory sizes and CPU speeds allowed virtual memory on the hard drive to be of practical benefit?

2. Workstations should be able to benefit more from swap that servers. Users cannot switch tasks 1000 times a second, thus large amounts of virtual memory can be practically used to for editing large files and parking large chunks of many programs that were loaded but doing nothing most of the time. Swap times of 2 to 4 tenths of a second are of no consequence in an environment where user programs switch every 20 seconds or more, or the occasional search and replace on a large file takes 15 seconds to complete, or minimized Photoshop pictures that take a second to reload.

For me, I think I’m going to challenge some OS developers to explain to me where all of the dead wood is coming from that they can store in swap because it surely cannot be from active processes.

Another issue is to use raid for swap. If you do that, your system can survive and continue running, if one of the disks that you use for swap fails. Given that we are talking about 2 Gb partitions, which is not much on todays huge disks, you can use more than 2 disks to use, 3 could be useful to survive 2 disk failures.

And for performance I would use the raid10,f2 or raid10,f3 layouts. The “far” layout of raid10 gives almost raid0 performance for sequential readning, and raid10 with the “far” layout is overall the best performing raid-1 like raid type. More on linux raid can be found at http://linux-raid.osdl.org and specifically setting up a system with swap on raid on http://linux-raid.osdl.org/index.php/Preventing_against_a_failing_disk

I tend to design modularly so I good grasp on what to provision them for, and the age of virtualization has made some these easier in ways, and more difficult in others. Good virtualization software will allow you to dictate how much memory you will use for your virtual machines (which makes it easier to manage machines running over a host OS).

I good monitoring tool also helps with the proper thresholds set to alert the admin if there is any sign of possible trouble.

These days, with RAM so cheap, if you are hitting swap, just buy more RAM!

The amount of swap that you should use is entirely dependent on how the system is used. If you have lots of users running unpredictable codes, then configure more swap. If you have a reasonable RAM cushion for your system’s usage pattern, you may well never touch swap. I ran a 32 GB RAM system for quite a few years using 8 GB of swap, and in all that time, the swap was never needed.

Our shop bought quite a few 1-4 GB RAM workstations from SGI over the years. They shipped pre-configured with either 128 MB or 256 MB of swap (I forget exactly which). Again, never a problem.

That said, as disks became very cheap, we started setting up new Unix workstations with 1 GB swap unless there was a specific reason that we would want to add more, and for servers, we’d typically just allocate 4 GB for swap, no matter how much RAM the boxes had. This was a high-performance environment, and again, never a problem.

We also kept a close eye on system performance (including swap usage) using sar and also SGI’s Performance Co-Pilot product (free for Linux, by the way), and that gave us more confidence in ignoring the traditional “Rules of Thumb.”

As others said, swap is also used if you configured your kernel to make core dumps for debugging or if you plan to “sleep to disk”.

Some programs do cache to disk using swap but if you don’t have any, most (like VIM) run fine fully within RAM. Swap is addressable by all programs for cache once running. Someone who does more memory management stuff can help you here.

In terms of need/reliability: For some machines, which have a rare/fixed amount of RAM that is a little small, its a must (hacked TiVO recorders or Playstation 2 running linux are examples, the latter with 256 and 32 MB of ram fixed. Yetch!) Certainly all machines, as long as your disk is good will continue to run stable abeit somewhat slower (if you use faster hdds or multiple swap on different drives this may be less noticable.)