Discussion: Size your windows XP page file.

[Phoenix86]

Please post discussions from the "How to: Size your windows XP page file." sticky here.

This thread was created to keep the sticky as clean as possible, yet provide a place to discuss/debate the information found inside. Thank you.

 

[KoolDrew]

I will try to keep this discussion flame free and try to contribute to the thread

The first thing is this

less recently used data from RAM will page to disk (pagefile.sys)

As you know the pagefile is not the only file involved with paging. You may want to add things about that. The same with this

Paging to disk is when data is being transferred between RAM and the PF

This is a topic only covering the basics of paging, but you should at least say the pagefiule is not the only file involved with paging.

As for the actual sizing of the pagefile I like to do it using perfmon. Run intensive applications and stuff and then see how much PF is actually in use. Then multiply this number by 4 and set that as the initial. The max should be 2x that number.

If you require a PF, you should set the minimum and maximum size to the same value. If you set a range, the PF can grow, but this will cause file fragments in the PF. The built in defragmenter cannot correct fragments in the PF, only 3rd party software can. The more fragments in your PF, the slower it will operate.

We discussed this in the last argument we had. I don't reccomend setting it as a "fixed" value. If you do come under a heavy load you want the pagefile to grow. Also with my reccomendation above the initial would be high enough where the pagefile would most likely never need to grow, but still giving it head room. If however the pagefile does grow when rebooted it will go back to its initial size.

Also, if you sized it properly, your PF will never need to grow.

Exactly. My reccomendation has a high enough initial where it most likely will not needf to grow thus not creating fragments and still having available head room.

Also I have explained a couple times on here about disabling the pagefile. In the long run it is hurting your performance. There may be some gain in short term events such as game load times though.

If new data is loaded, the system with a PF would be paging memory to disk, one without will not

This is completely incorrect. Again the pagefile is NOT the only file involved with paging.

This means paging will still happen, it just won't be transferred to the HDD.

Yes it will...

Also as another note. Placement of the pagefile when you have quite a bit of RAM is just a waste of time the majority of the time. Also the pagefile is not the only file involved with paging.

In the ened though for the majority of users there is no reason to mess qaround with the pagefile. It is best left system managed.

 

[Phoenix86]

As you know the pagefile is not the only file involved with paging. You may want to add things about that.

I understand that executable images are not paged, and stored as memory mapped files. I do need to do some reading on this subject...

However, that doesn't change the limits of what you can store as commit charge.

I *really* want to explain this a bit, but I also don't like posting stuff I can't back with some technical white papers or something we can all reference. To that end, gimme some linkage.

Paging to disk is when data is being transferred between RAM and the PF

This is a topic only covering the basics of paging, but you should at least say the pagefiule is not the only file involved with paging.

As far as paging to disk, that is only when data is transferred to the PF. I don't see how paging to disk would involve ,emory mapped files. Are you also saying paging to disk involves the memory mapped files? I see how these files are important in the VM process, but not as it relates to paging to disk.

As for the actual sizing of the pagefile I like to do it using perfmon. Run intensive applications and stuff and then see how much PF is actually in use. Then multiply this number by 4 and set that as the initial. The max should be 2x that number.

Use perfmon how? Explain in detail. Also, how can initial be less than max, I think you meant to swap those two...?

We discussed this in the last argument we had. I don't reccomend setting it as a "fixed" value. If you do come under a heavy load you want the pagefile to grow. Also with my reccomendation above the initial would be high enough where the pagefile would most likely never need to grow, but still giving it head room. If however the pagefile does grow when rebooted it will go back to its initial size.

Yeah, I have discussed a lot of crap in a lot of different threads.

I remember this one though, and here's the problem. When XP needs to grow the PF it fragments it (I posted pics to demonstrate this). The problem is, what if the memory requirements have simply just gone up? XP will never shrink it to it's original size. Then you have a fragmented PF. I'd agree that it should be set high enough to never need to grow, that's kinda the point to my method.

Also I have explained a couple times on here about disabling the pagefile. In the long run it is hurting your performance. There may be some gain in short term events such as game load times though.

That's a whole 'nuther topic as I'm not recommending it. I do provide some information for those that are interested as the calcualtions in setting your PFs size are relevant.

If new data is loaded, the system with a PF would be paging memory to disk, one without will not

This is completely incorrect. Again the pagefile is NOT the only file involved with paging.

What is the file name that data will page from RAM to disk? Again, I realize memory mapped files are used *in place* of paging, but that doesn't mean data is paged to those files. Actually from my reading all memory mapped files are read-only, meaning you obviously can't write data to those files.

You have made this claim more than once. Please link to a creditable source that verifies this information.

Placement of the pagefile when you have quite a bit of RAM is just a waste of time the majority of the time.
In the ened though for the majority of users there is no reason to mess qaround with the pagefile. It is best left system managed.

For systems with "lots of RAM" (relevant to usage) you are probably right. The PF is used so very little when you have more RAM than commit charge usage.

 

[KoolDrew]

I understand that executable images are not paged

Paging does not have to be to the pagefile. Anything being moved from RAM to the HDD and vice versa is considered paging.

To that end, gimme some linkage.

I could search around for links, but as of right now the only source I can give you is the book "Inside Windows 2000".

As far as paging to disk, that is only when data is transferred to the PF

That is incorect.

Are you also saying paging to disk involves the memory mapped files?

Yes memory mapped files are paged in and out as you read and write to them. Just about every read/write is paged in some way. When you run an executable the data is paged in from the executable as needed (with some readahead for performance), same thing with libs that the executable depends on.

Use perfmon how? Explain in detail

1. Start > run > "perfmon"
2. Click "+" button
3. Under Performance Object choose Paging File and click add, then close.
4. Click the "% usage" for PF and read the max. This is the max % of PF used during that session. To find out the percentage move the decimal and multiply. I think all of you know how to find a percentage. This is the peak Pf usage during that session.

An alternative way to doing all that would be to download THIS

Also, how can initial be less than max, I think you meant to swap those two...?

No, I meant 2x what you calculated from the thing before. For example my session peak is 37MB. This is without running intensive applications, but this is just an example. Now multiple this number by 4 (37x4=148). That is equal to 148 and that should be the initial size. Now take 148 and multiply this by 2 (148x2=296). 296 should be your max.

With my reccomendation (initial-148, max-296) the initial is high enough where it would not need to be expanded thus no fragmentation. It can expand if needed though. Of course if I did actually run intensive applications it would probably need to expand, but that is because this is just an example and I did not run intensive applications before checking my peak usage.

I remember this one though, and here's the problem. When XP needs to grow the PF it fragments it (I posted pics to demonstrate this). The problem is, what if the memory requirements have simply just gone up? XP will never shrink it to it's original size. Then you have a fragmented PF. I'd agree that it should be set high enough to never need to grow, that's kinda the point to my method.

It does shrink back to its original size on a reboot. Not if it is fixed though liekt eh pics you posted showed. If the initial is say 100MB and the max is 200MB. Under a heavy load it may increase to 150MB. On reboot it will be back at 100MB (the initial size) not fragmented. I do know a lot of people don't reboot often though, but with my reccomendation it would probably never need to grow.

There is nothing really wrong with your method if it is high enough, but you are removing that "safety net" if it needs to expand.

A System Managed size is even better in this situation.

That's a whole 'nuther topic as I'm not recommending it. I do provide some information for those that are interested as the calcualtions in setting your PFs size are relevant.

If you do not reccomend it why is it even in there?

What is the file name that data will page from RAM to disk? Again, I realize memory mapped files are used *in place* of paging, but that doesn't mean data is paged to those files. Actually from my reading all memory mapped files are read-only, meaning you obviously can't write data to those files.

There is no single file. As I explained above just about every read/write is paged in some way. Any executable is paged in when needed and vice versa. It is not *in place* of paging. It is paging.

You have made this claim more than once. Please link to a creditable source that verifies this information.

If I had links I would give you them, but th only thing I can reccomend is getting the book "Windows Internals." That is the newer one. I have the older one titles "Inside Windows 2000." Even "Understanding the Linux kernel" would have a lot of the same info.

 

[mikeblas]

It looks like Drew has responded to many of your questions; I don't have much time, so I'll try to fill out on some of the ones which he didn't respond to in depth.

As far as paging to disk, that is only when data is transferred to the PF.

This isn't correct. Paging invovles any memory mapped file, which includes any executable that you've decided to load and run.

I remember this one though, and here's the problem. When XP needs to grow the PF it fragments it (I posted pics to demonstrate this). The problem is, what if the memory requirements have simply just gone up? XP will never shrink it to it's original size. Then you have a fragmented PF. I'd agree that it should be set high enough to never need to grow, that's kinda the point to my method.

Then I wonder why you're writing an article about tuning PF size. Why not just make it big? It'll never fragment, then. And it'll always be big enough. Disk space is cheap; even a 2 gig page file is probably less than 1/40th of the size of your drive. Why spend time measure and tweak? What am I gaining by following your advice to change my page file size?

What is the file name that data will page from RAM to disk?

Search the posts I made to your other threads; I pointed out the registry key which contains the name of the files the system will use.

Again, I realize memory mapped files are used *in place* of paging, but that doesn't mean data is paged to those files. Actually from my reading all memory mapped files are read-only, meaning you obviously can't write data to those files.

Memory-mapped files are not read-only. Memory mapped files make use of paging; they don't replace paging.

 

[Phoenix86]

OK guys, if you want to help, you need to post links backing up what we say here. Taking pot shots by saying "that is incorrect" and moving on are wasted efforts and I'm not going to bother responding to those comments. I don't expect you to buy what I'm saying wholesale, don't expect me to buy what your selling w/o some evidence.

The point of having a discussion/debate thread, by it's very nature, is to demonstrate one way or another what you are saying. "This isn't correct" doesn't cut it, it isn't helpfull at all, and invites the "yes it is" response (IE pissing contest).

As far as things you would like to quote. One of the points of having this thread is so others can verify and cull the information. Not all of us have this book that's been mentioned, and if it's information is that good, it can't be the only place it exists. If you do want to quote it, do just that, quote it. Give us the full cite (book name, author, revision, page# etc.) so we do research in the (ugh) library.

That being said, the thread is now locked, so I can't edit anything in that thread. Fortunatly I did link to this thread in the second post, so this thread has visibility. I don't expect odoe to unlock the post if this turns into an unproductive conversation (IE pissing contest).

To that end. Please link/demonstrate/cite information you are presenting.

A perfect example is this quote.

This isn't correct. Paging invovles any memory mapped file, which includes any executable that you've decided to load and run.

This statement is useless to someone who doesn't understand memory mapped files. Now if you explained it in detail, or linked to an article discussing memory mapped files, we can move on from that point. However, now we have to "validate" what's being said here because you didn't. Well, I'm not doing all the leg work here guys. If you want to bring something to the table go ahead, but support it please.

OK... going through the meat of what's posted so far in my next post. I just want to keep things on track early.

 

[Phoenix86]

I could search around for links, but as of right now the only source I can give you is the book "Inside Windows 2000".

Quote and cite please.

That is incorect.

See above, comments like this don't further a discussion.

Are you also saying paging to disk involves the memory mapped files?

Yes memory mapped files are paged in and out as you read and write to them. Just about every read/write is paged in some way. When you run an executable the data is paged in from the executable as needed (with some readahead for performance), same thing with libs that the executable depends on.

Quote and link please (not that I disagree, so me and others can understand). Also, how is this relevant to PF sizing, or is it just VM related?

I don't mind discussing VM related things that don't affect the page file, but let's not muddy the water, at least say if this information is topical to page file. Personally I don't see memory mapped files as directly relevant, but I can clean up statements to recogonize what they do.

1. Start > run > "perfmon"
2. Click "+" button
3. Under Performance Object choose Paging File and click add, then close.
4. Click the "% usage" for PF and read the max. This is the max % of PF used during that session. To find out the percentage move the decimal and multiply. I think all of you know how to find a percentage. This is the peak Pf usage during that session.

An alternative way to doing all that would be to download THIS

This is another way to get similar information. I like.

It does shrink back to its original size on a reboot. Not if it is fixed though liekt eh pics you posted showed. If the initial is say 100MB and the max is 200MB. Under a heavy load it may increase to 150MB. On reboot it will be back at 100MB (the initial size) not fragmented. I do know a lot of people don't reboot often though, but with my reccomendation it would probably never need to grow.
...There is nothing really wrong with your method if it is high enough, but you are removing that "safety net" if it needs to expand.

OK, I'm not going to bother testing that it shrinks, I'll assume it does. However, if they acutally need a higher PF on a regular, then it will grow again, and be fragmented. It'll just do it every time the PC is rebooted. We both agree on setting high enough it doesn't though, and that's the main point. Like you said, you are just allowing a safety net. Heck if you have a defragmenter that touches the PF, your method is better. It's worth mentioning.

Quote=Phoenix86]
That's a whole 'nuther topic as I'm not recommending it. I do provide some information for those that are interested as the calcualtions in setting your PFs size are relevant.

If you do not reccomend it why is it even in there?[/quote] Because the information is relevant to those people who do what to. It's the same reason you're mentioning memory mapped files and other VM related functions that don't really affect the page file.

Quote=Phoenix86] You have made this claim more than once. Please link to a creditable source that verifies this information.

There is no single file. As I explained above just about every read/write is paged in some way. Any executable is paged in when needed and vice versa. It is not *in place* of paging. It is paging.

If I had links I would give you them, but th only thing I can reccomend is getting the book "Windows Internals." That is the newer one. I have the older one titles "Inside Windows 2000." Even "Understanding the Linux kernel" would have a lot of the same info.[/QUOTE]
Then by all means quote the paragraphs and cite the book. If people are to learn, they need to read. Reading "this is how it work" by, no offense, "some guy" on the internet isn't that persuading.

Paging invovles any memory mapped file, which includes any executable that you've decided to load and run.

Please provide a link with detail.

Then I wonder why you're writing an article about tuning PF size. Why not just make it big? It'll never fragment, then. And it'll always be big enough. Disk space is cheap; even a 2 gig page file is probably less than 1/40th of the size of your drive. Why spend time measure and tweak? What am I gaining by following your advice to change my page file size?

Actually after learning how to monitor the PFs usage, through discussing things like this, a large page file may be effective. Size on the HDD is not an issue, as you note. However there may be issues with accessing an unnecessarly large PF, maybe not. If you think it's taht viable, test it and let us know the results. The point of the article is to help people learn more about the PF.

Search the posts I made to your other threads; I pointed out the registry key which contains the name of the files the system will use.

OK, I'll take a stab, but there are a lot of PF threads. I assume you mean the 6 page one...

Again, I realize memory mapped files are used *in place* of paging, but that doesn't mean data is paged to those files. Actually from my reading all memory mapped files are read-only, meaning you obviously can't write data to those files.

Memory-mapped files are not read-only. Memory mapped files make use of paging; they don't replace paging.

What I mean is if the file is mapped, it's not paged to the page file because it's backing store is the image of the file on the disk, is that correct?

 

[mikeblas]

A perfect example is this quote.
This statement is useless to someone who doesn't understand memory mapped files. Now if you explained it in detail, or linked to an article discussing memory mapped files, we can move on from that point. However, now we have to "validate" what's being said here because you didn't. Well, I'm not doing all the leg work here guys. If you want to bring something to the table go ahead, but support it please.

I know that everyone learns differently, but I'm not having much fun guessing how it is you like to learn, or what it is that will make you receptive to a constructive conversation.

You can read lots about memory management on MSDN. If you go to http://msdn.microsoft.com/ and search for "memory mapped files", you'll get links to lots of great articles about what they are and sample code showing how they work.

This article by Randy Kath is great, but it is showing its age. CreateFileMapping() is one of the primary APIs used for mapping a file. This article has links to lots of other APIs that have information about the details of the feature: MapViewOfFile() is probably the next most interesting.

I previously pointed you to the Windows Internals Book. I think KoolDrew has, too. I explained that one of the chapters covers how exectables are loaded, and discusses the mapping of images in that chapter. In response, you said you'd go through the post in earnest later ... but I never saw a further response.

I didn't think it was necessary to post a link because I thought that I had done so before when responding to threads you've been involved in.

I'm not sure at what point you want to start doing your own work. Your own sticky has zero links to backup, tests, or supporting documentation, and that's one of the reasons it is being so strongly challenged. If I write up everything you want in order to substantiate my cliams, then maybe I should just write the pagefile article myself, too.

You don't want people to question you on your sticky thread. When we try to help you on your other threads, we don't get a timeply response. Then, when we follow you to your still another thread, you want us to substantiate every claim we make because you don't want to research them for yourself, but still want to be considered the definitive source of information on the forum for PF file sizing.

 

[mikeblas]

Quote and cite please.

Let me go the extra mile.

I have a spare copy of Inside Windows 2000, and I'll send it to you (if you live in the US). It's not as cool as the next edition (Inside Microsoft Windows) but it does cover these topics in detail and most of the information in the book is new enough to be applicable to Windows XP and Server 2003.

That will save you the trouble of going to the bookstore or ordering it online, though you'll still have to actually read the chapters we've been telling you to read, or look up your favorite topics in the index.

To show there's no hard feelings, I'll even include an autographed copy of my own book. Just PM me with your address.

 

[mikeblas]

What I mean is if the file is mapped, it's not paged to the page file because it's backing store is the image of the file on the disk, is that correct?

Hey! Progress!! I feel rejuvenated.

Now that you know other files than the page file can be used as backing store to service hard faults, you also know that the perfmon counters are showing all faults, not just the faults that go to the system page file.

 

[Phoenix86]

Sorry, I kinda dropped the ball in that other thread (heh, I work too ya know ). I will read that last post in detail with the info you posted here. Thanks.

Also, while I appreciate the offer for the book (truely, that's very nice of you), but that won't help others visiting the thread.

 

[mikeblas]

Also, while I appreciate the offer for the book (truely, that's very nice of you), but that won't help others visiting the thread.

I'm not about to repost the content of the book here so that everyone can read it. I've already cited the book several times, and some of the details can be found in MSDN anyway. The information I've been posting is from the book (mostly), distilled through me and my experience.

I think you're right to be skeptical about getting information from other people and trusting it. It turns out that some of the people you're dealing with are accomplished in the field, and well-established, even if you don't already know that. While everyone makes mistakes, I for one am not giving you inforamtion that I don't believe to be 100% correct.

If you don't know anything about memory-mapped files, it's easy to see why you would assert that no other files are involved in paging than the system page file.

 

[mikeblas]

Actually after learning how to monitor the PFs usage, through discussing things like this, a large page file may be effective. Size on the HDD is not an issue, as you note. However there may be issues with accessing an unnecessarly large PF, maybe not. If you think it's taht viable, test it and let us know the results. The point of the article is to help people learn more about the PF.

Effective at what? Providing virtual memory? It certainly is.

I don't think there are; Microsoft Windows Internals tells me so: "increasing the size of the page file does not change system performance, it simply means the system can have more nonshareable committed virtual memory."

 

[Happy Hopping]

Alright, can either of you tell me why xp pro continuously write the paging system file (pagefile.sys) to the hard drive to the point that minutes are passed, and they are still writing to that file.

This doesn't happen often, but once in a while, they keep writing to the hard drive, and nothing can be done, the process is non-stop to the point that I have to shut down the machine by holding the power button for 10 sec.

I really hate to shut down the machine when it is writing to the hard drive as I may lost the entire content of hard drive.

Is it just a bug in XP Pro on its paging system or is there anything can be done about it?

 

[mikeblas]

Alright, can either of you tell me why xp pro continuously write the paging system file (pagefile.sys) to the hard drive to the point that minutes are passed, and they are still writing to that file.

Nope, as I've never seen that happen.

Have you actually verified the machine is writing to the page file? How? Which apps are credited with causing the page faults?

The reason I ask is that there are lots of programs which might do background hard disk access, and I've seen lots of people assume that that disk activity was acutally to the page file without investigating it.

 

[Happy Hopping]

In those incidents that it happened, there is nothing running. The only suspect is the page file, which generate a very large pagefile.sys file, I have seen them as large as 800 - 900 MB.

There is nothing else that can remotely justify the on-going non-stop writing of the hard drive, unless you can come up w/ some other suggestion.

 

[mikeblas]

In those incidents that it happened, there is nothing running. The only suspect is the page file, which generate a very large pagefile.sys file, I have seen them as large as 800 - 900 MB.

There is nothing else that can remotely justify the on-going non-stop writing of the hard drive, unless you can come up w/ some other suggestion.

I'm confused. Is it absolutely impossible that nothing can possibly be writing to the hard drive, or is it possible that someone can point out something which might have been causing that I/O?

By what process did you eliminate all other suspects", leaving only the page file as a candidate? Also, note that the page file is a file -- it's not a process. It might be the target of the I/O operations, but it isn't the cause of the I/O operations.

An 800 megabyte page file is by no means large. Even so, just because the file statically has that size does not neccessarily mean that it was recently written to be that size.

There's always something running, and always more than one thing: services, virus software, the indexer, and so on. If you investigate the problem on your machine yourself, I'm sure you'll find dozens of processes running. I'd suggest you start by looking at what processes are active when you think nothing is running, and measuring which one is doing how much I/O or causing page faults. If you don't know how to do this, please ask and I will try to help you.

 

[Phoenix86]

*just checking in*
I have been dealing with "life" issues and haven't gone through all the reading, but I AM doing it.

Happy Hopping, what is your commit charge peak (task manager) vs physical RAM?
When does it seem to page for minutes at a time, is there a pattern?

Basically there is *some* program using lots of PF space, look in task manager, add the VM size column and tell us what has a large amt. of usage (wild guess, it may be firefox with too many browser windows open).

 

[mikeblas]

Basically there is *some* program using lots of PF space, look in task manager, add the VM size column and tell us what has a large amt. of usage (wild guess, it may be firefox with too many browser windows open).

I think that task Manager offers far better counters than Virtual Memory Size for diagnosing Happy's problem. I/O writes, I/O Reads, Page Faults, and Page Faults Delta are all interesting. Note, though, that the fault counts here are all faults and not just hard faults.

 

[Phoenix86]

I think that task Manager offers far better counters than Virtual Memory Size for diagnosing Happy's problem. I/O writes, I/O Reads, Page Faults, and Page Faults Delta are all interesting. Note, though, that the fault counts here are all faults and not just hard faults.

I think you mean perfmon, task manager is just a quick and dirty look.

 

[rcolbert]

Task manager is better for figuring out which process is borking. Perf Mon doesn't slice and dice down to the process level when it comes to memory as far as I can tell.

 

[Phoenix86]

Task manager is better for figuring out which process is borking. Perf Mon doesn't slice and dice down to the process level when it comes to memory as far as I can tell.

Well, that's why I recommended task manager, and I'm confused about what he's suggesting...

 

[rcolbert]

Well, that's why I recommended task manager, and I'm confused about what he's suggesting...

I recognized the disconnect and understood your recommendation. I was also confused by the response which basically sounded like "task manager is ok, but task manager is better."

 

[mikeblas]

I think you mean perfmon, task manager is just a quick and dirty look.

PerfMon is ideal, but it is harder to use.

TaskManager has some of the same per-process counts that PerfMon does, and will let us, at a glance, decide what the problem really is.

From what Happy has reported, we don't know if paging is the issue in the first place; we can determine if it's paging or I/O by looking at the "Page Faults", "Page Fault Delta", "I/O reads" and "I/O Writes" columns for each of the processes in the "Processes" tab within Task Manager.

Task Manager will show us that a particular process is doing lots of page faults, then we know that guy is the problem. Or, it will show a particular process is doing lots of I/O. Then, we know the I/O is an issue and not PF ... but we still know which program is the culprit and can work on addressing it.

You can use PerfMon for the same measurements, but it's harder to use. You have to add three or four counters per process, and that's tedious. PerfMon does have the advantage of doing logging, though; if the problem is sporadic or hard to repro, then maybe that's the way to go.

 

[Happy Hopping]

Mike:

I am well versed in those "Services" running in the background. In fact, I kill some of those like wireless, auto win xp update, as I don't use them.

Happy Hopping, what is your commit charge peak (task manager) vs physical RAM?

Commit Charge (K)
Total = 232676
Limit = 1026420
Peak = 357640

And my sys. RAM is 256 MB

When does it seem to page for minutes at a time, is there a pattern?

totally random and once in a while. My application software are very plain, just Corel WP 2000 suite, Netscape, and a few cheap shareware like ACDSee, FotoCanvas, Eudora.

Basically there is *some* program using lots of PF space, look in task manager, add the VM size column and tell us what has a large amt. of usage (wild guess, it may be firefox with too many browser windows open).

I don't have Firebox in my computer. Right now, the largest one is Netscape at 48,280K, the next largest one is explorer at 7668K.

I will continue to monitor the Task Manager and when this happens again, I'll write down the name of Processes and find out what software it is.

On unrelated matter, I have talked to a few people, there are at least 2 other friends that have the same issue. One lady who has a P4-1.3GHz at 128 MB of RAM mentioned the same thing to me. So I am not the only one.

I really appreciate the help that you guys offer me so far. I'm going to screen capture and find out who the wise guy is.

 

[Phoenix86]

OK, it's not one program that's causing the paging, it's all of them. Your system is starved for RAM (~40%), increase the memory (to at least 512) and you will page MUCH less. The reason it's paging is because you don't have enough RAM to keep all your *active* programs in memory.

Services that start, and are never used are not really a factor as they are never being read once paged to disk. It's the programs you are activly using, taskbar programs, & user apps. like netscape that will cause paging. Well, you can't really stop using those, as that's what the PC is there for... You can try to close programs you are not using and open them later when you do need them again.

Download 3rd party defrag software like O&O Defrag and analyze your system, is the page file fragmented? If so, defrag it.

 

[mikeblas]

Perf Mon doesn't slice and dice down to the process level when it comes to memory as far as I can tell.

What is "borking"?

Meanwhile:

1) Run PerfMon
2) Add Counters
3) Press the [+] button to add counters
4) In the resulting "Add Counters" window, select "Process" for your performance object.
5) In the "Select Counters from List" box, multi-select "Page Faults/Sec", "Working Set",
and "I/O data bytes".
6) In the "Select instances from list" box, multi-select a handful of processes.

You've now "sliced and diced down to" the interesting memory counters for the individual processes you've selected. You can choose other per-process memory-related counters in the counters list, if you'd like.

The problem is selecting multiple processess to monitor. If you select them all, you end up with a really busy and potentially confusing graph. You can go to a report view, but you'll end up with something the same as (but not quite as clear as) Task Manager.

 

[rcolbert]

Interesting. I was looking in the wrong place (memory).

 

[Phoenix86]

mikeblas, I didn't know you could go into per process like that, I too was looking under memory.

Bork.

 

[Happy Hopping]

Alright, next time the disk spinning to hell, I'll engage in those tricks and let you guys know what happens.

Thank guys for everything so far.

 

[Phoenix86]

With perfmon you need to start the diag before the problem... It also has logging options so you can look at the results later.

 

[rcolbert]

Your system is starved for RAM (~40%), increase the memory (to at least 512) and you will page MUCH less. The reason it's paging is because you don't have enough RAM to keep all your *active* programs in memory.

This is the only information you really need in this case. Deep analysis of how the small amount of memory that you have is being used is kind of like trying to figure out how to slow down your breathing sufficiently to survive with your head wrapped in a small plastic bag.

 

[Phoenix86]

This is the only information you really need in this case. Deep analysis of how the small amount of memory that you have is being used is kind of like trying to figure out how to slow down your breathing sufficiently to survive with your head wrapped in a small plastic bag.

LMAO, yeah I guess the analogy works.

 

[Happy Hopping]

One minor thing, while we are on the subject of disk spinning from XP Pro:

Whenever I used either Windows Explorer, or a Graphics viewing software like ACDsee going to a directionary with JPG:

1) Explorer would love to read every single file and creates the thumbnail. I set the explorer View to Detail, but they are still spinning my hard drive for quite some time (30 sec or so)

2) ACDsee -- when I open to say a certain default sub-dir with JPG, there is a considerable amount of disk reading, although I have turn off any cache, or any read ahead function.

Now, neither of the above occurred when I was using Win 98 SE, this is clearly a XP PRo function. Is there a way to disable this function?

 

[rcolbert]

I don't know about ACDsee, but with Explorer in my experience the tumbnails only get created when you're in thumbnail view. My evidence to this is largely circumstantial, but it appears to me that my thumbs.db file is timestamped and falls right in line with the moment in time when I last used thumbnail mode. If I add a lot of new pictures, the thumbs.db doesn't seem to grow or get a new datestamp until I switch back to thumbnail mode. Anyone else find the same to be true?

 

[Happy Hopping]

I agree. But the default is always thumbnail mode. Accordingly to the Option tab of windows explorer, you can save the saving of any mode, including Detail mode, and the software should save that setting.

But I have a lot of JPG sub-dir, how on earth do you get the default of all sub-dir to be detail mode, or any other mode rather than the stupid thumbnail mode?

 

[rcolbert]

You can change it globally in the folder view settings. First change your view to whatever you like, then open up the folder view settings and deselect the option to save each folder's view settings, and also reset all folders to be like current folder.

 

[Happy Hopping]

Thanks very much. It works.

==============

as to the hard drive continuous writing issue, I haven't seen it lately. But my friend claim he is still having that issue. But he has an educated guess: he thinks it is the Windows REgistry update backup.

Someone told him that the registry backup takes 15 - 20 min. For whatever reason, his computer must be set to frequent backup, and if it does take 15 min. or so, that would explain why the hard drive is keep on writing.

Any 2nd take on this?

 

[mikeblas]

The sticky is locked, but is still kind of iffy in some areas ... but we're making no progress with this corrections/questions thread.

I think locking stickies is the wrong idea, at least if the issues in them haven't been discussed to clarity.

I also just noticed odoe's post in the sticky. I must say I am a bit scathed by it: while I might have appeared confrontational in pressing for clarifications or corrections, I certainly never pushed on any absolutes or refused a compromise offered to me.

Any forum that doesn't hold accuracy, constructive criticism, and healthy questioning over perceived confrontation and friction is not going to be a good place to get clear and reliable information.