Slashdot Mirror
How Much Virtual Memory is Enough?
whitroth asks: "Ten years ago, Received Wisdom said that virtual memory should be, on the average, two to two-and-a-half times real memory. In these days, where 2G RAM is not unusual, and many times is not that uncommon, is this unreasonable? What's the sense of the community as to what is a reasonable size for swap these days?"
Simple. Monitor your own resource usage and figure out what YOU require. Everyone has different hardware, programs, and habits.
I disable virtual memory on computers with more than 1GB of ram unless the user is going to be manipulating large images. Never had a problem yet.
If you really want to know, I use 1-2 GB swap with 1GB ram and the same for 512MB ram.
However, you might just do what I do and try out different values to figure out what works. If you're talking about a linux system a real-time memory/swap usage graph can be added to most window managers so that you can see what's happening. You could also try to estimate usages based on what the machine is expected to do.
-Tim Louden
system control panel -> advanced -> performance options -> advanced - > virtual memory.
Set to no paging.
Do you even lift?
These aren't the 'roids you're looking for.
To control how much 'it will swap' on Linux: /proc/sys/vm/swappiness
#echo [0-100] >
A better question is how much memory you can address. Could your 32 bit Windows system address over 2^36 bits of memory (64GB), for example? And could you allocate over 2GB to windows kernel?
Could your 64-bit linux system address over 2^48 bits of memory?
Obama likes poor people so much, he wants to make more of them.
Swapping out makes sense sometimes, though. For instance, there are tiny chunks of the system -- daemons and such -- that are pretty much never accessed. I'd rather reclaim that, if only to cache something worthwhile.
Also, remember that suspend2 requires swap, so figure how much of an image you'll need (and how much is cache that can be freed) and get a bit more than that. My own rule of thumb is, swap is roughly 1x to 1.5x RAM, so that I can be sure I have room for the suspend. But I have the space, and Windows doesn't use swap for this anyway, it uses hiberfil.sys
Don't thank God, thank a doctor!
Linux has futzed with this a lot (and lets the user tweak VM behavior a lot, but /proc/sys/vm/swappiness goes a long way...), both linux and Windows will swap well ahead of not having free memory (for good reason). Just wanted to go into detail because I keep seeing people complain that they see swap used in linux or windows when they still have free memory, not realizing this isn't a bad thing generally.
There are generally two strategies:
-The common-sense one where you swap when you run out of memory. This makes a lot of practical sense on systems with limited write cycles (flash based swap, though you really never ever should do that anyway), and systems that want to spin down drives to conserve power for battery conservation. Performance wise (this may surprise people who haven't spent time thinking about it), this can often be bad. Avoiding swapping is generally only good on systems where resource utilization is carefully managed and you know it won't swap ever (the IO operations of unneeded can interfere with the productive activity of a constantly busy system). This is actually a vast minority of systems in the world (no matter how l33t one may think themselves, they most certainly don't have a usage pattern that would be impacted by the extraneous IO operations of occasional write to swap.
-Pre-emptive swapping. When the IO subsystem is idle and the system can afford to copy memory to swap area, it does so (depending on criteria). Generally speaking it will select memory not accessed much and write it to disk, but leave the memory copy in place if the physical memory is not immediately needed. A fair amount of swap used in an apparently underutilized system is duplicated in physical memory and swap space. The benefit here is that if the process reads back that memory, it doesn't incur any penalty in reading it back despite it being also in swap (the system may make certain decisions on what is the best swap candidate and write to disk different data). The benefit of writing this stuff to swap even when not needed is clear when an application comes along that allocs more memory than the system has free in physical space. In the first strategy, this means the malloc blocks while data is written to disk, and the new application starting or needing a lot of data is severely impacted. In the pre-emptive swap case, system notices the condition, knows what memory it has a backup in swap of that hasn't been used lately, and can free that memory and satisfy the malloc pretty much instantly.
To those who have 1GB of RAM or so it becomes less likely that the system will have to flush memory from physical RAM, but there is a balance to be struck between memory used directly invoked by applications, what the application memory access pattern is, and what ram you can use to buffer filesystem access. If your total application memory allocation is 75%, it still may make sense performance wise to only keep 50% of your physical memory dedicated to the applications, (the other bit relegated to swap), and 50% of the memory to buffer disk I/O.
XML is like violence. If it doesn't solve the problem, use more.
This works really well until the one day you leave everything running, startup halflife and flick around the levels (uses memory faster...)
bleeding thing cannot smoothly say "You are running out of memory, Setting up an emergency page file now...." without something crashing.
Fix this problem and you are cooking on gas. A modern computer should be able to accomodate every malloc upto memory+free disk space and it can't easily.
liqbase
This is completely wrong.
/tmp.
In Windows, your RAM is saved to a file called "hiberfil.sys" which is the exact size of your physical RAM. Your swap file stays exactly the way it is, otherwise you'd lose the data that was swapped to it.
In Linux, it depends on what program you are using to suspend, but typically, it's a file in
On Mac OS X, swap is stored (by default) in files in the /var/vm directory on the boot hard drive, instead of on a separate partition. So there's no limit to how much is used, nor a predefined minimum amount of space used, the swap space expanding and contracting as needed. That seems reasonable.
Signature.
Man, it's utterly depressing to see the same useless "rules-of-thumb" still in effect when the original question is asking if the rule-of-thumb is a good idea.
1) Page space is not swap space. There's a small distinction that's generally lost (and generally ignored). Page space is used to move memory pages to and from disk. Swap space is technically to move entire processes out to disk. The difference is mainly based on when your OS was created (i.e., technological underpinnings) and no need to get into it now... but the difference is meaningful.
2) Page space is not *free*. There's a misconception that if you have 500G of disk space then "how does it hurt" to put 8G of swap on 4G RAM. Depending on your OS, the size of the page table can grow remarkably depending on how much memory (RAM + VM) is allocated. This means that adding 2G of page space may not cost anything, but adding 2.5G may suddenly take up another chunk of real, non-pageable memory because the page table cannot itself be paged. This means that if your app is thrashing, then adding page space may make it worse.
3) Even with lots of RAM, it's still often a good idea (depending on your usage) to have some page space. Modern OSes will still page out unused pages to use RAM for better stuff. I.e., if you have a huge file open in a graphics application, but are not actively using that application for a length of time (an hour, say) then the OS will page it to disk. This makes better use of your physical RAM. On some OSes the OS will use page space even if free RAM is available. It can then toggle a page out by flipping a bit in the page table and not have to do an expensive write.
4) In some systems you can overcommit memory. Applications tend to request a lot more memory from the OS than they'll actually use. This is useful in many instances but it again depends on your usage. If you're running a single application that doesn't dynamically allocate memory then you can run pageless. If a new app requests memory that's not available then it will get a failure on malloc request. This can be desirable in some circumstances.
5) There are benefits to running page space on a separate disk, but for the vast majority of home users, the difference is negligible. This applies to Windows and Linux. Once you start stressing the VM subsystem then a separate disk is highly desirable.
6) You can create page files on Unix/Linux. It's not desirable generally because of the extra filesystem overhead and possibility of fragmentation. But hey, in a pinch it works.
7) Why this 2x RAM rule? A lot of it comes from old VM subsystems that needed a "picture" of the entire memory space. This made the page-out algorithms easier to code. Newer algorithms don't require the 2X RAM.
KL
VM != VA. You're confusing the two.
/3G switch (which can hurt other parts of the system because it reduces the memory that the kernel can use)).
VA is Virtual Address space. For a 32bit processor, you have 32bits of virtual address space - each process can occupy no more than 3G of RAM (on XP, with the
If you have more than one process, you have more than one virtual address space. So saying that each process can only address 3G of RAM doesn't matter - with 30 processes running, you could theoretically have 90G of VA allocated.
What's important is VM.
VM is vitual memory. VM is what backs the pages that are mapped into the VA.
The maximum amount of VM you can have allocated on a machine is measured by the commitment limit on the machine, which is typically measured as "physical RAM + page file space". If overall VM always stays below physical RAM, you don't need a paging file. But if it EVER goes above it, you're toast if you don't have a paging file. All those pages from the boot process that normally would have been discarded to the paging file (or were allocated by daemons that started during boot but haven't done anything since then) stick in the craw of the memory manager taking up space that COULD be used for your application, but can't because you've not told the OS where to put them.
That's why you have a paging file - it gives the OS a place to put the mouldy old pages that were allocated by apps that aren't actively doing things so your application can re-use the memory that those apps were using.
Btw, it's my understanding that ALL modern virtual memory based operating systems have essentially the same VM architecture - Linux, Windows, whatever. They both use paging files for essentially the same things - discarding writable pages that are not in current use by applications (read-only pages can typically be loaded from the binary image).
There's no real hard and fast rule anymore. And setting it against a static value (like physical memory) is incredibly wasteful.
It's a much better idea to set it interactively. Use the system without adjusting the Virtual Memory for a while. Then take a look at your usage and set your virtual memory against that usage.
For instance.
If you're in a Windows machine, let it run normally for a few days.
Run everything the way you normally use it.
Multiple apps, multiple instances, games out the ass, everything.
Then open up the Task Manager and look at the Performance tab.
Take a look at the Peak value under "Commit Charge".
Set your virtual memory, min and max, at about 10% above that value to leave yourself a little headroom.
Normally this will be enough to deal with your maximum swap requests.
If, somehow, you begin bumping against virtual memory limits again AFTER that, bump it another 10%.
If you still have problems, keep bumping it in 10% increments, and start looking for apps that are memory leaking.
Chas - The one, the only.
THANK GOD!!!
Don't you hate meta-sigs?
"One other (Linux) server has big processes (1Gig or more) and when they have to swap out, watch the machine fall apart while the process is swapped out - it takes a while to write 1 gig of ram into swap! Since the process is large, swap needs to be large.... Just hope that server needs to have 3 or 4 multi gig processes swapped out...."
n it), which segments the memory in 4-64KB of pages.
You seems to miss the idea of swap. All modern OSes combined with processors (from 386 in the x86 range) will swap 4KB pages. So if memory is needed, the last accessed page (4KB) in RAM will be swapped (and the algorithm continues until no more RAM is required). When one of the swapped 4KB pages is needed, it's retrieved from swap in free RAM (if no free RAM is available, it swaps out another page).
I don't think it swaps out all of your application, and if it does, you should increase you RAM. The thing is that your app can try to access the "just swapped" page, which is a preformance killer. Swapping is done on page chunks, not app chunks.
PS: the term pagefile probably comes from windows 95 because it contains "pages". All modern processors have MMU (http://en.wikipedia.org/wiki/Memory_management_u
Or to put it a third way, is there any situation where swapping is helpful, anymore?
:)
Sure. Consider Andrew Morton's logic:
http://kerneltrap.org/node/3000
In your average program, most code never gets executed, and most data is never used. For a long-lived process, swapping out the unnecessary bits frees the memory for disk cache.
While you may improve overall performance, by minimizing the average completion time for operations, the downside is responsiveness. As a user, I don't care if Firefox reads cached images a few milliseconds faster (by reading from cache instead of disk) if I have to wait 3 seconds for Thunderbird to respond to my clicks (because it has to swap in) after I've been browsing for a while. Average speed be damned!
Having said that, I just set my swappiness to 100.
Here is The True Word from a MCSE of long standing on the subject of virtual memory and windows (please note that nearly every person who has worked with windows will have a different true word):
All windows: defrag your drives first.
Win98SE: if RAM is =/> than 256mb, make Min setting equal to the amount of RAM, Max set to 1.5 the amount of RAM.
If less than 256mb, set min setting to 1.5 times amount of ram, max to 2.5 times or 512MB, whichever comes first.
Winnt:
if you have 2 drives (not two partitions, two drives) create swap files with min/max equal to the amount of physical memory in the system on 2 drives. This is a way to make WinNT scream when it comes to disk writes
Otherwise, if RAM is less than 256mb, set Virtual memory, both min & max, to twice your amount of RAM; if you have => 256MB, set min & Max to 1.5 times the amount of RAM.
Win2k: if you have less than or equal to 512MB, set min to 1.5 times RAM, max to 2 times RAM. if you have greater than 512mb, set swap min/max to 1.5 times RAM.
If you ever get an "out of virtual memory" error, defrag and add 100mb to min/max.
If you have =/> 2GB RAM, disable swap, unless you are running server, in which case 4GB is the magic number.
The 2 drive swap method just doesn't seem to work as well on Win2k as it did on WinNT; no clue why, but i've tested it repeatedly.
WinXP Pro: Luser. why are you running the Windows ME of the 21st century? at least you aren't running WinXP home, though. just follow the guidelines for win2k, since that is all WinXP pro is, win2k with add-on crap, no changes to kernel or underlying function.
Win2003: No clue.
Vista: Not only have no clue, but I promise you I never will.
Why, yes, I AM a Pagan Libertarian.
The VM Size listed in Activity Monitor is not the size of the swapfiles. I'm running on a machine with 1 GB RAM, my VM size is 6.53 GB, but I only have 128 MB of swapfiles. You might find it interesting to intall MenuMeters http://www.ragingmenace.com/software/menumeters/ to keep track of what's going on.
But that's the ONLY way to fully answer the question.
The old guideline of swap size = 2X RAM size still holds as RAM usage (application bloat) / system memory increases automatically mean swap space increases. But that was a general purpose guideline, and the guidance has ALWAYS been to set your swap space size to what you need based on actual usage. your only other option is to just set it to a ridiculously high number.
If you are concerned about something yet are unwilling to spend 10 minutes educating yourself on how to deal with your concerns, then you have to live with the current situation or pay someone to handle your concerns for you. There is no magic bullet.