[johnhc]

I found this post by prathapml (great thread - a little dated). It describes, among other things, how to set the paging file size during install. I had to do a couple of things to get it to work on my XP x64 system. The thread shows using pagefileconfig.vbs from the System32 folder. I did not have one on my running system (nLite install), but I had a pagefile.vbs (also not on the running system) in my original CD files. I placed this in my $OEM$\$$\System32 folder and called the pagefile.vbs routine from my command file invoked via the Unattended RunOnce exit. It worked fine except the paging file ended up fragmented. I don't remember what the original size definition by Setup was, but it was smaller than mine. I specified 1.5x my memory size for both the initial and maximum (6144 MB). I have done a lot of searching without luck for a method to set the paging file size before/in lieu of Setup, so I don't end up with a fragmented paging file. I have found several methods to defrag the paging file via Google, but I would rather not have to do this. I am hoping that someone can suggest a scheme to accomplish this. Thanks for any comments. Enjoy, John.

[prathapml]

Hmmm, what I'm gonna mention is a circuitous route, but I'm just looking at this as throwing an idea into the open from where you could take it forward if it's workable.

1. Use the VBS the first time around to disable pagefile entirely, and reboot in 2 mins (you are using autologon, I guess).
2. Autologon a second time and run a defrag command, and set the next task to reboot.
3. Autologon a 3rd time and enable pagefile as per your preferences, then reboot automatically.


One other possibility, is to see if one of the defragging apps (DisKeeper, Raxco, O&O, Defraggler, Vopt, whatever) offers a command-line switch to auto-defrag C: drive and consolidate the pagefile at the same time. If you've nLite'd so much that the pagefile.vbs is removed, chances are you might as well have a defragmentation run to speedup your OS and maximize performance. On the other hand, if your C: drive is located on an SSD, then pagefile fragmentation isn't an issue (heck, pagefile is not even required with your 4GB RAM and an SSD!).

This post has been edited by prathapml: 11 January 2010 - 03:31 AM

[johnhc]

prathapml, thanks much for your reply. I was hoping there was a way to run your tweak one time very early and be done. I guess not. I have seen several discussions (via Google) that did manually the way you describe. I had not thought of implementing that using my install method (including WPI). Right now I am running DisKeeper 30-day trial (my son swears by it and talked me into trying - I am not convinced). DisKeep has a Pagefile defrager (boot time) that I could use (I think it has command line interface) and need only one reboot (which I already do with WPI). I am not running an SSD (but do have 4GB memory), but I guess we are all headed that way. I have a pretty snappy system with a RAID5 using four WD VelociRaptors but am always looking for a faster system. I have used nuhi's Safe Removal Preset and am really fairly conservative with nLite. I too was surprised that the VBS files were missing. Recently I ran a test using nLite to see some networking settings and did nothing but the Unattended Task. The only VBS files are in some .cab files and the pagefile.vbs I added to the $OEM$ folder. For some reason nLite is not bringing VBS files into the ISO. I attach my Last Session.ini from my test run. All the things I normally do with my preset are there, but I only run the Unattended. Thanks again, John.

[jaclaz]

johnhc, on Jan 5 2010, 09:16 PM, said:

I specified 1.5x my memory size for both the initial and maximum (6144 MB).

A rather largish choice, if I may go slightly OT, the 1.5 Myth is still a die-hard one.

JFYI:
http://tadej-ivan.50....com/myths.html

jaclaz

[submix8c]

PageDefrag (includes link to ContigDefrag) Sysinternals/MS.

HTH

edit - may not as you want it to happen during Install...
edit2 re jaclaz above... very true! Pagefile is just that - a PAGE file (Mainframe, anyone?)!

This post has been edited by submix8c: 11 January 2010 - 02:52 PM

[johnhc]

jaclaz and submix8c, thanks for your reply. I will check out the 1.5x myth. I did find PageDeFrag from SI, but it is 32 bit only and I am running 64 bit. Thanks, John.

[cluberti]

The page file at 1.5x was also a relic from a time that 32 - 64MB of actual RAM on a workstation was a lot. In Win7, Microsoft changed the algorithm from 1.5x to 1.0x RAM, and that's mostly because you need that much paging space for storing a .dmp file if a complete dump happens. You can actually get away with very little if you've got a lot of RAM and don't mind the fact you can't store a paging file on crash - I personally run machines with 256MB of paging file, and I could go lower but knowing a bit about how the paging executive works I'm sticking at 256MB for now to be safe, "just in case".

[johnhc]

Thanks for the all the comments. I have decided that my PageFile is too large. When I do my next install I will use the VBS to set the it to 2048 MB (0.5x) for both the Initial and Maximum. I am not convinced that leaving the PageFile fragmented is a good idea, but this specification should prevent it from being fragmented. I have run some tests on my machine while watching the Task Manager. While running Prime95 (Torture Test), I see my PageFile size varying around 1300 MB, so I selected 2048 MB. Thanks again, John.

[jaclaz]

Hmm.

I am not convinced it's "small enough", but anyway sounds much better.

Let's see what happened in the years.

XP (32 bit) was "advertised" as having the need for a bare minimum of 64 Kb of memory, and usable with 128 Kb:
http://www.microsoft...ysreqs/pro.mspx

Using the usual 4x multiplying factor that is needed with MS requirements statements , you had in practice:
64x4=256 Kb "real" bare minimum to boot
128x4=512 Kb "real" minimum to have a usable system

In real world a working machine you would have a further 2x factor as in:
128x4x2=1.024=1Gb


Now using the mythical 1.5x factor you have respectively:
256x1.5=384 pagefile +256 RAM=640 Mb TOTAL
512x1.5=768 pagefile +512 RAM=1280 Mb TOTAL
1.024x1.5=1.536 pagefile +1.024 RAM=2.560 Mb TOTAL

Now, you have x64 that can address a larger amount of RAM than x32, but I do not think that x64 needs that much amount of memory, I mean something like 4 time the actual RAM and (4.096+2048)=6,144/2.560=2.4 times the TOTAL.

Questions:

• What happens if you try running your "Torture Test" on your machine after removing RAM as to remain with "only" 2 Gb of it?
  
• What becomes the usage of the pagefile?

Hints (not necessarily directly related to questions above):

• an OS tries to use as much resources as you have available
  
• "torture tests" (and in a minor way benchmarks) are - besides inhuman - largishly pointless, the only thing is to see how your paricular system bewhaves with the particular settings you chose with the particualr use you make for it.

jaclaz

[MrJinje]

prathapml, on Jan 11 2010, 03:30 AM, said:

(heck, pagefile is not even required with your 4GB RAM and an SSD!).

I like this answer, even without an SSD. I have an old box with 4GB of DDR (not DDR-2 or DDR-3 but DDR-Original - 400mhz I think) and a 40GB IDE-HDD. Anyways, long story short, 5-6 years no pagefile and no issues. But then again I always thought it was a stupid idea for Microsoft to write data to my HDD while the machine is at it's busiest.

What you could do is install your windows and start up every Microsoft Office program, open all your other programs, maybe pop in DVD, then check and see what kind of RAM usage you are getting. If you are still under 4GB at extreme usage, you can probably survive without a pagefile.

For any readers who want to test this out, here is the reg setting that disables your page-file.

Disable_Pagefile.reg

Windows Registry Editor Version 5.00
;-----------------------------------
;Disables The Paging File
;-----------------------------------
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"PagingFiles"=hex(7):00,00,00,00

[johnhc]

As with many things in the world and especially OSs, most are compromises. You can choose to run without a PageFile and get away with it. I have decided to run with a 2 GB one. Do I need this much? Well, only when I need this much. I just brought up VMware Server and it used over 700 MB of memory and the PageFile usage jumped up to 2 GB. Maybe a 2GB PageFile is too small for me. What if I ran several VMs at once? What normally happens when Windows runs out of real memory? It pages some (hopefully least used SW) out. If there is no PageFile, something bad happens. I would rather have a reasonably sized PageFile and not crash just as I am about to discover something fun. I normally run Prime95 to test changes to my system. The torture test says it is heavy on memory and once in the past on another machine I received a message that I was short of memory, so I tried it to see if my memory usage would be challenging. I appreciate all the comments but I think we can get into a contest (of the P kind) about this subject. Later, John.

[cluberti]

You have to remember the memory manager bias though - the more paging file you give an XP system, the *more it will be used*. The OS will try it's darndest to make sure that running applications are in RAM, and minimized applications or background tasks can (and will) be paged to make sure there's enough "free ram" on a just-in-case basis (it's more complicated than that, but for this discussion the layman's description here should be fine). This can be easily tested by setting a very small paging file and running a workload that is smaller in memory footprint than the installed amount of RAM - then, increase the paging file and run the same workload again. You will notice that on the first run, the system (minus what can be needed in a pinch for kernel paged pool memory) will keep everything in RAM and run just fine, but if given the paging space it will use it (heavily, at times) even if there's no risk of "running out of RAM". The bias is better on Vista and much better on Win7 machines, partially because XP was built on a kernel that was designed and tweaked during the NT era and thus behaves in an archaic manner, and partially because XP does little caching to try and improve performance, whereas Vista and especially Win7 try to take an active role in making sure that what needs to be in memory is, and what doesn't won't be - unless there's RAM to spare, in which case it'll leave things alone and simply keep pages on the ready list rather than actually swapping them out.

[jaclaz]

johnhc, on Jan 13 2010, 11:23 PM, said:

As with many things in the world and especially OSs, most are compromises.

Exactly.

But there can be "good" and "bad" compromises.

The whole point is that to reach a compromise, you have to carry on a negotiation with the other part.

Negotiating will take time, in order to reach a compromise good enough to have both parties reasonably happy.

As said, 1.5x is totally unjustified and a rule of thumbs that could only be used on completely different ranges of available RAM.

Your current 0.5x is only a hopefully better approximation.

If you can substantiate your decision and correlate the max value registered during a "torture test" 1,300 with the final value you used, 2,048, it would be a step ahead, after all 2,048/1,300=157%

Like when you choose a power supply, you calculate that your actual power need is in the 250÷300 W range and then, knowing that a power supply works better at 1/2 to 2/3 of it's "tag power" you go for a 450÷600 W one.

But pagefiles do not work like that.

Let's take another example, you have to buy a car for your wife.

From historical data you know:

• that you are a family of three
  
• that the car will never be used on a highway or for longish trips
  
• that it's main use will be commuting home/work, go to the supermarket and take your child to school

Now which car do you buy?:

• a sub-compact 4 seater (simply because three seaters are not available)
  
• a big 4x4, 7 seater

Answers:
If you live in the US #2, if you live in Europe (and/or are cheap, like me ) #1.

In other words, let's say that you fancy having a 2,048 Mb pagefile and it's allright, but do not try "selling" us that it comes from a strictly technical reason, as we won't buy it.



jaclaz

This post has been edited by jaclaz: 18 January 2010 - 07:26 AM

[prathapml]

At the risk of drawing wrath, may I suggest we all back off from the "how much pagefile is appropriate" discussion.
Different strokes for different folks, and "johnhc" here might have his reasons for what he wants, and all of you that have commented definitely have strong technical reasons and experience to back their recommendation.
I might personally disable pagefile altogether, but everyone need not HAVE to share that view.

But at the end of the day, the question is (*or was, and has probably been abandoned) "how to set my pagefile AND not have it fragmented on disk".
Let us get back on topic, and let the thread die a natural death if there are no further solutions that we can thrash out.

[johnhc]

prathapml, thanks much for your reply. I could not agree more! Have fun, John.

[johnhc]

Just a note concerning why the VBS file was missing in my nLited output. I specified "Administrator VB scripts" in my Component Removal task. I guess it is part on the Safe removal Preset. Enjoy, John.

[prathapml]

Ah, that clarifies it then. I did seem to remember that the VB scripts are not removed unless specified.
(the vague memory is because I moved away from WinXP many years ago)

[johnhc]

Quote

The thread shows using pagefileconfig.vbs from the System32 folder. I did not have one on my running system (nLite install), but I had a pagefile.vbs (also not on the running system) in my original CD files.

It turns out that the file is renamed during install. It appears that TXTSETUP.SIF and LAYOUT.INF both rename the file, thus:

pagefile.vbs = 1,,,,,,,2,0,0,pagefileconfig.vbs
pagefile.vbs = 1,,222222,,,,,2,0,0,pagefileconfig.vbs

Enjoy, John.