• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Only 2gb of ram, how do I pagefile an ssd?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
*sigh* i should have read.... o well OP BUY MORE RAM AND BE PATIENT TILL IT GETS THERE.
 
And that still doesn't answer my question, if you have got the room for it why wouldn't you just max out the page file? Even if you have a full load of ram, why wouldn't you pus for every last bit of performance you can get? Is there some detriment to virtual memory besides the speed penalty and used space? Why would you tell him that 10gb is too much? If it is 96x slower then he ought to be using (96 x 6gb) to achieve his goal right? Eve though that is an unrealistic page file, once again why would you even bother with less than the maximum amount?
 
And that still doesn't answer my question, if you have got the room for it why wouldn't you just max out the page file? Even if you have a full load of ram, why wouldn't you pus for every last bit of performance you can get? Is there some detriment to virtual memory besides the speed penalty and used space? Why would you tell him that 10gb is too much? If it is 96x slower then he ought to be using (96 x 6gb) to achieve his goal right? Eve though that is an unrealistic page file, once again why would you even bother with less than the maximum amount?

why would you max out the page file and waste SSD space it makes not sense, when he gets more ram his page file will hardly be used, you need like 2 to 4 GB max. really.

MORE PAGE FILE DOES NOT MEAN MORE PERFORMANCE!. PAGE FILE IS SLOW NO MATTER HOW MANY GB YOU USE IF YOU HAVE A 100GB PAGE FILE ITS JUST AS SLOW AS A 1GB PAGE FILE.
 
It did answer the question, actually...

You need to know how a page file works...https://www.google.com/webhp?source...hat is a page file and how is it used&es_th=1

You really want to LIMIT the amount of pagefile you use honestly because, as I just mentioned above, it is A LOT slower than system ram. Some people even DISABLE IT (which I personally do not recommend as some applications REQUIRE one). A page file is used minimally unless you fill up the capacity of your ram. If you "max out" your page file size, chances are, nothing is going to fill it so then you have all this space allocated to the page file and you can't use it.
 
Last edited:
I feel the failure here is in how I worded my question. Yes 100gb is just the same speed as 1gb, but having 100gb usable is much better than having 1gb full... So more is better. Except for the cost in storage space. I do see from Earthdog's explanation that all that page file may never get used. It was my assumption that a memory hungry program would continue to use memory (or page file) until 1 of 2 options had been reached 1) the program reaches an optimal level of function or 2) the page file is exhausted. This was my error. I apologize. I am very used to working on low ram systems and rarely have seen a page file that is not in heavy use. Most of the time I've had to add to the page file just to get the OS to run smoothly even with all the aero and animations off.
 
100gb is just the same speed as 1gb, but having 100gb usable is much better than having 1gb full... So more is better.
In that extremely elementary example considering no other variables, I agree. However, taking into consideration things like, there is no chance the VAST majority (think 99%) of PC's will NOT come close to using more than a few GB of a page file, why would you put such a large PF on there? That makes no sense at all as it is just a monumental waste of space as nearly nobody would use it. And if you are using that much pagefile, you either have a memory leak, or you need a shed load more ram.

There is a reason why we suggest people get 8/16GB of ram because for most people that is PLENTY and it doesn't write out to the PF much unless required or somehow they managed to stuff the available system ram full. So why would you set a page file larger than 16GB even if you were rocking 1GB system ram when its not used? It does not just sit there and constantly fill.
 
It does not just sit there and constantly fill.

That's why I apologized. I though ram just kept on being used. I'm getting my Linux learning (unused ram is wasted ram) crossed with the almost nothing I know about Windows. Not that I know anything about Linux either... I just thought that was how all ram was utilized. As I said I apologize.
 
That's why I apologized. I though ram just kept on being used. I'm getting my Linux learning (unused ram is wasted ram) crossed with the almost nothing I know about Windows. Not that I know anything about Linux either... I just thought that was how all ram was utilized. As I said I apologize.
I'm not sure you are getting clear answers here. I think your question is fair. It is worth thinking about what the pagefile does and how that compares to swap on Linux and how all that relates to memory usage, and why setting a large pagefile wont help with performance.

The adage "unused ram is wasted ram" is as much true in the Windows world as it is in the Linux world. (It is also a personal favorite of mine. If you search this forum you will see that I've used it many times.) Because unused ram is wasted ram Windows essentially keeps all your ram in use all the time (unless you really have lots of ram like 32GB+, in that case it can run out of stuff to keep in memory). Ram not used by programs running gets used to cache frequently accessed stuff from the drive.

Because ram is essentially full every time something needs more memory the Windows memory manager has to evict something else from ram. In order to decide what to evict the memory manager keeps track of your usage patterns and assigns each page in memory a priority (from 1 to 7 if i recall correctly) and will first evict low priority stuff. Mostly that low priority stuff is cached stuff from the drive. But it is also possible that the memory manager will kick out some stuff used by a program in favor of keeping some cached stuff around. This mostly happens if there is some program that marks part of its memory as low priority. If the program that you are using starts needing a lot of memory Windows will also kick other programs out of ram because the application with focus gets higher memory priority.

When the memory manager kicks something out of ram what happens to that memory depends on what is in it. If the memory happens to be a file loaded from the disk windows will just forget about it since it can always load it from disk again. On the other hand if the memory contains data the program has generated or gotten from somewhere else than the disk windows will write the data to the pagefile.

So how do size limits on the pagefile affect this process? The important thing is running out of memory. If you have some memory hungry application that is filling up memory with data then you can end up in a situation where the combined ram + pagefile size limit is not enough and Windows will have to start throwing out of memory errors. That usually means things will start crashing. Even if the situation doesn't get so bad that you run out of ram and pagefile but the current program still ends up with using all ram and having part of its memory in the pagefile you will experience a huge performance drop because it constantly has to read and write to disk to do its work (aka trashing) .

But would a pagefile size limit hurt your performance if you don't end up in any of the bad scenarios above? Not usually. If you ever hit a situation of running out of pagefile you will hit out of memory errors, which will ruin your experience much more than slow performance. There is a corner case if some application is caching stuff in memory that it will throw away in case of memory pressure because it can regenerate it, but usually this sort of stuff starts happening when running out of ram. Another corner case is if you have lots of ram but a tiny pagefile and some program has lots of low priority memory that would get thrown out to make room for high priority disk cache. There are also more complicated scenarios where the availability of memory affects the willingness of the Windows memory manager to commit to memory which can affect the behavior of allocators and garbage collectors in the programs.

I promised to compare the pagefile to Linux swap, which I haven't done yet. One key difference is that on Linux swap is a separate partition. This has the effect that the size is fixed. On Windows the pagefile is just a file (hence the name) and so growing it is no problem. In fact, by default, Windows will grow and shrink the pagefile as needed. This is why your suggestion to set a big pagefile is completely unnecessary. If Windows needs more pagefile space it can always grow that file and then shrink it back when it no longer needs it. This is also why the OP's quest to fiddle with pagefile setting in Windows was misguided and wont have any beneficial effect on performance. The one catch is that growing the pagefile can cause it to become fragmented, which can have a negative effect on performance if the pagefile is on a hard drive. On an SSD like in this case it doesn't matter.

One hardware aspect worth mentioning, not directly related to Windows memory management, is that SSDs slow down as they fill up so setting a large pagefile would actually hurt performance from that side as well.

There are some other interesting differences between how Windows and Linux handles memory commit that relates to pagefile/swap size, but this post is getting long enough as it is.

EDIT: Oh dear, I didn't actually realize how long this thing was until I actually posted it.
 
Ive got to apply for an ssd mind... My read and write speeds are low with information intensive posts :)

Thank you for the thoughtful answer and please do continue with what you were saying about the page file/ swap partition (in a separate thread if need be) I truly do find it wonderful how many things can be emulated with enough storage space ( I've got an app that builds virtual equipment to interface between smartphone and desktop! Fascinating!) and take every chance I can get to learn more about virtual hardware. The real issue with reading about such things is the accessibility of the literature for the layman, so I relish the chance to read a post like the one you made above, where the higher levels of knowledge were brought to a place that I could understand as well. Thank you sir. I will keep this stuff in mind when setting my own page file (or building a swap partition... Whichever OS I happen to be on at the time)
 
I promised to compare the pagefile to Linux swap, which I haven't done yet. One key difference is that on Linux swap is a separate partition. This has the effect that the size is fixed.

Two things wrong with that.
First, mkswap works just as well on a regular file as it does on a partition, but then you are of course going through whatever filesystem overhead there is wherever that file is located, so nobody who knows better does that.
Second is a semantics nitpick: the partition isn't what fixes the size. mkswap fixes the size. You can increase the partition (or file) size all you want, but mkswap, just like any other mkfs command, put bounds on what portion of the partition (or file) is used. Of course, with the various notifier systems in the kernel, there's nothing stopping you from creating a dozen 1 GB swap spaces in LVM and having a script dynamically swapon/swapoff them depending on load :)
 
I think the phrase "virtual memory" is where I became confused. It was my mistaken belief that the page file was used as additional ram (albeit slower-yet-better-than-none-ram) up to the value set as the size of the page file (or swap partition). If I understand the above explanation correctly Windows will ear mark ONLY certain types of data to be moved to the page file, these things being data that would be held in ram otherwise, so having a really gigantic page file is useless because the types of information that get sent to page file would almost never add up to an abnormally large size.


For my own information and understanding is the script pettyg359 is talking about similar to letting Windows manage the size of the page file?
 
For my own information and understanding is the script pettyg359 is talking about similar to letting Windows manage the size of the page file?

Yes. I don't like a variable size page-file, though. You're just adding extra erase cycles to that SSD every time Windows changes the size of the file.
 
Yes. I don't like a variable size page-file, though. You're just adding extra erase cycles to that SSD every time Windows changes the size of the file.

I have an example I'd like to run past you, but it rather labored and there isn't much I can do about it.

As always if you would like to read the article I am paraphrasing from, I will try to find it for you to provide a link, but as of now, just paraphrasing :) I read an article that tried to explain how the trim command worked in terms of data storage on an ssd and why it is better. Apparently the hierarchy of storage demands a type of "header" or something with the rest of the data being stored in sub "directories" under that "header". These exist as a cohesive unit. When Trim is run, the header is removed asking the already written sub "directories" appear empty and available for rewrite. In this way erase cycles are saved as well as time. So after that paragraph of stuff I almost understand I have a couple of questions : 1) am I missing something about how trim command works? At this point all I really need is a simple grasp. 2) if that is true, can the trim command be applied to the page file in some way to overcome the limitation in the above post?
 
can the trim command be applied to the page file in some way to overcome the limitation in the above post?

No. TRIM just lets an OS make the SSD do discards / garbage collection at opportune times, since the OS can guess when the system is idle or not in need of disk I/O. Cell erasing is an aspect of Flash memory that you're not going to get around.
 
Back