64-bit page file size?, in the x64 Terminal Server / Citrix forum on BrianMadden.com

I don't know about anyone else but this article doesn't really spell it out for me: MS KB Article 889654 "How to determine the appropriate page file size for 64-bit versions of Windows Server 2003 Windows XP." It does go so far as to say that "When lots of memory is added to a computer, a paging file may not be required." I wonder what "lots" is. I have some 16GB machines. At first we set the page file to 32 GB and found that 10GB was being reported used (task manager) while 10GB of physical was reported free. We tired cutting it down to 16GB and not surprisily had saw the exact same results. My next thought was to cut it down to 4GB to try to "force" physical RAM use but I just read a post here where someone was having issues with that reporting "Windows - Virtual Memory Minimum Too Low : Your system is low on virtual memory." URG! Are we really going to be running 512GB page files when we get to servers with 256 GB of RAM?

Robert, have you done any more on this? I too have the same questions, as I want to keep as little page swapping to disk.

Scott

Anyone have comments on this? I have a CPS 4.0, 8GB RAM, 8GB Page, and everything is fine. When I installed the exact same box but with CPS 4.5, I feel Robert's pain. To boot, I get all this excessing paging activity and % Disk Write even with no one on the server.

Is it Citrix? Is it Microsoft?

Anyone have a final answer on this? Is the bottom line to just not have a pagefile in x64 windows unless you need one for dump files (which by the way are very rare in my case)?

Thx,
Sy

I thought I would throw my two cents in this since my group has been required to do a LOT of research to determine alerting thresholds for paging activity and capacity planning. Just so everyone knows, I am open to being corrected on items I have posted. if there is a better way of doing this or you think I am just wrong, Let me know.


To start with, we needed to understand what is going on. There are two types of paging activity:

- Page in (read from PF to RAM)
- Page out (write to PF from RAM)

the Perfmon Pages/sec is a total of the two (bad measurement IMO to see if there is an issue. Page input/sec, Page reads/sec and Page output /sec, Page writes/ses are better).

Basically, the rule is this, If you have a consistently high 'Page in' metric coupled with a High 'Page out', you need more ram. if you have high 'Page out' metric, you have a lot more Ram than you need (not a bad thing necessarily).

If you have a page file, you will always get some level of activity to it whether you need it or not. Somewhere in the internal workings of Windows there is a time limit that tells the OS, this is stale data, put it on the page file so I can use the ram for something else. I don't know if this can be adjusted or if you would want to but it would be cool to find out.

good page file use = stale data
bad page file use = extra ram

Now the question is, is my paging activity excessive? and is it causing problems? this is where you have to determine a few things,

the big one, is it reads or writes?

- if it is high reads, check your writes if they are always high... yes you have a problem, get more ram.
- if it is writes and it comes in spikes, IMHO I would not consider page writes excessive, as long as your hardware (disk i/o, HD speed) can handle the activity. Reducing the size of the page file does not necessarily change the amount of page write activity. (unless of course you don't have one)

can my hardware handle the write activity? (this is where it gets a little difficult)

- Disk I/O's is a total of read/write activity.

I do not remember where I got this formula from but it is not mine. But we use this to determine if our disk subsystem is having an issue. it factors in a write penalty and is used for estimations.

I/O's per sec. per drive w/RAID1 = (Disk Reads/sec + 2*Disk Writes /sec)/(drives in volume)
I/O's per sec. per drive w/RAID5 = (Disk Reads/sec + 4*Disk Writes /sec /(drives in volume)

we use the highest points in the metric gathering (not average) for Disk reads (page in/sec) and Disk writes (page out/sec)

we then compare these numbers against our hardware's listed capabilities:

15K SAS drive is capable of about 400-500 Liner I/O's /sec - maybe 250 Random I/O's /sec
(numbers we use, not necessarily what your hardware is capable of)

Most controller cards are listed in Total throughput (GB/sec, MB/sec) and not in I/O's just keep that in mind.


With all of that being said, we have our page files on a separate controller with a Raid1 set of SAS drives. (All that is on this drive) this allows our Servers to handle large spikes of Writes (3000-5000 pages/sec) quite comfortably. but for the most part our writes are far apart and so are our reads.

hope this helps.

I too would "test" using no pagefile when RAM is abundant.

Hello All,


The metric you need to observe in this scenario is your Commit Limit. This tells you what amount of maximum memory would be committed to disk *IF* it had to at one time. This will never happen(actually it can’t) so you can base your page file size off that number.

So for example, start with your page file the same as the amount of ram in your system, i.e. 4 gigs. Monitor your commit limit in task manager for a few days during "full load". If your commit limit only reaches 3 gigs, you could trim that page file down some. This helps with the excessive pages.


Hope this helps,

--Mike

PS, Paging isn’t a bad thing, don’t look at Pages/sec counters. They are irrelevant. Windows technically 'pages' every time you read a file. Hard faults are expensive; monitor those and your commit limit. If you want more info, start inspecting the different lists in the memory manager.

I agree with above post by Mike Smith. Also bear in mind if you choose not to use a page file you will not get any dmp files mini or otherwise. The minimum page file you can set is 16mb however you will still get out of virtual memory warnings.

If you're using 32Gb of physical memory you're better off setting no page file, if windows sees a page file it will use it regardless if there is excess ram.

can anyone explain why i still get page outputs/sec showing up on the perfmon counters with the pagefile disabled on the server?

i have 32gigs of ram on the server, no pagefile. i dont understand why or how windows is outputting data from the disk to memory... on the other hand page inputs/sec is totally flatlined.

Hello,

From the Explination of the counter:

Pages Output/sec is the rate at which pages are written to disk to free up space in physical memory. Pages are written back to disk only if they are changed in physical memory, so they are likely to hold data, not code. A high rate of pages output might indicate a memory shortage. Windows writes more pages back to disk to free up space when physical memory is in short supply. This counter shows the number of pages, and can be compared to other counts of pages, without conversion.


In your scenario, I wouldn't worry about that counter because The Memory manager is using existing physical memory to emulate(not quite the right word) a paging file. So what its doing is moving pages from one list to another inside of physical memory. The window memory manager decides when something in the Standby list gets paged out to disk or not, and in your case, you dont have a pagefile on a disk to page out to, so it moves it off to the standby list.

To verify this, open up Process Monitor and turn on advanced information and remove the page file filter. You'd see the reads/writes to the page file if you had one. In your case you shouldnt see any.

For more info refer to the Microsoft Windows Internals 4th Edition. Lots of good info in there. Or if you can get your hands on them, the videos from Sysinternals describing memory management are really interesting.

But to sum it up, I think you shouldn't be concerned with that counter.

--Mike

Hi Mike,

thanks for the detailed explanation. Only problem is i made a typo when writing my post, the actual counter that is being used is the pages input/sec, while output/sec is flatlined. So, having said that, does your statement also hold true for input where data may be written from one part of the list to another?

Regards,

Sam

Hello Sam,

This is again from Perfmon:

Pages Input/sec is the rate at which pages are read from disk to resolve hard page faults. Hard page faults occur when a process refers to a page in virtual memory that is not in its working set or elsewhere in physical memory, and must be retrieved from disk. When a page is faulted, the system tries to read multiple contiguous pages into memory to maximize the benefit of the read operation. Compare the value of Memory\\Pages Input/sec to the value of Memory\\Page Reads/sec to determine the average number of pages read into memory during each read operation.

I'm not entirely sure this description is 100% accurate because windows "Pages" just to open a file. It pages the file into memory. To verify this on your own PC, open perfmon, add the Pages In/Sec counter. It should be somewhat flat while idle, then open Word or some other application. You'll see it spike up because it has to page winword.exe into memory. Essentially they're just "reads".

Check out page 443 of the Windows Internals 4th Edition book for more info.

Hope this helps!

--Mike