Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MikeGillespie]

I built a CAPS Zuma and use JRiver.

I have 8tb of music, about 250,000 songs.  All uncompressed and hi-rez.  I have maybe 150 video concerts.

Is there anything in the architecture of JRiver now to make it advantageous for me to use anything more than 4gb of memory?  I can easily put in 32 gb. 

Thanks.

[kstuart]

This is discussed in the recent thread:

http://yabb.jriver.com/interact/index.php?topic=77189.0

[glynor]

Essentially, no.

You may see a small benefit, depending on your usage pattern to going with more than 4GB (and 8GB would be the most reasonable purchase, all things considered), but unless you are doing many more high-end tasks with a workstation (VMs, video editing, high end design work, etc), going to 32GB would be terrible overkill.

[Matt]

Essentially, no.

You may see a small benefit, depending on your usage pattern to going with more than 4GB (and 8GB would be the most reasonable purchase, all things considered), but unless you are doing many more high-end tasks with a workstation (VMs, video editing, high end design work, etc), going to 32GB would be terrible overkill.

Well put.  I completely agree.

[mykillk]

Unless you're trying to decode the human genome or do contract work for Industrial Light and Magic I think the answer is none what-so-ever.

[MrHaugen]

The advantage is that you can brag about it. That's it As others mention.. .It's totally useless. Unless you do heavy computing work like editing video, or are doing MASSIVE mltitasking on your workstation.

[jmone]

I've got 16GB on my main PC as it was cheap but it rarely breaks 6GB being used.

[kstuart]

I've got 16GB on my main PC as it was cheap but it rarely breaks 6GB being used.

If you find you have unused RAM, then make a RAM Disk, and put the Pagefile on it.  (I use the freeware Gavotte RAMDisk.)

[rjm]

If you find you have unused RAM, then make a RAM Disk, and put the Pagefile on it.  (I use the freeware Gavotte RAMDisk.)

Will this make a noticeable difference if the pagefile is already on an SSD?

[glynor]

If you find you have unused RAM, then make a RAM Disk, and put the Pagefile on it.  (I use the freeware Gavotte RAMDisk.)

Sorry... Putting your page file on a RAM disk is ridiculous.  This guy did a nice write up of some of the reasons why:

http://www.overclock.net/t/1193401/why-it-is-bad-to-store-the-page-file-on-a-ram-disk

Even if you don't believe the guy writing the post (he's right), you absolutely should believe Mark Russinovich.  If you want to know more about how this system actually works from someone who is actually an expert at the internals of Windows, here's the best reference:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

The ONLY thing this could possibly help with is allocation/deallocation, which happens at boot time (and even that's iffy, as there is RAM disk overhead).  For actual system operation, any benefit you get from the incredibly small writes that happen as part of normal operation would be VASTLY outweighed by the overhead of creating and maintaining the RAM disk.

PLUS... The only time Windows really uses the page file (for more than record-keeping) is when you run out of available RAM.  So, what you're doing is creating a run-around.  Lower available RAM == more page hits.  Page hits are bad because of latency.  Accessing a RAM disk is higher latency than accessing the RAM directly via the Memory Manager in Windows.  Ergo...

There's also this stuff, by the way:
http://www.tweakhound.com/2011/10/10/the-windows-7-pagefile-and-running-without-one/
http://lifehacker.com/5426041/understanding-the-windows-pagefile-and-why-you-shouldnt-disable-it

Lastly, I've seen TONS of actual benchmarks which follow the, you know, scientific process.  If you care to look for yourself, just use the google.

1. Disabling the Page File provides either no or very, very little benefit, and it is incompatible with some software.
2. Making a RAM disk for your page file almost always decreases overall system performance, and certainly does not help.

[InflatableMouse]

If you find you have unused RAM, then make a RAM Disk, and put the Pagefile on it.  (I use the freeware Gavotte RAMDisk.)

Pagefile on a RAMdisk really is rediculous. Please read the articles Glynor provided. When people asked me about Mark Russinovich, I always answered that he's the guy that better understands how windows works than Microsoft does.

[kstuart]

I think you guys are skimming, rather than reading, since you are missing two points (both of which were brought up in the thread in the links given by glynor):

* We are talking about systems with far more RAM than ever used.   So the argument "the RAM disk pagefile will use up RAM that will give more performance by being part of available RAM" doesn't apply.

* In theory, if you have far more RAM than ever used, then the pagefile will never be used.  But as explained in the thread, it ends up being used anyway, because lots of software applications and Windows software are not written correctly according to theory.

* SO, the choice is pagefile on slower media or pagefile on faster media.

PS  To answer the question about pagefile on SSD, theoretically it will be a) slower than the RAMdisk, and b) decrease the life of the SSD by increasing the number of writes to the SSD.  However, in a "far more RAM than ever used" system, the pagefile won't be used very often, so it doesn't matter much.  And, in the real world, the lifespan of SSDs doesn't really matter, since they will all last far longer than the point where a new one will have 20 times the capacity and 20 times the speed for half the price...

[glynor]

I think you guys are skimming, rather than reading, since you are missing two points (both of which were brought up in the thread in the links given by glynor):

* We are talking about systems with far more RAM than ever used.   So the argument "the RAM disk pagefile will use up RAM that will give more performance by being part of available RAM" doesn't apply.

Yes it does, and no I'm not.  Read better*.

It may not substantially hurt performance in those cases, but there is no reason to do it either.  The pagefile is not used by anything significant until Windows becomes RAM limited (ergo, exceeding the latency induced by running the RAM disk process, and considering this initial allocation time and overhead).  This may NOT have applied to Windows 2000 and Windows XP, but it certainly applies to Vista+.

Like I said, I've seen a LOT of demonstrations from a wide variety of folks (including Mark Russinovich himself at trade shows) showing just how useless it is, (and the related bit of snake oil of how useless it is for the vast majority of applications to disable the page file entirely).  This includes situations even with very slow disks (SAN) and obscene amounts of RAM (when Mark did the test I saw live, it was with a USB2 boot disk on a system with 128GB of RAM).  When you actually test it, the results fall well inside the realm of statistical noise (like I said above, except possibly boot times, though this probably doesn't even apply with SSDs and modern versions of Windows).  Sure, you can cherry pick one particular benchmark (of some broken application), but overall, the results are clear and consistent....  Roughly as many things will be 0.03% better as those that are 0.03% worse, and you're still reducing the total amount of commit capacity you have on the system (not to mention the hassle and effort of setting it up).  For what?  Why?

I absolutely stand by this:

If you have the RAM available, just let Windows use it.  If you are paging out (so whether the page file exists or doesn't exist matters at all), then buy more RAM.  It costs essentially nothing now for the amounts normal people need.  Buy 8GB and be done with it, and just ignore the page file, because it'll never be used in day-to-day operation.

If you feel otherwise, fine, you can do what you want.  If you want to tell me I'm wrong, I expect to see hard numbers and proof, not vague theory, because I have seen just the opposite (and done plenty of testing myself over the years).

I'm sorry... That's why I said what I did in the other thread, and I didn't really want to get into it, but...

Sigh.

* Here's an example...

But what if,
someone has let's say 32GB ram.
Dont you think moving the pagefile to a RAM DISK is a good ideia ?
Much faster data transferes, and no problem with low memory commit.
You explanation is great for low memory systems, but what about systems with huge memories?

No, because in the case of 32GB of RAM, paging will hardly occur. There's plenty for process working sets, and the memory manager will move least frequently used pages into the standby list, which is in RAM instead of having to write them out to disk. Note that modified pages will get moved to the modified page list, and eventually written to disk when memory pressure becomes high. With 32GB of RAM, this will hardly happen.

You are just taking up RAM for something that probably won't be accessed frequently.
Look at it this way: If placing the page file on a RAM disk with 32GB of RAM is a good idea because of faster data transfer, then why not just use RAM instead! (Which is what will happen).

but aren't there some programs that use page file independent of the size of the RAM?

No. Programs don't use the page file directly. They don't get to choose where their memory is stored. They simply ask Windows for a chunk of memory, and it either satisfies the request if it fits within system commit, or fails if it does not. (Admittedly this is a very watered down explanation).

This is the important distinction between virtual memory and physical memory.

What you were most likely seeing was 1.5GB of virtual memory committed, and 10GB total virtual address space usage (this wouldn't be possible on 32-bit systems, though as the process address space is only 2GB regardless!). It may have reserved 10GB virtual memory, but only actually touched 1.5GB of it. Only when a program touches its reservation (write/read) does Windows commit it.

[rjm]

When people asked me about Mark Russinovich, I always answered that he's the guy that better understands how windows works than Microsoft does.

And a decent techno-fiction author. Just finished his audiobooks "Zero Day" and "Trojan Horse". They were good but not excellent like Daniel Suarez's books.

[glynor]

PS.  kstuart... Please don't take offense.  I absolutely do NOT mean anything personally towards you.  I just see this time and time again, both online, and in my support roles.  People flipping over to accomplish nothing (or extremely little) because the arguments "seem" to make sense.

You can do what you want, like I said.  And, perhaps, it really works for you, placebo or not!  I'm not trying to tell you what you are doing is wrong (or right) for you.  I just do NOT feel it is a good general-purpose recommendation.

Very similar to the 32-bit vs. 64-bit discussion.  For some uses and some systems does the RAM limit matter?  Heck no.  But it might, you lose nothing by using the 64-bit version (they cost the same and all current hardware supports both), and you do also lose the security and other performance benefits of the 64-bit version if you intentionally choose the 32-bit version.

It basically boils down to this:

The vast majority of users (even "expert users") with most software (that which isn't essentially a timed process or a benchmark themselves) cannot distinguish consistently between systems with a measurable 10% performance difference in blind tests (I've seriously helped participate in user studies proving this).  Doing something like this is fiddly, prone to breaking, and will certainly NOT provide (even best-possible-case) anything remotely approaching a 10% performance difference.

Like I said, in all of the tests I've seen from places/people that I trust (with documented, repeatable procedures), the differences are well within the realm of statistical noise.  If I'm wrong, show me how to prove it, and I'll test it myself.  I'm happy to admit I'm wrong when I am, but you have to show me the numbers and the methods that prove it so they can be replicated.

[glynor]

And a decent techno-fiction author. Just finished his audiobooks "Zero Day" and "Trojan Horse". They were good but not excellent like Daniel Suarez's books.

That's cool.  I didn't know he was doing that now.

[kstuart]

I think you are still missing the point.  You wrote:

1. Disabling the Page File provides either no or very, very little benefit, and it is incompatible with some software

and you linked a Lifehacker article which stated:

In addition to applications crashing anytime you run up against the memory limit, you'll also come across a lot of applications that simply won't run properly if the pagefile is disabled. For instance, you really won't want to run a virtual machine on a box with no pagefile, and some defrag utilities will also fail. You'll also notice some other strange, indefinable behavior when your pagefile is disabled—in my experience, a lot of things just don't always work right.

Which is exactly what I said in my previous post.

Theoretically, with way more RAM than you will ever use, the pagefile should never be used - but it is.

When it is used, it is faster to put the pagefile on unused RAM than a hard drive.

Anyway, at this point, I am starting to just paste the counter arguments from the link that you pasted:

http://www.overclock.net/t/1193401/why-it-is-bad-to-store-the-page-file-on-a-ram-disk

There are many pages of arguments and counter arguments.

The commonality between this argument and the 32-bit vs 64-bit argument is that in both cases, each is being presented as an absolute, but in both cases, it depends on the specifics.

The following is part of a post on the overclock.net discussion you linked.  It is, of course, only one data point, but it is a good example of the difference between theory (where pagefile will never be used with 32GB RAM) and real life where Windows is coded with all sorts of errors:

About six months ago while reading a post about a possible micro-stutter fix I came across my eventual solution: A RamDisk dedicated to pagefile as the only paging file on my system. I have found a few similar posts since then.

It is exactly because I DO NOT have a lack of understanding as how Windows is SUPPOSED to use the paging file and the causes of micro-stutter that I completely disregarded this fix for another five months and I might have never tried it had I not found a free win 7 64bit certified RamDisk App.

With nothing to lose I gave it a shot. To my surprise this completely eliminated all micro-stutter and the 2nd issue (occasional Audio/Video stutter) has been completely eliminated as well.

[glynor]

I think you are still missing the point.  You wrote:and you linked a Lifehacker article which stated:Which is exactly what I said in my previous post.

Theoretically, with way more RAM than you will ever use, the pagefile should never be used - but it is.

The fact that Windows (and some software for whatever reason) expects the Page File to be there, and reacts poorly when it finds an unexpected condition is not evidence that the use of the Page File on disk in non-RAM-limited situations impacts system performance.  Like I said, there IS some additional disk activity when the page file is on disk, but the writes are TINY and bookkeeping related (and can be done in the background where they don't impact latency).  But there is also additional CPU and memory subsystem load for running a RAM disk.  Which is worse?  I'd trust the guy who knows the kernel inside and out to know what he is talking about.

In fact, the most common problem you'd ever encounter if you turn off your page file is running out of memory when you run something unusual that does require a bunch of RAM.  In those cases, using a RAM disk would hurt not help, because the total available commit capacity of the system is lower.  Lifehacker doesn't tend to get into the nitty gritty details as much.  Have you read the entire Mark Russinovich series?  Because I have, and I saw him speak while he was in the process of writing them.

I'm a video editor.  The system I'm writing this on right now has 64GB of RAM, and certainly actually uses it.  We're a very concerned bunch, generally, about memory performance.  And some of the imaging systems down the hall that I use to generate videos (from EM systems and other more esoteric microscopy systems) have even more absurd memory demands.

But that's why I know a lot about both the "suggested fixes" that are all out there, and why many (but not all) of them are snakeoil.  Your other example from the extreme overlockers thread is a perfect example...

I've read TONS of those kinds of comments used as "evidence" of the value of a particular tweak... Correlation does not equal causation, and anecdotal evidence isn't evidence.  I have NO IDEA what that guy's system might have been doing to cause his issues, and his "solution" may or may not have had anything to do with the problem at hand.

Just to take that example... His issue could have just as easily been cause by malware that went dormant for some reason (maybe because it "saw" the system changes, and was programmed to go dormant if it looked like a tech might be banging on it, to avoid detection).  It could have been hardware problems on his disk, that he "avoided" by moving the page file off of the failing disk.  Likewise, there could have been SATA driver problems on the system (well documented with AMD chipsets) that caused generalized disk access problems (again, avoided by moving the page file off of disk, but you'll eventually hit those problems anyway).  Or, like many users, he might have been doing multiple "troubleshooting" steps at once to solve the problem, without a systematic approach, and now he "thinks" his problem was solved by the RAM disk, when really it was the GPU driver update he did, or a Windows update that happened, or that the disk got defragged in the background, or who knows what else.

There's way too much variability in those kinds of examples to glean anything useful from them, other than... Cool story, bro.  Glad your problem is solved.

If it isn't documented and repeatable, then it doesn't exist (or might as well be placebo).  It certainly doesn't suggest a "general" suggestion of "if you have unused RAM, this is a good idea".

Like I said, I've seen countless, repeatable, documented demonstrations showing that system-wide, this type of "fix" does not help general system performance (with numbers from multiple tests and a process to replicate).  Like I said, can you cherry pick one benchmark example?  Sure.  Software is broken all the time.  Find better software, or help the vendor fix the issue.  If you start applying targeted "fixes" like that without a very rigorous systematic approach, you're as likely to spin into a situation where you're "fixing" one problem over here, while creating 12 new problems over there.

PS.  And, it depends what he means by microstuttering, but "real" microstuttering is usually caused by the GPU design or drivers.  It isn't even a very precise use of terminology.

[BillyBoyBlue]

All depends what you want to use all that RAM for. I get by fine with just 8 GB and I often am doing multiple instances of high end video rednering using Sony's Pro Vegas with multiple projects rendering at once while still having other high end apps like Photoshop running while still surfing the web, chating in forums and having music playing in the background. Helps to have a high end CPU and be running a 64 bit system.