1. You are viewing our forum as a guest. For full access please Register. WindowsBBS.com is completely free, paid for by advertisers and donations.

Services and pagefile tweaking worthwhile?

Discussion in 'Windows XP' started by Christer, 2005/12/29.

  1. 2006/01/10
    Christer

    Christer Geek Member Staff Thread Starter

    Joined:
    2002/12/17
    Messages:
    6,585
    Likes Received:
    74
    Whitphil,

    my computer started its life with WinME on its shoulders and 256 MB RAM to carry it. When I migrated to WinXP, initially, I changed no hardware and the pagefile was by the installer set to 384-768 MB.

    When I was working in Microsoft Powerpoint and Microsoft Photo Editor at the same time, I had "out of memory" messages. The pagefile had been increased to its maximum and the computer could do nothing but squeal and freeze. I don't know how "taxing" those programs are on RAM but if Adobe Photoshop had been used instead of Microsoft Photo Editor, my guess is that the ceiling would have been hit much sooner.

    I purchased another stick of 256 MB RAM and adjusted the pagefile to 768-1536 MB. (That setting would have been set by the installer if 512 MB RAM had been fitted at the time of installation.) This means that the new "floor" is higher than the previous "ceiling ". Since then, the pagefile has never been resized by the system but it sure has been used.

    My conclusion is that if a user is only surfing the web and sending E-mails, it doesn't matter but if anything "heavier" is loaded, think about it.

    Christer
     
    Last edited: 2006/01/10
  2. 2006/01/10
    TonyT

    TonyT SuperGeek Staff

    Joined:
    2002/01/18
    Messages:
    9,072
    Likes Received:
    400
    Actually, the page file is used frequently on XP systems, no matter how much ram the system has. XP uses the page file for every bit that gets loaded into ram.

    and, MS recommends adjusting the page file for performance:
    http://support.microsoft.com/?kbid=314482
     
    Last edited: 2006/01/10

  3. to hide this advert.

  4. 2006/01/10
    WhitPhil

    WhitPhil Inactive

    Joined:
    2002/01/07
    Messages:
    599
    Likes Received:
    4
    Tony: Can you explain what you mean by that statement, or point me to a reference?

    In order to get a performance boost by moving the pagefile to another drive, so that "Windows can handle multiple I/O requests more quickly ", Windows HAS to be doing ANY type of I/O to that file in the first place. On a Ram laden system, I/O to the pagefile will be absolutely minimal on a continuing basis.

    Christer Powerpoint and Photo Editor are fairly large intensive apps. And I can see that if you were dealing with relatively large files to begin with, that you would start to page. In a Windows managed environment, you should not get Out of Memory errors. That's what VM is meant to cater to. But, if you place an upper limit on the pagefile, at some point the "memory" required to run the system and all apps will exceed ram+VM, and windows has no choice but to "complain ".
    So, I think you essentially resolved that issue by adding ram, and as you said has not been resized, because it is seldom used. Thus, if left as Windows managed, the same would/could have happened.
     
  5. 2006/01/10
    Christer

    Christer Geek Member Staff Thread Starter

    Joined:
    2002/12/17
    Messages:
    6,585
    Likes Received:
    74
    Whitphil,

    On WinME, it is possible to set a minimum size and leave the maximum "undefined" (the size is greyed out and equal to free disk space).

    On WinXP, leaving the maximum "undefined" is not possible which means that a sensible value has to be entered. (I don't know what would happen if free space gets smaller than the set maximum size of the pagefile.)

    My experience as related in the previous post, indicates that it may be simple for the installer to always set the pagefile to 1.5xRAM - 3.0xRAM but for low RAM computers, the pagefile needs to be larger than that. At the other end of the spectrum, a high RAM computer will get a ridicolous pagefile.

    I have monitored the pagefile and it still gets used when working with those applications but pagefile usage has not exceeded the minimum size and in consequence, has not been resized. It probably would have, if it was Windows managed.

    As I mentioned in a previous post, the WinXP installer does set a "semi fixed" pagefile (1.5xRAM - 3.0xRAM). I have not changed it from a Windows managed pagefile so, I couldn't "have left it" as Windows managed.

    Earlier (with 256 MB RAM) when the pagefile was resized, there was a noticable slow down each time it was incrementally increased in size. Setting sensible minimum and maximum sizes is not worse than a Windows managed because between the min and max, it will be Windows managed but less prone to fragmentation. The tricky part is to find out what is "sensible" and that varies with installed RAM and usage pattern.

    Christer
     
  6. 2006/01/10
    TonyT

    TonyT SuperGeek Staff

    Joined:
    2002/01/18
    Messages:
    9,072
    Likes Received:
    400
  7. 2006/01/10
    WhitPhil

    WhitPhil Inactive

    Joined:
    2002/01/07
    Messages:
    599
    Likes Received:
    4
    Tony:

    Thanks, I've seen that article. (I think both are the same link)

    But, it is not saying that "XP uses the page file for every bit that gets loaded into ram ",
    It states that everything that runs must be paged in, BUT "For the most part, this paging does not take place in the page file ".

    And even saying that, the word "paged in" is used loosely, since paging is used generally when talking about the pagefile.

    Or, is there something else in this article that I am missing that lead you to make that statement?
     
  8. 2006/01/11
    TonyT

    TonyT SuperGeek Staff

    Joined:
    2002/01/18
    Messages:
    9,072
    Likes Received:
    400
    Well, there's essentialy 2 types of paging, paging using the virtual memory (page file) and paging uisng the exe or dll directly.

    Windows xp is "smart" in that it will not utilize the page file if it doesn't have to, and will instead page directly to the exe or dll. However, the software must be coded in such a way as to allow direct paging to the exe or dll.

    The vast majority of apps available today are coded by lazy programmers, who take shortcuts, add extraneous code to fix recent code that breaks earlier coding, justify it by thinging "more ram makes these extra events unnoticable to the end user ", and more. MS is as guily of this type of programming as any. But for the most part, MS apps comply with operating systems standards laid out by MS.

    Now, the key points are:
    "modified information cannot have backing store to the original file or .exe's SINCE it's modified ".

    if page file too small
    Affect? Stacks, heaps, program global storage, etc will all have to stay in physical memory, NO MATTER HOW LONG AGO ANY OF IT WAS REFERENCED!!! This is very important for any given workload and ANY amount of RAM, since the OS would like to mark memory available when it's not been called for a long time. You have impeded this strategy if you have a page file lower then the amount of ram in use.

    ...but the above Affect also can be caused by:
    1. running unnecessary & unused services.
    2. poorly written program code.

    Hows this relate to Services:
    In #1, you will see this Affect if you attempt to stop a service that has unmet dependancies, such as when you try to stop the Remote Auto Connection Mgr Service when/if Web Client Service is started. Windows will often hang and be unable to stop the services. Terminal Services is another, in fact, on a new clean install of XP w/ sp2, there is no option to stop the Terminal Services service, all you can do is change to manual or disabled and change won't takle place until a reboot. This demonstrates that xp cannot unload Terminal Services from memory initially, and is likely a "bug fix" that was implemented in SP2.

    In #2 you see this when you use an app, close it, and it still shows up in the Task Manager Process list. An example is Adobe Reader, which will sometimes fail to unload completely and have the memory it was using be reallocated by windows. Many other apps do this too.

    Now, while it is correct that having LOTS of ram offsets these issues, the average comp for sale today comes w/ 256 MB ram, which is not nearly enough, esp since these comps come bundled with all kinds of useless unnecessary bloatware. (an optimized tweaked win98 is usually faster than an out of the box modern oem xp system!)

    Thus, tweaking services and the page file can and do affect performance. It ALL depends upon the users' preferences, how the users use their comps, and what software the users use, as well as what hardware the comp has, including the type and amount of ram.
     
    Last edited: 2006/01/11
  9. 2006/01/11
    WhitPhil

    WhitPhil Inactive

    Joined:
    2002/01/07
    Messages:
    599
    Likes Received:
    4
    Tony: May I presume you make this statement as as result of what was said in the article you linked to?
    "One form of this memory reclamation (or paging, so to be clear), the kernel can mark to release or unload data without a hard write. The OS will retrieve said information directly from the .exe or the .dll that the information came from if it's referenced again. This is accomplished by simply "unloading" portions of the .dll or .exe, and reloading that portion when needed again. "

    If so, this is not paging directly to the exe, but rather Windows realizing that the area of ram being reclaimed contains code, and thus does not need to be paged out (since it can't change), but just brought back in (from the EXE file).

    IMHO it would be crazy for Windows to be paging to an exe or dll file. This would mean that the file itself would need to be large enough to contain ALL of the paging activity that it ever generated. That is, if the exe were a 1K mickey mouse app that declared 5 arrays of 10MBs each, the size of the file would need to be at least 10MBs in size, in case all 5 areas needed to be completely paged out.
    The other option would be to just dynamically write to the code file at run time. But now we have files being continually read and written to, as they are being executed. This would have the potential of massive file corruption in the event of a system hang, power outage or forced shutdown.
    I also don't see anything in memory architecture documents that describes how this would happen.

    Well yes. That's sort of a truism. But, (again IMHO) for the vast majority of users, little performance will be gained by playing with the pagefile settings. More will be gained by getting rid of all the excessive **** that loads from the various startup areas, first.
     
  10. 2006/01/11
    TonyT

    TonyT SuperGeek Staff

    Joined:
    2002/01/18
    Messages:
    9,072
    Likes Received:
    400
    yes, had I said "paging from" exe or dll it would be more correct.
     
  11. 2006/01/13
    Christer

    Christer Geek Member Staff Thread Starter

    Joined:
    2002/12/17
    Messages:
    6,585
    Likes Received:
    74
    This evening I had nothing better to do than a few empirical tests of the workings of the RAM and pagefile. As usual, it added to the confusion.

    I restarted the computer and let it idle for five minutes before starting Task Manager and Norton System Doctor to monitor the values:

    Physical Memory used = 187 MB
    PageFile usage = 11 MB
    PM + PF = 198 MB
    Commit Memory = 154 MB
    PM + PF - CM = 44 MB

    Next, I started 20-25 applications (Office programs, Adobe programs and other heavier and lighter applications) in rapid succession:

    Physical Memory used = 295 MB
    PageFile usage = 130 MB
    PM + PF = 425 MB
    Commit Memory = 445 MB
    PM + PF - CM = -20 MB

    After five minutes idling, things had gradually been paged out from RAM to the pagefile:

    Physical Memory used = 255 MB
    PageFile usage = 170 MB
    PM + PF = 425 MB
    Commit Memory = 445 MB
    PM + PF - CM = -20 MB

    Next, I loaded a few documents and pictures in rapid succession:

    Physical Memory used = 320 MB
    PageFile usage = 203 MB
    PM + PF = 523 MB
    Commit Memory = 518 MB
    PM + PF - CM = 5 MB

    After five minutes idling, things had gradually been paged out from RAM to the pagefile:

    Physical Memory used = 254 MB
    PageFile usage = 269 MB
    PM + PF = 523 MB
    Commit Memory = 518 MB
    PM + PF - CM = 5 MB

    Finally, I killed everything except Task Manager and Norton System Doctor. After five minutes idling the values were:

    Physical Memory used = 209 MB
    PageFile usage = 16 MB
    PM + PF = 225 MB
    Commit Memory = 178 MB
    PM + PF - CM = 47 MB

    It is obvious that the pagefile gets used and with my 512 MB RAM, XP seems to keep half of it free. That conclusion is probably incorrect but it debunks the statement that XP uses as much RAM as it can find a use for.

    I was under the impression that PM + PF = CM (approximately) but the variations when applications were started and documents and pictures were loaded surprized me. It is obviously not that simple.

    No matter what, I have convinced myself that my system needs the pagefile and I was convinced long before this that it doesn't need Windows to manage it!

    Christer
     
  12. 2006/01/13
    WhitPhil

    WhitPhil Inactive

    Joined:
    2002/01/07
    Messages:
    599
    Likes Received:
    4
    Just because the page file shows as being "used ", does not mean that any ram has actually been paged out.

    On Windows 98 everyone saw this "phenomemom" where the swapfile was being used and there was still ram available, so they ran and set ConservativeSwapFileUsage so that Windows "use all the ram first ".

    The fallacy was that this was already happening, and windows was just "preparing" for the event that it "might" have to page areas out.

    What you are seeing is similar.

    There is no reason NOT to run with a pagefile.

    And, there is no reason not to run with a windows managed one. The ONLY difference is that with a non windows managed one you set the lower and upper limits on the file. All the rest of the paging algorithm is the same. And, yes there is the growing and shrinking of the file, but this was an issue in Win95 days. It really is nothing to have to be concerned about now.
     
  13. 2006/01/14
    Christer

    Christer Geek Member Staff Thread Starter

    Joined:
    2002/12/17
    Messages:
    6,585
    Likes Received:
    74
    I tried to run my car based on a similar (dis)belief ...... :rolleyes: ...... and I ended up walking!

    Christer
     
  14. 2006/01/15
    Christer

    Christer Geek Member Staff Thread Starter

    Joined:
    2002/12/17
    Messages:
    6,585
    Likes Received:
    74
    Another late evening with nothing better to do ...... :rolleyes: ...... and I played a bit with the XP performance monitor:

    The green graph is "Available RAM" (NSD - PM free).

    The yellow graph is "Memory, Pages Output/Sec" (showing that pages move from RAM to PF).

    The blue graph is "% of PageFile used" (NSD - PFU usage).

    The Norton System Doctor show values in MB for the different readings.

    The attached screen shots:

    1-Idling.jpg shows the uneventful start of the "test ".

    2-Opened Apps.jpg shows the values after opening ~25 applications.

    3-OA+2min.jpg shows (under hard disk activity) that paging is going on.

    4-OA+5min.jpg shows that paging has finished. (The paging and decrease in Available RAM that occurrs after it first finished is due to me taking screen shots.)

    5-Closed Apps.jpg shows the values after closing the applications.

    WhitPhil,
    if the above is not evidence for RAM being freed and the pagefile being utilized then you'll have to do a better job convincing me that it's not happening than just stating that it doesn't.

    Christer
     
    Last edited: 2006/01/15

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.