RAM Disk for Virtual Memory

[Essence_of_War]

I say if you have enough;Use RAM for pagefile
8 gb? Make the top 2-3 pagefile
16GB? Make a 5gb one if you want.

Nothing about this makes sense on a 64-bit OS with 64-bit applications. Why on earth would you take RAM away from the OS in order to re-map the file it uses to swap to when it is out of RAM to RAM? You're creating a no-value-added middleman.

 

[ashetos]

You people should stop LOLing, the OP is not retarded and here are some reasons to hate virtual memory:

- contrary to popular belief, Windows is not writing to the pagefile when it's out of memory, it's doing it since second 0, filling the paging file with data just in case it runs out of memory. What you're thinking about is linux, whose default behaviour is like what you would expect, and there are tunable parameters in any case.

- now, that's a very good way to kill your (TLC everywhere) SSD, writing stuff to it all day long.

- also that's a great way to create interference to your 100 IOPS HDD just when you want to use it for a real reason.

- while in linux applications can allocate 2TB of memory and nobody gives a crap until you actually use the pages, in Windows the application can demand 8GB of memory to be virtual-memory backed, just in case it ever needs it. Usually, those are the problematic applications, those that will create enormous traffic in the paging file while in practice you never need all that memory cause your workloads are simply not that big.

Windows gives more control of the system's memory to the programmer, whereas in linux virtual memory is mostly transparent, the applications don't really control the swap files. I'm in the tough spot of admitting that I'd like less powerful APIs for applications in this case, just so that I can always get rid of the paging file safely, just like I do in linux.

For the bunch that will say "what if an application has a memory leak", "what if you want to use a VM", "what if your application runs out of memory" I will proudly say:

- please OS, kill my hog application. I'd rather you do that than make my whole system an unresponsive page-swap-fest where I cannot even move my mouse cursor cause of pagefile hell.

How I use the pagefile:
- under 4GB of RAM, always on
- 4GB of RAM, casual users - off, gaming or power user - on
- 8GB of RAM, light gamers - off, power user - on
- 16GB of RAM or above, always off

Peace

 

[BonzaiDuck]

I think I've set up my own pagefile for a range between 1GB and 2GB on my SSD.

Not sure how PrimoCache would resolve the problem, but I use PrimoCache for most of my machines that matter for anything. Virtual memory has a different function explained by another poster.

This is another thing that makes me balk at adding RAM that I don't need beyond 16 or 20GB. One imagines what an untweaked pagefile would look like in GB for 64GB of RAM. And with an SSD, you don't need the default size for any RAM size practical for today's standards.

 

[nerp]

Time and time again, tests have shown this is a bad idea. Get SSDs, get a lot of memory and leave the damn swap file alone. Sheesh.

 

[Elixer]

You people should stop LOLing, the OP is not retarded and here are some reasons to hate virtual memory:

Nobody here said that there wasn't a good reason to not like the slowness of virtual memory, but it IS required by many programs in Windows.
Also nobody is laughing at the OP, but they wanted to have a pagefile in a RAM drive, instead of letting the program they were talking about use all available RAM there was. That made no sense.

- contrary to popular belief, Windows is not writing to the pagefile when it's out of memory, it's doing it since second 0, filling the paging file with data just in case it runs out of memory. What you're thinking about is linux, whose default behaviour is like what you would expect, and there are tunable parameters in any case.

Hmm? "since second 0?" Not familiar with that term. In any case, Windows does indeed write to the pagefile when it needs to swap out memory space, or some other circumstances.

- now, that's a very good way to kill your (TLC everywhere) SSD, writing stuff to it all day long.

Any writing to a SSD all day long will quicken the devices death, but, you would have to be writing over 50GBs a day for years before a SSD's life is expired.

How I use the pagefile:
- under 4GB of RAM, always on
- 4GB of RAM, casual users - off, gaming or power user - on
- 8GB of RAM, light gamers - off, power user - on
- 16GB of RAM or above, always off

Turning off virtual memory in Windows is highly not recommended, and as stated before, it IS required for many things.
Having a fixed sized swap file is the best practice.

 

[VirtualLarry]

contrary to popular belief, Windows is not writing to the pagefile when it's out of memory, it's doing it since second 0

"pre-emptive paging". It does that so it can discard the memory pages, in case a large RAM request comes in, since the data is being written to the pagefile pre-emptively. Unfortunately, this behavior generates a lot of I/O traffic at times.

I don't know, but it would be nice if this is a tunable in Windows.

 

[Phynaz]

These days it's 90 day trial.
Then you start with a new OS.
And do it all over again.

To save $29 on software. Pretty dumb, but whatever floats your boat I guess.

 

[BonzaiDuck]

To save $29 on software. Pretty dumb, but whatever floats your boat I guess.

I don't think PrimoCache addresses the problem. Romex SW has another product for creating a RAM disk. Either way, I'd think you'd be asking for trouble by just introducing another level of complexity with the RAM disk. If the boot drive is an SSD, the pagefile should be fine set to 2048MB or less, but above 700MB to 1000MB.

Primo largely provides the benefit of read-speed for caching frequently used programs or data. It's a very flexible and reliable program. If your system can't accommodate an M.2 or PCI Express SSD card with NVMe, Primo offers a performance boost -- more or less depending on user habits and workstation application.

The paradox of it: You can eliminate much of the swapfile size for a booting SSD. But if you hibernate your systems*, you can only limit the hiberfil size to half the RAM. But -- OK -- so far, so good.

Now, Primo offers a feature so that it will save the cache contents to disk at a normal restart or reboot, which understandably causes a delay at boot-time but it will restore you in time to a higher cache hit-rate. You can also walk on the wild side and defer writes to the disk, further improving performance in a stable system.

However, you define a fixed portion of your RAM for the PrimoCache cache, which can be shared among disks. So with that feature turned on, you're going to do writes to the disk in addition to the hiberfil and the pagefile.

So if you're worried about the odometer on your SSD, use a small pagefile size, don't hibernate your computer and don't use a program like PrimoCache. But it's really not going to make a hilla beans difference for your SSD. I have a couple that are a year old or older, and they've only passed the 5 or 6TB mark on their long journey to being "used up."