Indexing and Page File on SSD

[satrow]

Ah, ok Bill, I'll reset Windows to defaults because MS knows my usage better than I do. Thanks :thumbsup2:

 

[Digerati]

Ah, ok Bill, I'll reset Windows to defaults because MS knows my usage better than I do. Thanks

I don't understand that answer. Perhaps now I am reading more into it than I should. But it sure "sounds" dripping with sarcasm. If I am misreading, then I apologize.

Of course they don't now YOUR specific usage. But they sure know how millions and millions, 100s of millions of "normal" users use theirs. And they know not one of them (except maybe POS and other dedicated purpose systems) utilize memory the same, day after day after day. Or even hour after hour.

Contrary to what some folks think, with nearly each and every one of the 1.4 billion Windows systems out there being unique, very few are so unique that the MS defaults Windows sets up during install, and dynamically during use are so far off "optimal" that they need user intervention.

Again, I am not talking about XP - which IMO, benefited from user intervention. I am talking about modern operating systems, (W7 and especially W8) - operating systems designed for modern, not legacy hardware.

And finally, they know that the vast majority of users don't pay attention to those sort of things, nor do they want to. Nor they should not have to! The job of any OS is to utilize the hardware resources it has available. Memory management is an OS function and MS has making and refining OSs for some time.

Microsoft may have some misguided people in their marketing and PR departments, but their OS development teams are some of the sharpest experts in the world. They sure are a lot smarter, and way more educated and experienced in memory management than me! And as a hardware guy, building, configuring, and optimizing hardware resources is something I've been doing for a very long - perhaps too long - time.

You made it clear you use yours for testing software, and you monitor your systems carefully and regularly, then make adjustments as necessary. I said clearly, if you know the pros and cons of what you are doing, and are disciplined enough to keep watch and adjust as needed, "then kudos to you" and "go for it"!

 

[Digerati]

Rats! I cannot edit my post. I said, "Nor they should not have to!" Obviously not right. I meant, "Nor should they have to!"

 

[jcgriff2]

Dealing so often with BSOD dumps + the system files generated by the OP BSOD app, I'm used to seeing page file sizes = installed physical RAM + a few hundred MB.

My Windows 7 HP laptop has 4 GB RAM; Windows allocated the page file @ ~ 4.2 GB - exactly what I would expect.

Interestingly, my Windows 8.1 HP laptop has 12 GB RAM; Windows allocated the page file @ 1.96 GB.

My page file settings are managed by Windows.

The above numbers are the "page file base allocation size". You can check out your system's page file info + virtual memory peak & current usage by running one of these two WMI apps -

To check your system's "Recoveros" (Recovery) and Page File settings via Windows Management Instrumentation (WMI), run the following -

HTML output - WMI - "Recoveros" and Page File Settings (HTML)
Text file output - WMI - "Recoveros" and Page File Settings (TEXT)

From this thread: https://www.sysnative.com/forums/bsod-crashes-kernel-debugging/9599-bsods-but-no-dump-files.html

My Windows 8.1 12 GB RAM system's current readings:

AllocatedBaseSize=1856
Caption=C:\pagefile.sys
CurrentUsage=66
Description=C:\pagefile.sys
InstallDate=20131220133842.488186-300
Name=C:\pagefile.sys
PeakUsage=184
Status=
TempPageFile=FALSE

It tells me that Windows allocated the page file originally on 12-20-2013 with a base size = 1856 MB. The current size of my page file = 1946 MB.

Current virtual memory usage = 66 MB (likely due to several Notepad's being open - Notepad writes directly to the page file)

Peak virtual memory usage (since last re-boot) = 184 MB

hyberfil.sys on my Windows 8.1 system = 10.25 GB (~85% of physical RAM)
swapfile.sys " " = 268.4 MB

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\>dir /a *.sys
 Volume in drive C is Windows 8.1 x64
 Volume Serial Number is C8D9-F1EF

 Directory of C:\

[B]08/01/2014  12:49 AM    10,250,895,360 hiberfil.sys
08/01/2014  12:49 AM     1,946,157,056 pagefile.sys
08/01/2014  12:49 AM       268,435,456 swapfile.sys[/B]
               3 File(s) 12,465,487,872 bytes
               0 Dir(s)  431,010,742,272 bytes free

C:\>

Something changed in Windows 8.1 (v. Windows 7) as the page file base allocation size had to be > installed physical RAM in order for BSOD kernel dumps to be produced (in Windows 7, Vista).

So... I'm surprised to see the page file allocation is < installed physical RAM on my Windows 8.1 system. I haven't had any BSODs yet, but have confirmed that the system can generate user-mode dump files just fine.

 

[Digerati]

Interestingly, my Windows 8.1 HP laptop has 12 GB RAM; Windows allocated the page file @ 1.96 GB.

Right! Just because Windows 8 can use more, it does not mean it will. But it will always make a small PF for dumps, unless disabled.

But sadly, too many still have past experiences with older versions of Windows dictating their actions and decisions. Many feel the old rule of thumb of 1.5 X RAM = PF still applies, or that Windows 8 will use that formula if Windows is allowed to manage the PF.

1.5 x RAM was great when users had 2Gb of RAM but not realistic when systems now come with much more. On this 16Gb system I am using, for example, W8.1 recommends 5627Mb (5.6Gb) and has currently allocated just 2432Mb. Hardly a space hog. And on a SSD, even a relatively slow SSD, hardly a bottleneck - when compared to even the fastest conventional HD.

So... I'm surprised to see the page file allocation is < installed physical RAM on my Windows 8.1 system.

Again, W8 is not XP or even W7 and virtual memory management has come a very long way in recent years with Microsoft's W8 development team fully understanding the vast majority of systems with 8Gb, 12Gb or 16Gb of RAM don't need 12, 18 or 24Gb of disk space allocated to a swap file. So I am not surprised at all with your figures. Windows 8 does not just use your installed RAM to calculate the PF size. It also takes into account the size of the disk, the amount of free space, and more importantly, how you are "currently" using your computer.

While you see a PF of <2G today, if you were to fire up a bunch of other applications and start them actively crunching tasks (that is, they are not just sitting idle), you will likely see your PF allocation has increased. This also explains why the size during your initial setup is different from today.

Note too Task Manager has been totally overhauled in W8 and it MUCH more informative than previous versions.

 

[tension]

I have both disabled on my ssd, I didn't notice a drop in performance.

It was mostly done to save space and prevent extra writes.

Absolutely Correct, If you run transfer rate scans "Bench32", you will see improvements, not much, but there is.

See...:grin1:

https://www.sysnative.com/forums/ha...-am-i-wrong-nope-dont-think-so.html#post94092

 

[tension]

Thanks. :)

Would moving the page file to my HDD be a good idea do you think?

BAD....
Keep on SSD. If fast systems. turn off. Windows WX will make temp if needed.

 

[tension]

I think there's some confusion here, and some misconceptions based on obsolete, superseded information and inaccurate perceptions.

Would moving the page file to my HDD be a good idea do you think?

Absolutely NOT!!!!! SSDs are the perfect place to put your page file. See SSD FAQs, Should the pagefile be placed on SSDs? (almost 1/2 way down the page).

I also see absolutely no reason to disable indexing when using a modern OS (W7 - 8.1). We MUST let go of XP and stop stereotyping W7 and W8 based on problems with XP. W7 and W8 are not XP. Indexing in XP was horrible. Indexing in W7 and W8 is not the same as XP. In W7/8/8.1 indexing has been highly refined to minimize impact on performance while indexing (stepping way into the background when the user is NOT idle).

But most importantly, we much realize that, BY FAR the most significant impact caused by Indexing is when Indexing a drive for the first time - NOT forever thereafter. Once indexing of a drive is complete, all indexing must do after that is keep track of any changes - and that takes next to nothing in system resources.

It was mostly done to save space and prevent extra writes.

If a small SSD and already low on free disk space, then saving space may be important, but it is important to note again, this is not XP and that PF size management in W7 and W8 is NOT the same as with XP. If you are not using your SSD for PF due to a lack of free disk space, I HIGHLY URGE you to free up space or buy more space and then move your PF to the SSD. And let Windows manage the size - and I don't care how much RAM you have.

It is also important to note that today's SSDs do NOT suffer from the limited writes problems of first generation SSDs. Limiting the number of writes is no longer required and IMO, stifles a significant advantage for using SSDs in the first place.

Remember, there have been SSD-only notebooks for several years now and more and more PCs are being built with SSDs only (including this one).

Hmm???View attachment 10732

 

[tension]

I know my own usage pretty well, one size does not fit all.

Exactly! And that is why Windows managed page files (with W7 and W8) does not use a one-size fits all PF, or even a fixed size PF. Our system environments are constantly changing - a modern Windows will vary the PF size as needed.

The problem with users setting a fixed size (even if they properly analyzed their VM use) is that is just a snapshot analysis. Tomorrow or next week your environment and VM usage may change. Letting Windows manage the size accounts for that.

If you set your PF manually and don't regularly revisit your VM use and adjust the PF size accordingly, you are doing yourself a disservice.

RAM and SSD's are there to be used to their best potential

Agreed. And putting the PF on the SSD takes advantage of that potential.

no point in wasting costly drive space when RAM should be doing the heavy lifting.

How is it wasted if there is still plenty of space for Windows to operate in? If 12Gb of disk space is that critical, you need to buy more space.

Also, I feel you believe forcing Windows to use RAM instead of the PF is a good thing. It is not.

Understanding the Windows Pagefile and Why You Shouldn't Disable It

So sorry. I know there are some real Windows experts here, but the PhDs and supercomputers at MS are pretty sharp too. Unless you have advanced compsci degrees, I doubt anyone here is capable of properly sizing their PF, AND keeping it properly sized with the environment.

As for Indexing, that is more of a "convenience" feature rather than a performance feature. If you don't have a need to quickly find things on your drives, or if you have installed an alternative indexing/search feature on your computer, then turn Indexing off. But frankly, I don't see any advantage doing so.

How much install ram, help's choose the correct settings. These are 64 bit OS setups only, and your Bootable SSD only.
6GB or less leave it all on. 8GB's to 12GB's your have options. 16GB's plus to limits, Turn it off. IMHO. These don't apply to server setups.

 

[tension]

Even Mark Russinovich has changed his tune on page file sizing some 3 times, maybe more, and that's just where he was trying to generalise - for the majority of users.

Right! But Mark also says to just let Windows manage it if you are not going to take the time to properly analyze AND UNDERSTAND your virtual memory requirements.

I've changed the page file sizes some 4 times on my main PC since #5 here, simply because my workload is frequently changing

Which is exactly why I recommend users let Windows manage it - especially with modern versions of Windows - even among experts. For one, Microsoft has had more than 20 years to tweak the process. But more importantly to my (and your) point is things change. You can analyze your virtual memory and set a "fixed" page file size and that may be perfect - today. But tomorrow, you may install or uninstall a program, update Windows, or otherwise change your computer or your computing habits, changing the optimal settings for your PF. But unless you regularly go back in and re-analyze your requirements, you can easily, and users often do end up with a PF setting that is not optimum.

Modern Windows takes care of that for us and does a darn good job of it too.

Bill, that doesn't take into account any real world usage for machines with multiple drives, increasing disk I/O on the System drive when there are alternatives with usually lower base I/O levels might not be the best plan.

My System drive is an mSATA SSD with read/write speeds of 265/251 MB/s (most mSATA motherboard connections are SATA 2), my secondary SSD has read/write speeds of 507/250 MB/s and my 2.5" HDD is around 90MB read and write.

I have paging files spread across all 3 drives (the only 'fixed' size PF is on the System drive, which has the highest I/O anyway), when the SSD PFs become busy/full, Windows will use the HDD's PF. Until that point, ie. for my normal usage, I suggest my setup is better than Windows' default.

When the HDD PF does come into use, I can hear it, giving me an audible warning that 'something' is close to hitting the limits on at least one of the SSDs.

Currently on 8.5 days up time here and the Currently Allocated PF is still at the minimum level, 1.5GB (of 2.4), even though there have been a number of periods when the used memory has been over the 6.5GB (of 8) mark.

Hmm?? Sata2 can't transfer over 300MB/s? Where and how do you get 507 on 2nd drive, being a sata2? Sata3 can go to 600MB/s max.. I avg. r/w @ about 550MB/s


and if it was writing a swap file or in my case photoshop scratch files. As this LT page is off and has 32gb mem.




But have a cad station running this PCI express, all this indexing /swap is meaningless. Were talking about speeds were you blink, you missed the whole event....as transferring:roll eyes (sarcasti

 

[tension]

oops that is a msata is a III 600MB/s... why so slow 250MB/s read side?