Anyone else using Ramdisk in Windows 7?

[kyrathaba]

What's your opinion on this:

Windows willingly swaps its own code from memory to make room for your other programs. But since Windows code is the most often used when you run your system, swapping it can slow things down. You can save swap time by making Windows lock its own kernel in RAM, as long as you have enough memory (512MB).

Note that the Registry controls all swapping of the kernel, and any erroneous alteration in the Registry can make your PC inoperable. Use the program Regedit (usually found in your Windows or WinNT folder). Click on My Computer | Local Disk (C:) | Windows | Regedit.

Expand the listings to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management in the left-hand half of the window. Highlight DisablePagingExecutive on the right-hand side. Then click on Edit | Modify and enter the value 1. Click on OK, close Regedit, and reboot your computer.

[Stoic Joker]

With a habit of multitasking I frequently have 50 to 100 things going at once as I (am forced to) bounce from one project to another. So I tend to hedge my bets a bit and run a fixed size 2GB PageFile with 4GB of physical RAM on a 64-bit machine.

With that configuration and work load, I've never had any stability issues with this machine running either Vista or 7. And the machine is almost 5 years old now.

[Stoic Joker]

What's your opinion on this:

Windows willingly swaps its own code from memory to make room for your other programs. But since Windows code is the most often used when you run your system, swapping it can slow things down. You can save swap time by making Windows lock its own kernel in RAM, as long as you have enough memory (512MB).

Note that the Registry controls all swapping of the kernel, and any erroneous alteration in the Registry can make your PC inoperable. Use the program Regedit (usually found in your Windows or WinNT folder). Click on My Computer | Local Disk (C:) | Windows | Regedit.

Expand the listings to HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management in the left-hand half of the window. Highlight DisablePagingExecutive on the right-hand side. Then click on Edit | Modify and enter the value 1. Click on OK, close Regedit, and reboot your computer.

-kyrathaba (August 26, 2011, 07:25 AM)

Seemed like a nice tweak back in the 2k days, but I haven't used it in years.

[kyrathaba]

Right now, here's what I've got:

I have 6 GB RAM installed on this Win7 Home Premium 64-bit machine.  I have a 1.5 GB RAMdisk installed, but I'm allowing Windows to manage the pagefile.  I've tweaked the registry to force Windows to keep it's kernel solely in RAM (no reads from disk).

Before doing any of these steps, I've created a restore point each time and I backed up my registry before applying the tweak.

Do you think I'm in good shape?

[vlastimil]

No, but have fun  Peace!

[kyrathaba]

So, vlastimil, you think I need to ditch the RAMdisk altogether?

[vlastimil]

Indeed, unless you need it for a special purpose to solve a particular problem.

[Stoic Joker]

I'm with vlastimil

Also keeping the kernel trapped in memory is about as effective as having all of the shift managers at a burger joint all show-up for the same shift. They'll all just be tripping over each-other because they are not all needed at any one given time.

Windows is actually really good at memory management. So it's best to just leave it be, so it can do its thing.

[kyrathaba]

Okay, thanks guys.

[Deozaan]

I've got a Minecraft server running in a VM on a RAMdisk. There's lots reading and writing of terrain data, especially with multiple players connected, so the RAMdisk can really speed things up.

[kyrathaba]

I moved the Windows TEMP directory to the ramdisk via the Windows environment variable.  I would think surely that makes sense, in that it will automatically ditch unneeded temp files when I reboot.  Although, considering that I don't make heavy use of my machine, I'm leaning toward not using the RAMdisk at all.

[MilesAhead]

Maybe not as much fun as using a ramdisk but I think I get the same results by having Firefox (3.6 with lots of extensions) load in at startup and then minimise itself - so it's ready and waiting. The next important part is to keep FF open all day, minimise if need be (even to the system tray) just don't close it.

Does a ramdisk offer much more than this? If so, I'll have to try it, I mean, does a ramdisk make FF faster in actual operation and not just loading up?

-nudone (August 26, 2011, 05:07 AM)

Depends on your setup. If you are on a 32 bit system with more ram than Windows can directly utilize then the RadDisk may be able to handle stuff like browser cache without writing to disk or "costing" you anything of system ram.  But it's probably not worth doing just for that. I don't like to leave a bulky app sitting idle.  If you have a zillion FF extensions to do everything then your method is preferable.  I didn't really run that many other than to maintain stuff related to the browser like uploading bookmarks, checking for dead bookmarks etc..  with Chromium I only have 4 extensions installed.  The bookmark checker is disabled until I run it manually. I don't need all the maintenance extensions that I did with FF. I'm only running AdBlock, LastPass and SpeedDial.

One other side-effect of running FF out of RamDisk is you let sites put on whatever cookies they want.  When you close the disk, discard everything.  No cookie filters, hunting for tracking cookies, and all that bother.  Just use a password tool to login to sites.

I got rid of my RamDisk as soon as I got with Chromium.  So for me it wasn't worth the bother. I couldn't think of any other real need to carry it around.

[Edvard]

Myth - "Putting the Paging File on a RAMdisk improves performance."

Reality - "Putting a Paging File in a RAM drive is a ridiculous idea in theory, and almost always a performance hit when tested under real-world workloads. You can't do this unless you have plenty of RAM and if you have plenty of RAM, you aren't hitting your paging file very often in the first place! Conversely, if you don't have plenty of RAM, dedicating some of it to a RAM drive will only increase your page fault rate. Now you might say "yeah, but those additional page faults will go faster than they otherwise would because they're satisfied in RAM." True, but it is still better to not incur them in the first place. And, you will also be increasing the page faults that have to be resolved to exe's and dll's, and the paging file in RAM won't do diddly to speed those up. But thanks to the paging file in RAM, you'll have more of them. Also: the system is ALREADY caching pages in memory. Pages lost from working sets are not written out to disk immediately (or at all if they weren't modified), and even after being written out to disk, are not assigned to another process immediately. They're kept on the modified and standby page lists, respectively. The memory access behavior of most apps being what it is, you tend to access the same sets of pages over time... so if you access a page you lost from your working set recently, odds are its contents are still in memory, on one of those lists. So you don't have to go to disk for it. Committing RAM to a RAMdisk and putting a paging file on it makes fewer pages available for those lists, making that mechanism much less effective. And even for those page faults resolved to the RAMdisk paging file, you are still having to go through the disk drivers. You don't have to for page faults resolved on the standby or modified lists. Putting a paging file on a RAMdisk is a self-evidently absurd idea in theory, and actual measurement proves it to be a terrible idea in practice. Forget about it."

This has to be one of the most over-worked tech topics on the internet.
It always happens when somebody learns what the pagefile does (or the swap partition on Linux) and what a RAMdisk is, puts two and two together and comes up with five.
Okay, YES having a page file in memory IS IN THEORY faster than having it on disk, but in real-world use, it is NOT faster than just using that same chunk of memory as... memory and leaving your pagefile on the disk.
Every argument around this topic ends up arguing for a snake eating it's tail.

Ram disk is beneficial if you need a small, super-fast hard disk for a special purpose. For example when compiling a very large project, where the compiler creates and accesses a lot of temporary files. In other cases, it hurts, because it blocks Windows from using the memory you dedicate to it. It is better to simply leave the applications running.

I actually like this idea, good point Vlastimil.  
I don't doubt that there are actual usage scenarios where a managed RAM disk is a good idea, and the software in question seems like an easy way to set up and manage that.

As for your benchmark results, Kyrathaba, that's probably the THEORY portion of the argument actually working, but while memory requirements are still low, when it would be expected to.
I would put it to the test and do some things that traditionally force Windows to use up a lot of RAM and hit the pagefile on your system.
Heavy surfing with lots of tabs and all extensions enabled, then firing up Photoshop and doing some processor-intense editing, lots of blurs and transparency, edit some HTML in Word, then switch between the applications.
Then you'll REALLY see how it's doing.
I'd be curious as to the results...

[MilesAhead]

I don't use office tools but I've heard rumors some won't run without a page file. If you really don't want a page file on your HD and have more ram than Windows can access normally then it may be useful to stick the page file in the ram disk.  But I don't use office tools anyway. Seems like a simpler solution would be to write the software so that it doesn't insist on memory it doesn't need.

For cutting down on disk thrashing and you have such excess ram on a 32 bit machine then it may be easier just to dedicate some to a disk cache.

Another special case, which may help regardless of the bitness of the OS may be use of some script tool or batch that insists on seeking in disk files to get data on every access.  Putting the data file in ram might be useful especially if nobody can figure out the script.

[f0dder]

What's your opinion on this:
*snip* DisablePagingExecutive *snip*

-kyrathaba (August 26, 2011, 07:25 AM)

Not sure if the memory manager honors the settings these days, or how big an effect it has - but it was a huge advantage for me back in the Win2k days. Without the setting, after quitting a game I'd have a lot of page-in activity before my system was usable again. With the setting, much less.

After I got enough memory (the WinXP days and ever since), I've turned off pagefile.sys entirely, so the setting would be superfluous. And I don't agree that better performance from turning off the paging file is a myth, even with plenty free memory Windows tends to trim process working sets a bit aggressively - at least it definitely did so in the XP era, might be better at 'wasting' memory with Vista and Win7.

I prefer chugging enough memory in my system and not worry about the pagefile - but it's only an option if you can always having enough physical memory available.

Fixed size pagefile is a bit silly, by the way. Set it to a large-ish minimum size to avoid fragmentation, but why set a fixed upper size? (OK, the one reason I can think of is shutting down a runaway leaking 64bit process before it fills your drive... but that's about it).

I don't use office tools but I've heard rumors some won't run without a page file.

-MilesAhead (August 26, 2011, 04:49 PM)

Not true for office2000, 2003 or 2007.

As for RAM drives... as mentioned previously, putting your pagefile on a ramdrive is utterly moronic - don't do it. They can be nice for other purposes, though. I keep my %TEMP% there, and apart from a few badly designed installers and the stupid way Flash caches videos, it works very decently. Putting my firefox profile there also made the fox a lot less sluggish (but of course you have to have a backup scheme if you don't want to lose stuff on a power outage).

Oh, and then there's specialized use cases like compiling Boost or grepping through huge codebases

[MilesAhead]

Fixed size pagefile is a bit silly, by the way. Set it to a large-ish minimum size to avoid fragmentation, but why set a fixed upper size? (OK, the one reason I can think of is shutting down a runaway leaking 64bit process before it fills your drive... but that's about it).

Setting the maximum guarantees it won't be fragmented. I've removed page file, defragmented the disk.  Then enabled paging with min=max.  Months afterward checking the page file for fragmentation shows it never needs to be defragmented.  Zero maintenance.

On my 8 GB machine paging is disabled.  On my 2 GB machine I have a 4 GB page file just because I got one out of memory error in 4 years running no swap due to having a dozen Chromium tabs open while doing a video mux.  No swap is the best swap unless you have to use some memory hog app. I prefer lightweight processes unless I'm getting some kick-ass performance that justifies the bulk.

[f0dder]

Fixed size pagefile is a bit silly, by the way. Set it to a large-ish minimum size to avoid fragmentation, but why set a fixed upper size? (OK, the one reason I can think of is shutting down a runaway leaking 64bit process before it fills your drive... but that's about it).

Setting the maximum guarantees it won't be fragmented. I've removed page file, defragmented the disk.  Then enabled paging with min=max.  Months afterward checking the page file for fragmentation shows it never needs to be defragmented.  Zero maintenance.

-MilesAhead (September 01, 2011, 12:31 PM)

Setting the pagefile to a reasonable minimum size means you'll never get fragmentation under normal working conditions, but if you should need the extra swap... however unlikely... it'll be available rather than your application running OOM. If you've got little enough memory (or extreme enough applications) that you need swap, that seems to be far the superior solution to me.

And even if you do get into the extreme situation and it causes fragmentation... so what? Once system is back to normal memory usage, the file will be shrunk and you're back to your minimal-size file in one fragment.

[MilesAhead]

Fixed size pagefile is a bit silly, by the way. Set it to a large-ish minimum size to avoid fragmentation, but why set a fixed upper size? (OK, the one reason I can think of is shutting down a runaway leaking 64bit process before it fills your drive... but that's about it).

Setting the maximum guarantees it won't be fragmented. I've removed page file, defragmented the disk.  Then enabled paging with min=max.  Months afterward checking the page file for fragmentation shows it never needs to be defragmented.  Zero maintenance.

-MilesAhead (September 01, 2011, 12:31 PM)

Setting the pagefile to a reasonable minimum size means you'll never get fragmentation under normal working conditions, but if you should need the extra swap... however unlikely... it'll be available rather than your application running OOM. If you've got little enough memory (or extreme enough applications) that you need swap, that seems to be far the superior solution to me.

And even if you do get into the extreme situation and it causes fragmentation... so what? Once system is back to normal memory usage, the file will be shrunk and you're back to your minimal-size file in one fragment.

-f0dder (September 01, 2011, 12:36 PM)

Run your machine your way.  This has worked for me across many machines across many years. No maintenance no crash. The "so what" is having to reboot the machine and defrag the page file for no reason that I can think of. If you really think "so what" then just let Windows manipulate the page file in the first place. No stress.

In fact I only got OOM because I ran a brute force script to load pages in Chromium to refresh favicons(at that time Chromium lost favicons on nearly every snapshot update.)

Now that I have Bookmark Sentry extension I may as well disable the pager.  But it doesn't seem to hurt anything so I guess I'll say "so what."

[f0dder]

Run your machine your way.  This has worked for me across many machines across many years. No maintenance no crash. The "so what" is having to reboot the machine and defrag the page file for no reason that I can think of. If you really think "so what" then just let Windows manipulate the page file in the first place. No stress.

-MilesAhead (September 01, 2011, 02:15 PM)

1) I can't remember if windows will only shrink the paging file on shutdown, you might be right on that point... but you're going to do that in due time. Can't really see why you'd reboot just for the shrinking?
2) you don't need to defrag - when the pagefile is shrunk to minsize, the additional extent(s) are simply removed, and you're back to your 1-fragment file.

I really don't understand the reasoning behind setting a fixed size. Either you have a ludicrously large pagefile, or you acknowledge you can run OOM. IMHO it's pure logic to set a minsize to "somewhat more than you expect to see (and have measured) under normal use", and without maxsize (or a "sanity limited" maxsize if you must) - you get the best of both worlds:
1) no fragmentation under normal working conditions
2) perhaps fragmentation, but temporary so (without needing a defrag), instead of running OOM.

So, is there a flaw in my reasoning? Or are you just sticking to "that's the way I've always done it, because I read on some tech site that's it's the thing to do"? 

[MilesAhead]

Run your machine your way.  This has worked for me across many machines across many years. No maintenance no crash. The "so what" is having to reboot the machine and defrag the page file for no reason that I can think of. If you really think "so what" then just let Windows manipulate the page file in the first place. No stress.

-MilesAhead (September 01, 2011, 02:15 PM)

1) I can't remember if windows will only shrink the paging file on shutdown, you might be right on that point... but you're going to do that in due time. Can't really see why you'd reboot just for the shrinking?
2) you don't need to defrag - when the pagefile is shrunk to minsize, the additional extent(s) are simply removed, and you're back to your 1-fragment file.

I really don't understand the reasoning behind setting a fixed size. Either you have a ludicrously large pagefile, or you acknowledge you can run OOM. IMHO it's pure logic to set a minsize to "somewhat more than you expect to see (and have measured) under normal use", and without maxsize (or a "sanity limited" maxsize if you must) - you get the best of both worlds:
1) no fragmentation under normal working conditions
2) perhaps fragmentation, but temporary so (without needing a defrag), instead of running OOM.

So, is there a flaw in my reasoning? Or are you just sticking to "that's the way I've always done it, because I read on some tech site that's it's the thing to do"?  

-f0dder (September 01, 2011, 02:43 PM)

If the page file size never even approaches the minimum what's the point of having a larger maximum? I can see if people run memory hogs like giant spread sheets.  But for my usage there's no need for it.

It's my experience that people argue about swap more than they actually use it.
I only have 2 GB ram on this machine and ran for 4 years with no swap.  So why should I subscribe to your formula?  On my side I have about 16 years of experience with my method.  On your side I have theory.

A better solution all around is a swap partition a la Linux.  You definitely do no fragment your system partition.  If the emergency case arises you can set it to create swap file(s) dynamically if needed.  I had Linux running on a 486 with a fast EIDE drive and a slow SCSI drive.  The fast drive the swap was much faster.  But by setting the swap "round robin" to the swap partitions on each drive I got smoother performance. The speed of the system was the same but the EIDE Linux was running on didn't thrash.

The Windows options are almost laughable.  Everything is squeezed through the straw of a file system.  They could fix it but they don't care.

[MilesAhead]

Aiyy!! Yet another swap argument!  Anyone know where I can get a copy of the MS official press release with the conventional wisdom that one must always run swap?

otoh I might get bagged for posting (c) material.

[Stoic Joker]

The minimum system controlled pagefile size is 1.5x physical. So for me having 4GB of RAM in my x64 box at home, it was grabbing 6GB of drive space just for the pagefile. Which I found rather annoying (especially if it set to clear on shutdown). So not wanting to run completely without I just cut it back to a fixed 2GB size ... Which has as of yet to cause any OOM issues.

I really just got tired of trying to follow and formulate an opinion on the 0 PF safety debacle and just - said the hell with it - split the difference.

[f0dder]

If the page file size never even approaches the minimum what's the point of having a larger maximum? I can see if people run memory hogs like giant spread sheets.  But for my usage there's no need for it.

-MilesAhead (September 01, 2011, 03:02 PM)

If you never go over the minimum, no space wasted, no harm done. If you run into a once-in-a-blue-moon situation where you need the memory, you'll probably be happy your application (or production server? ) doesn't crash.

It's my experience that people argue about swap more than they actually use it.

-MilesAhead (September 01, 2011, 03:02 PM)

Yep, and you see a lot of old crap regurgitated over and over, with either the "ZOMG SET TO A MAX SIZE TO AVOID FRAGMENTATION!" or some weird magic formulas that probably made sense 15 years ago when they were first invented, but... yeah.

I only have 2 GB ram on this machine and ran for 4 years with no swap.

-MilesAhead (September 01, 2011, 03:02 PM)

I did that back with 1gig of ram (which was a bit low when gaming), but after I upgraded to 2gig (and then all the upgrades after that) without a hitch. But running pagefile-less isn't something I'd advise to everybody.

So why should I subscribe to your formula?  On my side I have about 16 years of experience with my method.  On your side I have theory.

-MilesAhead (September 01, 2011, 03:02 PM)

Because the theory makes sense? - or perhaps you can point out a flaw in the theory? There might be some scenario I haven't though of... but at least there's none of those magic voodoo numbers.

A better solution all around is a swap partition a la Linux.

-MilesAhead (September 01, 2011, 03:02 PM)

Don't see the point of those fixed size partitions these day, really - for the same reasons as my arguments against the fixed-size windows paging file. There were technical reasons for it back in the olden days, but Linux has supported file-based swap for a while now.

The Windows options are almost laughable.  Everything is squeezed through the straw of a file system.  They could fix it but they don't care.

-MilesAhead (September 01, 2011, 03:02 PM)

How is the file system a straw? As long as your paging file isn't fragmented, there's no I/O difference between file swap and partition swap... and I bet you'd be hard pressed to measure the computational overhead between handling writes to a file vs. to a partition even on many years old hardware.

Now, paging options might aren't as comprehensive on Windows, that's for sure. But that's how it always is with Windows: it caters to the majority

I really just got tired of trying to follow and formulate an opinion on the 0 PF safety debacle and just - said the hell with it - split the difference.

-Stoic Joker (September 01, 2011, 03:22 PM)

The most reasonable advise I've seen by a techie the last few years was "don't blindly follow advise, measure your needs". I still don't see the obsession with with fixed size, though

[tomos]

I dunno. I like the idea of not having a pagefile. I have a second internal hd, it's 2TB, so I made a small(ish) partition and gave it a 9GB fixed-size pagefile.
Set it and forget it. I cant go wrong (famous last words lol).
The one time I disabled the page file, I did have some problems with a couple of graphics programmes, that I presume were related to it's absence, so I went back to it. In fairness that was with 2GB ram - now have 8 so could try it again, but it'll be down my list a bit...

[f0dder]

The one time I disabled the page file, I did have some problems with a couple of graphics programmes, that I presume were related to it's absence, so I went back to it. In fairness that was with 2GB ram - now have 8 so could try it again, but it'll be down my list a bit...

-tomos (September 01, 2011, 04:30 PM)

I wouldn't be surprised if there's a few crappy shoddy programs that depend on having a pagefile present, even if there's no real reason for it as long as you have enough RAM.