# Putting the Pagefile on a Separate Partition?



## PVTCaboose1337 (Oct 9, 2006)

How do I do it?  Will it improve performance?


----------



## pt (Oct 9, 2006)

i want to know that too


----------



## PVTCaboose1337 (Oct 9, 2006)

pt said:


> i want to know that too



Well we are in the same boat.


----------



## pt (Oct 9, 2006)

PVTCaboose1337 said:


> Well we are in the same boat.



let's keep it above the water 'cause i cant swim


----------



## Alec§taar (Oct 9, 2006)

*BIT OF A READ, BUT SOME "FOOD FOR THOUGHT":*

If you left pagefile.sys "System Controlled" as to its size, via Control Panel, System Icon, & set it to another partition OF ITS OWN? 

Moving it to its own partition as placement MIGHT stop other files & the pagefile.sys itself from fragging itself & other files, some performance bennies may be there, and, IF it is left system controlled?

Well, pagefile.sys may grow/shrink (especially on reboots & if you set it as "clear pagefile.sys" on reboots, via secpol.msc for instance & it has to reform later on reboot), contributing to a KNOWN "perfomance detractor" in file fragmentation.

Also, leaving it "System Controlled" (as to its sizing) & doing this placement of the pagefile.sys onto its OWN partition (*using tools like Partition Magic for example, a partition mover/resizer tool, OR possibly, diskpart, via Recovery Console*) means you do not have to monitor your VM usage/pagefile.sys usage, sizing it for your USUAL use-patterns... which takes time & patience, imo.

All it takes is that 1 app, or dataset, to "upset" sizing pagefile.sys usage to a "MINIMUM SIZE" & you run out of virtual memory... it's risky to an extent imo @ least, doing that, unless you go "HUGE" on it immediately (like 1-4gb sized pagefiles).

Now, if pagefile.sys is on the FIRST partition/outermost part of the diskdrive (fastest due to larger circumference & all that) it would gain speed there also, but then, your OS & programs don't get it (trade off).

** Think about it... it tends to make some sense!*

STILL - I wouldn't expect HUGE increases doing placements of pagefile.sys onto its OWN partition on the C: drive (assuming you only have 1 HDD), but some, & some for the long-haul...

(This is how I see it @ least, & perhaps you will too (or, see objections to doing it)).

Microsoft, iirc, tends to keep it @ the midpoint of the diskdrive (edit part, per my 'correction' upon re-reading this, per my next post below (sorry))!

(Sort of like how a binary search works: So pagefile.sys is ALWAYS @ the 1/2-way mark position on the diskdrive, & the diskdrive heads don't move 1 way or the other TOO much - thus, it may actually make SENSE to place it on a partition in the middle of your disk when you use a single HDD only!)

APK

P.S.=> Plus, if you think about it: If the pagefile.sys is NOT on C:\ drive, typically your OS & program disk? 

Then, anything those files are doing (data & programs) on C: aren't 'encumbered' by additional head movement on the drives on THAT part of the platter... 

However, that tends to work best, if you do the pagefile.sys on ANOTHER diskdrive... apk


----------



## trog100 (Oct 10, 2006)

no it wont.. not in any noticable way..

trog


----------



## Alec§taar (Oct 10, 2006)

Well, since we're on the subject of placing pagefile.sys into a separate partition on the same disk w/ your OS & programs?

Here is an "odd one" you may wish to try/experiment with one day, or just some "esoterica" to be made aware of, excerpts are partially from JSIINC (one of the better 'tips/tricks/techniques' sites for Windows NT-based OS' there is):

*PAGEFILE.SYS located inside of a folder "how-to":*

By default, the Pagefile.sys is created in the drive root of C: drive typically, where your OS is located.

*NOTE:* Always set the Initial and Maximum size the same, to avoid fragmentation of the paging space.

To move the pagefile from the root of the drive, use Regedt32/regedit.exe to navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Double-click PagingFiles, a type REG_MULT_SZ value, in the right hand pane and click in the Multi-Sting Editor to remove the automatic selection. 

Edit the string to insert the full path to the pagefile.sys entry/entries.

E.G. -> Change c:\pagefile.sys <Initial> <Maximun> to c:\Windows\temp\pagefile.sys 

The folder you choose must be granted System - Full Control permissions.

(After you restart, you may delete the pagefile.sys in the root directory.)



* No "HUGE TRICK" but, one worth noting & being aware of imo...

APK

P.S.=> 





trog100 said:


> no it wont.. not in any noticable way..



It will make a diff. though, but mainly imo? Like you said: Nothing immediately perceptible, but placement of it CAN help (outermost tracks speeds are greater on disks, but a 'trade-off' of sorts exists on this one, noted above, if you only have a single diskdrive).

Gains would be "seen" only for avoiding fragmentations of the pagefile.sys (& this is assuming you left its size as "System Controlled" & not as JSIINC excerpt above recommends setting a 'static' pagefile.sys up for, which I also practice) itself, &/or other OS or Program files & their data files used (if the pagefile.sys begins to grow, or reform/shrink upon reboots)... IF you only have a single disk to use.

If I had a single diskdrive only? 

I'd make a smaller partition in the center of the diskdrive for pagefile.sys, mainly because of HOW 'binary searches' work...

I.E.-> If pagefile.sys is in the literal CENTER of the disk?? Any seeks for it would be kept around the same amount of time no matter where they are done from on the diskdrive... apk


----------



## PVTCaboose1337 (Oct 11, 2006)

Ok, im not gonna make the change...  too much work for little payoff...


----------



## Alec§taar (Oct 11, 2006)

PVTCaboose1337 said:


> Ok, im not gonna make the change...  too much work for little payoff...



Know what? I tend to agree - ESPECIALLY if you set your pagefile.sys as "STATIC" (unresizing, because you basically KNOW your use-patterns & their sizes in memory via program load &/or data ontop of it)...

The mid-disk placement of it though, MIGHT actually be the best way to do it on a single disk though!

(By the by:  I was wrong above about MS having the pagefile.sys there though, @ the midpoint of the HDD! Iirc, it is the MFT$ (master file table) that's located there, or as near to it as possible - but still, IF YOU THINK ABOUT IT, & how the mechanism of a binary search pattern works? It MAY be "the way" to do it on a single HDD!).



* Good stuff though, if you have more than 1 disk... especially via placement on the FIRST/outermost tracks of said 2nd HDD... 

APK

P.S.=> Due to faster access/reaccess via larger diameter (like larger tires work on vehicles basically, &/or "short-stroking" HDD's so they appear faster on tests than they actually are (for better "avg. read" etc.))... & sorry about the 'verbose' amounts of detail above, but hey: YOU ASKED, lol! apk


----------



## lemonadesoda (Oct 19, 2006)

Pagefile.sys in the MIDDLE of the disk is *not* optimal.

The optimal location for pagefile.sys is next to (1) an area that the PC uses most often, and (2) at a minimum distance from ALL other files. 

Guess what? If you defrag your hard drive often, then your files are bunched up near the start of the drive. Especially all you OS and PROGRAM files.  If you ever get near to full capacity, what you are loading tpward the end tends to be data/MP3/movies etc. and not the frequently accessed program and system files.

In fact, since most HDD (system drives) are approximatley half full, the optimum location is midway within this half-full drive, i.e. 25%.

So you should:

1./ Put your pagefile.sys somewhere in the 25%-33% location
2./ Make it contiguous, no fragmentation
3./ Lock it down so that it does not grow, move, and fragment
4./ Use a special defrag utility to put your \windows directory together, and near to the pagefile.sys


----------



## DaMulta (Oct 19, 2006)

Just turn it off, granted you have the memory to do it.


----------



## Slater (Oct 19, 2006)

uhhh why was the link I posted deleted?


----------



## Alec§taar (Oct 21, 2006)

lemonadesoda said:


> Pagefile.sys in the MIDDLE of the disk is *not* optimal.
> 
> The optimal location for pagefile.sys is next to (1) an area that the PC uses most often, and (2) at a minimum distance from ALL other files.



Interesting way to think about it, & it makes sense due to "Windows XP boottime prefetch" going on as well as how defraggers work... 

Initially? This makes sense... but, what about when your disk begins to be nearer to being filled up??

Also, how do you KNOW what the 25-33% location will be in say, a year from now? Remember: This is a partition, & typically, that's unmoveable... unless you own PQMagic or tools like it, which would allow NON-DATA DESTRUCTIVE partition movements OR even resizing non-destructively (not everyone has this).

(And, this is an inevitability, that you will eventually begin to load your disks more & more @ some point)...



lemonadesoda said:


> Guess what? If you defrag your hard drive often, then your files are bunched up near the start of the drive. Especially all you OS and PROGRAM files.  If you ever get near to full capacity, what you are loading tpward the end tends to be data/MP3/movies etc. and not the frequently accessed program and system files.
> 
> In fact, since most HDD (system drives) are approximatley half full, the optimum location is midway within this half-full drive, i.e. 25%.
> 
> ...



I would think @ least, that when you reached that point? The mid-disk placement would work the MOST optimally, over the long haul... because where would your 23-33% placement be a year later? Way too far up from midpoints... & there is reason to see it that way, over the long haul: MFT$ performance is placed this way for the very reasons I outline.

APK

P.S.=> Also, iirc, Microsoft does what I am saying (mid-disk placement) on the MFT$ (master file table) & for the SAME reasons I stated, due to it bein like how a binary search pattern works (always @ midpoints of datasets, cutting in 1/2)... & that works for performance gains! apk


----------



## stealthfighter (Oct 21, 2006)

I f***ed up my PC and had to reformat and just created a 2048 mb partition and made that teh pagefile and put 4096 on main partition and it does help a little bit


----------



## Alec§taar (Oct 24, 2006)

stealthfighter said:


> I f***ed up my PC and had to reformat and just created a 2048 mb partition and made that teh pagefile and put 4096 on main partition and it does help a little bit



A little bit? Yea, maybe some... but, still, guys: There's no real 'substitute' here for doing it on a single diskdrive, vs. using another one to handle paging duties...



Seriously recommend using another disk for this, as I note above, to get MORE out of this technique... but, that means monetary outlay for the cost of the drive, installing it & your time (or that of others you pay to do so) & then the electricity bill going up because you are drawing more power!

APK


----------



## AshenSugar (Oct 24, 2006)

DaMulta said:


> Just turn it off, granted you have the memory to do it.



NO, this isnt a good idea even with 4gb ram windows will still use and need the page file, not for windows itself but some apps spicificly use the page file, and wont work if its not avalable(some games for example store data in page file )

if you dissable it be prepared for problems when they come.


----------



## AshenSugar (Oct 24, 2006)

Slater said:


> uhhh why was the link I posted deleted?



somebody probbly thought it was spam, happened to me when i first started comming to tpu forums.


----------



## Alec§taar (Oct 24, 2006)

AshenSugar said:


> NO, this isnt a good idea even with 4gb ram windows will still use and need the page file, not for windows itself



Yes, it will... explorer.exe is CONSTANTLY paging (pagefaults are visible on it in taskmgr.exe, even w/ HUGE amounts of RAM)... if this is hard to believe?

EDIT: Ah, here it is (HAH, the test is in THIS thread, showing even w/ 2gb of RAM? You get paging (pagefaults) by explorer.exe):

http://forums.techpowerup.com/showthread.php?t=15577

The rest you are dead-on about - this should "round out" your knowledge in this area & I would look @ the test he & I did... subject was about pagefile.sys placements, size, if you need it w/ 2-4gb of RAM etc. (full battery of ALL kinds of tests in fact).

APK


----------



## lemonadesoda (Oct 24, 2006)

@alexstaar

I don't understand why you are disagreeing with my tips, and then in your post agreeing! It's a bit confusing.


> Also, iirc, Microsoft does what I am saying (mid-disk placement) on the MFT$ (master file table) & for the SAME reasons I stated, due to it bein like how a binary search pattern works (always @ midpoints of datasets, cutting in 1/2)... & that works for performance gains



You answered your own scepticism and confirmed my recommendation.

FIRST, most HDDs are NOT FULL, by a long shot.  So by your "binary binary" method, you should be somewhere in the middle of your defragged and condensed drive (all data moved up), ie. in the middle of a say, half to two-thirds fill drive.

SECOND, if your HDD is nearly full, what is in the latter portion tends to be data files not system files or programs. These will be "higher up" the HDD.

THIRD, is that your defragged drive is best if "ordered", by having the files you need to play "performance", ie. Windows system files, incl. the pagefile, all nicely next to each other.

***
PS. If you disagree with point one then you are completely mismanaging our HDD. For 90% of the HDDs life, it is nowhere near full. Tip: Format you C: drive to 30MB, install windows and programs.  Put your games and other data on a separate partition. Why?

(i)./ 30MB and less is optimal sector size for system files. >30MB will result in larger sector size resulting in more space being consumed by hundreds of mini-files, and larger sectors means less files loaded in one "cached read"
(ii) to stop the eventual "shuffling the pack" that will occur
(iii) protect your data from system crash or need to reinstall
(iv) makes backing up data partition a piece-of-cake

PPS. I challenge you to get yourself a defragger that allows you to position certain files and folders. Follow my tips. You will *feel* the difference. The recommendations are based on more than ten years of field experience.


----------



## Alec§taar (Oct 25, 2006)

First off: Optimization, the science of it? Is based on something that is good for ALL conditions!

Not just the ones you encounter today, but also years from now... keep this in mind:



lemonadesoda said:


> @alexstaar I don't understand why you are disagreeing with my tips, and then in your post agreeing! It's a bit confusing.



I agree that it makes sense, INITIALLY! How about over time though? 

My man, NEWSFLASH:  It won't... eventually it will not be as good @ its performance & if you want it to be again? You'll HAVE to move it.

AGAIN: Once you place your "mid-data" location (your 25-33% of the way into your disk as you stated) for a separate pagefile.sys partition? Well, what will happen when the disk gains more data than that is all... you won't be "mid-data" anymore.

And, if you DON'T have a non-destructive repartitioning tool like Partition Magic (tools like it do NOT come native w/ the OS, & face it: MOST FOLKS DON'T OWN IT)? Well... how will you move it later to BE "mid-data"??

Remember: It's a partition... unmoveable typically. ONCE YOU PLACE IT? It's generally 'stuck', unless you use & can afford (or in the case of many folks, even KNOW about it) such a tool like PQMagic?

If you place it middisk right off on a single disk system? You ARE optimal for ALL conditions present to future & you DON'T NEED 3rd party tools anymore, because this is optimal from day #1 near empty disks, to the day the drive is near full.



lemonadesoda said:


> FIRST, most HDDs are NOT FULL, by a long shot.



That's not true for "ALL" folks! Especially today, what with filesharing gone rampant & folks downloading entire FILMS by the score!

E.G. -> I have a 74gb WD Raptor sitting here VERY near to full, with data from downloads, which WERE on my main disk @ one point, packing it full as well, or on the way to it, VERY FAST!

Hence, why I went 2 days ago & bought a SamSung SpinPoint 250gb ($65 only approximately, great deal, CompUSA store closing)!

I was running out of room for data storage, first on my main disk, & later on the WD even (both had programs & OS on them).

Like SO much in this field? It depends on the user & how they use their system, or a particular component in a system!

Eventually, you WILL fill your disks somehow, data grows (this is a "rule" of sorts in MIS/IS/IT in fact, ask any network engineer running a network), it's that or use offline storage (I choose not to anymore, TOO slow).



lemonadesoda said:


> So by your "binary binary" method, you should be somewhere in the middle of your defragged and condensed drive (all data moved up), ie. in the middle of a say, half to two-thirds fill drive.



Look up "Binary Search" & understand why mid-dataset placements work!

It shows in fact, you how NTFS itself even works on searches - Always cutting to midpoint of the data & searching. It's proven & definitely works.

*AND, You're STILL assuming disks aren't full... or nearing it. This is inevitable... data grows & ESPECIALLY TODAY in the era of "filesharing" programs, even @ the HOME LEVEL!*



lemonadesoda said:


> SECOND, if your HDD is nearly full, what is in the latter portion tends to be data files not system files or programs. These will be "higher up" the HDD.



Not necessarily: If they are not used as much as certain data files, say movies you watch from your disks?? Which moves to the front, due to "prefetch optimizations"???

Here's a snippet from taken from the Microsoft website:

http://askbobrankin.com/windows_prefetch.html

"Windows XP monitors the files that are used when the computer starts and when you start applications. By monitoring these files, Windows XP can prefetch them. Prefetching data is the process whereby data that is expected to be requested is read ahead into the cache. Prefetching boot files and applications decreases the time needed to start Windows XP and start applications."

Diskeeper's I-FAAST & Raxco's SmartPlacement features? Variations of this theme, @ best. 



lemonadesoda said:


> PS. If you disagree with point one then you are completely mismanaging our HDD.



I do disagree - what happens if you place your pagefile.sys TODAY, in a partition mid-data (most folks can't do this anyhow, the OS does NOT come w/ the tools, & many are NOT aware of this anyways), today.

What happens a year from today when you added programs, data, etc.? Is YOUR placement on a PARTITION still 'optimal' for all conditions, even near full disks?



lemonadesoda said:


> For 90% of the HDDs life, it is nowhere near full.



Ok: Tell that to my WD 74gb disk here that is only like 7gb away from being totally loaded!



lemonadesoda said:


> PPS. I challenge you to get yourself a defragger that allows you to position certain files and folders. Follow my tips. You will *feel* the difference. The recommendations are based on more than ten years of field experience.



OH, I have 2 of them in fact (Raxco PerfectDisk, now, & Executive Software Diskeeper)... 

AND, just so you know? Windows Defragger functions on the SAME MoveFile API & also obeys Windows "prefetch optimization" rules as well! 

I.E.-> Helping to move MOST USED FILES to the front of the diskdrive, where the fastest outermost largest circumference tracks are. IIRC, the technology actually originated w/ INTEL on this topic in fact.

Well, I've been @ this field for nearly 25 years solid (14 as a pro in various capacities from network engineer/tech to programmer & most all else in between) & not ONLY @ a tech field engineer level, though it's where I started!

I just use the logic involved in mathematical principals like Binary Search Methods on this topic here.

*Mid placement of something in ANY dataset assures you that you will never travel more ONE direction, than the other direction involved... over the LONG HAUL of a lifetime of a disk ESPECIALLY today? Means placing the pagefile.sys into a parition that is MIDDISK... because that disk, especially today in the era of filesharing, will begin to fill up!*

Thus, it is CONSISTENTLY OPTIMAL, in any conditions to place the pagefile.sys into a partition, mid disk, on a SINGLE DISK SYSTEM...

Especially over nearing full disks & especially over the long haul.

APK

P.S.=> Still, I don't know WHY the heck folks just don't buy a 2nd disk & put their pagefile.sys onto it... if they WANT performance? This is the way to go... your programs & OS exist peacefully on 1 disk & are NOT interfered w/ in paging operations.

Disks, today? Relatively cheap, especially when viewed on a price-per-mb level... apk


----------



## lemonadesoda (Oct 25, 2006)

Ah, Mr. Natural Born Contrarian, I see.

Place your pagefile in the middle of your defragmented, consolidated, moved up to the front of the HDD "files", AND THE MIDDLE OF THIS LOT IS NOT THE MIDDLE OF THE PARTITION!!!!

How many times have I got to repeat myself?

For 90% of a HDD life the disk/partition is nowhere near full, and the 25%-33% location is statistically optimal.  Always be CLOSER to the START than CLOSER to the end because GUESS WHAT... the data comes off faster.  I don't give a hoot about your own personal mismanagement of your HDDs, because, like you said a hundred times, we are talking about the typical user, not your attic, or what you've got stuffed under your bed.

Why don't you do some analysis of your HDD?  First try using HD Tach for a starter, http://www.simplisoftware.com/Public/index.php?request=HdTach and post a screen shot.  Then try doing some other benchmarks second.  I very much welcome an analytic discussion based on facts and observations. But your **unproven yet repeated speculations** are drawing yawns from the crowd. 

TIP: be careful about basing your knowledge on the output of defraggers like PerfectDisk  . While they are good, they certainly are *not* perfect.  And remember their "optimisation rules" include other factors ... like total defrag time ... because this is the main benchmark used in marketing materials.


----------



## Alec§taar (Oct 25, 2006)

lemonadesoda said:


> Ah, Mr. Natural Born Contrarian, I see.



Whatever...



lemonadesoda said:


> Place your pagefile in the middle of your defragmented, consolidated, moved up to the front of the HDD "files", AND THE MIDDLE OF THIS LOT IS NOT THE MIDDLE OF THE PARTITION!!!!



Yes, and when the drive begins to fill up, & this IS a fact of life, data grows (especially today w/ a world of file sharing programs in use by common folks)? Where does that "MIDDLE OF THIS LOT" change to?

It will change, because your volume of data present does.



lemonadesoda said:


> How many times have I got to repeat myself?



As many as you'd like...



lemonadesoda said:


> For 90% of a HDD life the disk/partition is nowhere near full, and the 25%-33% location is statistically optimal.  Always be CLOSER to the START than CLOSER to the end because GUESS WHAT... the data comes off faster.



Elementary Dear Watson... but, the point I am trying to make is that you seem to think that your disks are EVERYONE'S DISKS... newsflash: They're not. NOR are mine.

BUT, I used other examples that apply more than YOUR disks, OR mine... read on!



lemonadesoda said:


> I don't give a hoot about your own personal mismanagement of your HDDs, because, like you said a hundred times, we are talking about the typical user, not your attic, or what you've got stuffed under your bed.



Fine - what about folks in datacenters managing NAS & SANS? Ask most network engineers about disks filling up over time... they do, this is a given.



lemonadesoda said:


> Why don't you do some analysis of your HDD?  First try using HD Tach for a starter, http://www.simplisoftware.com/Public/index.php?request=HdTach and post a screen shot.  Then try doing some other benchmarks second.



I don't know how long you've been around here, but we've 'been there & done that' (plenty of them).

In fact? YOU might want to see who took that test, overall... lol! Might surprise you...



lemonadesoda said:


> I very much welcome an analytic discussion based on facts and observations.



No, it doesn't appear that you do... 

Above & in posts earlier in this thread?

I mention things like what I have seen in datacenters in large companies, & you just "blow it off" & keep saying they are "stuffed under my bed" etc. on the diskdrive capacity filling up etc. w/ disks of mine!

Once more: Disks in the NAS/SAN scenarios I have seen on the job in this field, for over 14 years as a pro... think those don't fill up too?



lemonadesoda said:


> But your **unproven yet repeated speculations** are drawing yawns from the crowd.



Hmmm... you sure it's not the OTHER way around, & the shoe is on your foot? I know what I've accomplished in this field, and can show it... question is, can you?

DOUBT IT! @ least by way of comparison... 



lemonadesoda said:


> TIP: be careful about basing your knowledge on the output of defraggers like PerfectDisk  . While they are good, they certainly are *not* perfect.



And, tests like HD Tach, are? This is evidence of placements of MFT$ being MID-DISK as I stated earlier no less, from Raxco PerfectDisk (& doubtless WHY you are attempting to "invalidate it" as an evidence of what I state):







And, as far as HD Tach tests? We ran those here... it might surprise you whose system took the MOST #1 placements (mine) & overall did the best here, in a forum FULL of performance-oriented folks no less!



lemonadesoda said:


> And remember their "optimisation rules" include other factors ... like total defrag time ... because this is the main benchmark used in marketing materials.



I am not using Diskeeper, or PerfectDisk as my "proofs" here (I am not sure how you drew that conclusion either, but I am FAIRLY certain that you KNOW it will bear out my statements & thus, you are trying to invalidate my use of it: Nice try, NO DICE)... 

I am, however, using some BASIC principles about the science of optimization & yes, as anyone can see above? PerfectDisk bears out one of those statements on MFT$ placements!

*Mid-disk (not mid-data) pagefile.sys placement will ALWAYS be optimal for performance, in any conditions, over any period of the life of the disk... Whereas Your method? Only temporarily will it fit that & be "optimal", because you'd be adding data to your disks over time, & the midpoint of that data?? Will change due to you adding data to your diskdrives over time.

You'd have to move your pagefile.sys partition over, & over, & over again... my method does NOT require that.*

APK

P.S.=> In any event: Still, I don't know WHY the heck folks just don't buy a 2nd disk & put their pagefile.sys onto it... 

If they WANT performance? This is the way to go, & it will get them a better "performance yield" than doing this partitioning of their single diskdrive setup for pagefile.sys placements... 

That way? Your programs & OS exist peacefully on 1 disk & are NOT interfered w/ in paging operations which are happening on said 2nd diskdrive.

Disks, today? Relatively cheap, especially when viewed on a price-per-mb level... apk


----------



## lemonadesoda (Oct 25, 2006)

Nope. I didn't say keep moving it. I said fix it. Somewhere in the 25%-33% range. It' s better to fix it there, than to fix it at 50%, assuming your system files are at "the top" of the drive somewhere, and your data files are at "the bottom" somewhere.

And to quote you AGAIN "because you'd be adding data to your disks over time" = 90% of the time you are filling up a disk that is not full. And your 50% mid point IS ONLY OPTIMAL when the disk IS FULL. So until you reach this point, then the optimal position of the pagefile.sys is somewhere less than 50%.

LOL

Datacentres!? Data on the system partition?! LOL 

I do agree with your "2nd disk & put their pagefile.sys", so long as its a separate disk on a separate channel.  Have you tried experimenting with a Solid State pagefile? We have, and it's great, but we are very very concerned about data integrity/lifetime of the solid state device. Naturally, we have turned off "record last access time/date" to reduce writes and disk thrashing.


----------



## Alec§taar (Oct 26, 2006)

lemonadesoda said:


> I do agree with your "2nd disk & put their pagefile.sys",



You should, it makes sense, & it works!

(I've been using the technique since 1993 or so).



lemonadesoda said:


> Iso long as its a separate disk on a separate channel.



That was a problem on older systems. Newer mobos & IDE/EIDE circuitry have gotten by having a "slower disk on the same cable slows down the faster of the two (or more in the case of SCSI) diskdrives", by the way.



lemonadesoda said:


> Have you tried experimenting with a Solid State pagefile?



I'd wager I was doing it before anyone & have actual documented proof thereof... 

Fact is, write the folks who create these things, like CENATEK & see their front page of their website (I did one of the reviews they feature). That was in 2002-2003.

LONG before that? For EEC Systems (SuperSpeed.com), who can tell you the same, from as far back as 1996-1997 in fact.

That is when I wrote up this technique in fact, before anybody else did, while developing code for them & their SuperDisk/SuperCache products lines.



lemonadesoda said:


> We have, and it's great, but we are very very concerned about data integrity/lifetime of the solid state device. Naturally, we have turned off "record last access time/date" to reduce writes and disk thrashing.



You 'discovered' a technique I've written about (documented, or you can just check w/ OEM's of these things as I noted above) & used for a decade... first on std. HDD's, then on software based Ramdisks (when I had a system w/ 4gb in it of system RAM) & later on solid-state drives since 2001-2002 or so & it works. You know so & stated it, but are only 'discovering' what I knew on it a decade or more back.



lemonadesoda said:


> Nope. I didn't say keep moving it. I said fix it.



And, thus, you'd HAVE to move it, to 'fix' it... it wouldn't work out, long-term, & you admit it right there.

The middisk placement of a partition for the pagefile.sys ISN'T admittedly optimal, right off, but over the long haul, when a single diskdrive system begins filling up, which IS inevitable, especially today (what w/ filesharing going on especially)? 

It is... more optimal than attempting to do your technique of placement. Both have weakness' though... & using another diskdrive circumvents all of this.



lemonadesoda said:


> Somewhere in the 25%-33% range. It' s better to fix it there, than to fix it at 50%, assuming your system files are at "the top" of the drive somewhere, and your data files are at "the bottom" somewhere.



Is it? Once you add data to that disk on a single-disk system & today folks WILL add that data someplace, especially w/ file sharing programs running rampant hauling in HUGE amounts of data?? You'll fill disks fast.



lemonadesoda said:


> And to quote you AGAIN "because you'd be adding data to your disks over time" = 90% of the time you are filling up a disk that is not full. And your 50% mid point IS ONLY OPTIMAL when the disk IS FULL. So until you reach this point, then the optimal position of the pagefile.sys is somewhere less than 50%.



BUT, you always have it there, & NEVER have to move it... unlike your method, which would DEMAND movements constantly, once more data is added.

Personally? This is the "least best method" of pagefile.sys performance-based increases period... using a single disk. 

The 'dual/2nd disk' method is better, dedicating another diskdrive with a pagefile.sys on a partition @ THE FRONT OUTERMOST FASTEST TRACKS on it.



lemonadesoda said:


> LOL



LOL! (touche)... AND, today? Even @ the home level, data will add up fast (let alone this is a fact in datacenters)... why do you think diskdrives are getting SO big nowadays?

To meet consumer demands for MORE SPACE available.



lemonadesoda said:


> Datacentres!? Data on the system partition?! LOL



Did I say "System Partition"... you have to read closer. Also, in datacenters? I have seen the technique of MULTIPLE pagefile.sys in use, across several diskdrives. This tends to be what is used most from what I have seen in those environs.

APK

P.S.=> Funny how he just "took off" after 'blowing it' on well known facts like EIDE/SATA disks no longer needing to be on separate channels anymore too... 

& I am 'drawing yawns from the crowd' as he stated? Well, since you esteem HD Tach so much?? WELL, again - see whose system took the overall best placements in ALL of its tests here done on these forums, THIS year (very recently).

You're only NOW coming up with stuff only now doubtless after reading material I put up on this topic OR you & your colleagues read what others had, who put it up long after I put it out, & now claim it as 'theirs'...

(Now, I would like to see older citings of it than I put up above from 2 respected software & hardware makers' sites, & that I authored & what is now commonly followed as best practices for performance - if you did not do this, you're STILL 'late to opening day of the game' on this topic vs. myself) 

After all, you're only now "discovering" that which I did more than a decade ago now regarding this topic (as you evidenced above) & put out articles on it from 2 respected manufacturers of ramdisks for on their sites mind you!

AND, also some of the mistakes you made regarding problems with EIDE/SATA that no longer exist & have not for a VERY LONG TIME NOW?? apk


----------



## Ben Clarke (Oct 28, 2006)

Theres always USB memory sticks... and the good thing about those are theres no other files to work through, so it uses it instantaneously. Its as fast as a harddisk too.


----------



## Alec§taar (Oct 31, 2006)

Ben Clarke said:


> Theres always USB memory sticks... and the good thing about those are theres no other files to work through, so it uses it instantaneously. Its as fast as a harddisk too.



Decent idea, provided they can take the 'read/write' load on them for LONG periods, & afaik? They USED to have limited amounts of THAT, that they could take.

Things may have changed on that account nowadays, I am NOT sure... that's just what I've read & recall about those units!

Currently (& for about 4 years now almost), I use a Solid-State RamDisk drive for the purposes of pagefile.sys placement on its FIRST partition. Other stuff too, like browser caches, temp ops, & far far more.

(& looking forward to a FASTER model, supposed to release this year, called the DDRDrive X1, to replace the one I use in my signature (CENATEK RocketDrive)).

The newer to be released one in the DDRDrive x1 uses DDR-RAM (whereas the one I use now only uses PC-133 SDRAM) & also a faster BUS on which it resides (PCI 2.2, wherease the DDRDrive x1 uses a PCI-Express x1 slot).

It will be faster in "burst" of data, than what I have now... should make a diff. in some capacities!

APK

P.S.=> I look forward to its release, "VERY bigtime", in fact... hope it releases this year! It is supposed to @ some point... Then, my CENATEK RocketDrive goes back into my 2nd rig, which is now a lab server here (IIS 6.x/SQLServer 2005 unit)... apk


----------



## lemonadesoda (Nov 8, 2006)

AlexStaar... I see you've made a few edits to your earlier post and added a screenie... So, just to point out a couple of facts:

1./ You mention "Mid-disk" a lot. In fact perfectdisk and other defraggers put the pagefile "mid-partition".  Not mid-disk. 

2./ Quote "& doubtless WHY you are attempting to "invalidate it" as an evidence of what I state".  Oh come on. How boring. I'm not trying to "invalidate" anything. I use PerfectDisk. It's good. But just because its good, doesn't mean its perfect. Just like your sister. She's good. But she sure aint perfect.

3./ If you set up a small boot partition, pagefile is in the middle of the boot partition, not the mid of the disk. This is therefore a good tip. If you have a large HDD, but the OS and pagefile on a small partition up front. Pagefile is then near your system files. Set additional partitions for your data.

4./ Your PerfectDisk screenie of your C: drive is nice. But seems like your C: is nearly empty.  If your pagefile was a bit closer to your neat and tidy system files, then you'd be going a bit faster... QED.  P.S. Having your OS system on a 300GB unpartitioned space is grossly suboptimal.  Use Acronis Disk Director to shrink your C:OS to circa 30MB and create a new partition with the remaining 270MB for data. Report back on how much faster your computer "feels".


----------



## Alec§taar (Nov 8, 2006)

lemonadesoda said:


> 1./ You mention "Mid-disk" a lot. In fact perfectdisk and other defraggers put the pagefile "mid-partition".  Not mid-disk.



Not while inside a separate partition, the premise of this post... and one, no matter WHERE it is placed. 

(Unmoveable during Win32 API Ring 3/RPL 3 Explorer.exe shell operations with std. tools. PQMagic? Maybe... not std. though).

Also - As you see from the PerfectDisk photo above? 

The MFT$ & its zone (20% of your disk mind you while formatted w/ NTFS, unless 0 byte size file attacked (interesting topic there in & of itself, a "hole" in NTFS, that would make a hell of a virus imo, lol))? 

Is mid-disk... 

Why?? Binary Search Trees... from the get go it's mid disk.

Think that wouldn't work for a pagefile.sys LONGTERM?



Especially one in its OWN partition, which is typically unmoveable? Long term?? 

Absolutely!

APK

P.S.=> You see the mid-disk placement of MFT$ & it's 20% of NTFS consumption zone (preallocated blocks)... why? Performance... long term performance! 

Using 1 disk though, as I have stated for years & here already early on & you agreed with? Not nearly as good as a pagefile.sys on another hDD!

AND THAT? Pales compared to solid-state drive usage for it... apk


----------



## Dippyskoodlez (Nov 8, 2006)

Alec§taar said:


> It will make a diff. though, but mainly imo? Like you said: Nothing immediately perceptible, but placement of it CAN help (outermost tracks speeds are greater on disks, but a 'trade-off' of sorts exists on this one, noted above, if you only have a single diskdrive).



A single drive, and the speeds drives currently operate, I'm willing to bet any differences will be very very very close to the margin of error, if it even shows a difference.

However, putting it on a seperate drive... well.... thats a whole nother ball game  

That would work great if you had... say an old 15 gig 10k rpm server drive laying around


----------



## stealthfighter (Nov 8, 2006)

With me, I reformatted windows due to other issues. I decided to make the pagefile partition. I have 1GB ram and keep the pagefile at 1600/1600 at all times and defragged wih a pagefile defragger. What did I notice?
1. Less hard drive noise
2. somewhat better performance however nothing to brag about


----------



## lemonadesoda (Nov 8, 2006)

@stealth

Since you have 1GB, depending on your PC usage, the pagefile might not be getting used (very much).  Therefore, you observations might be explained by:

1./ You had system files or application files either side of your pagefile. Moving the pagefile out of the way allowed you to consolidate your system and app files so they are now very close together

2./ Performance improvements won't be captured by HDD benchmarks. The "feel" may not have changed much because you aren't using the pagefile when "using" the PC, only when loading the OS and applications, or maybe not at all with that 1GB.  May be more obvious with a pagefile hungry adobe application like illustrator or photoshop


----------



## Casheti (Nov 8, 2006)

I put a pagefile on my games partition once when I was getting a memory allocation error in BF2. Didn't make a blind bit of difference. Then I got another 2 512 sticks for £5!!  Now I have 2GB


----------



## Alec§taar (Nov 8, 2006)

Casheti said:


> I put a pagefile on my games partition once when I was getting a memory allocation error in BF2. Didn't make a blind bit of difference. Then I got another 2 512 sticks for £5!!  Now I have 2GB



THE ONLY THING YOU MIGHT GET BY MAKING A PAGEFILE.SYS PARTITION ON A SINGLE DISK, ARE THINGS LIKE:

*1.)* SAVING THE PAGEFILE.SYS SPACE FOR FILES TO LOAD FROM INSTEAD BY MOVING THEM CLOSER UP TO THE FRONT OF THE DISK AFTER DEFRAGGING (ASSUMES PAGEFILE.SYS WAS MID DATA) & PAGEFILE.SYS IS NOW ELSEWHERE ON DISK.

*2.)* NOT FRAGGING THE PAGEFILE.SYS ITSELF

*3.)* NOT FRAGGING OTHER FILES AROUND IT WHILE IT GROWS.

*4.)* IF PLACED OPTIMALLY FOR YOUR NEEDS/USE PATTERNS (THIS VARIES BECAUSE OF DATA VOLUME IF USING STD. METHODS, NOT IF USING MID-DISK PAGEFILE.SYS PARTITION PLACEMENT)?

* YOU MIGHT GET A SUPER-TINY DIFF. AS WELL ON PAGEFILE.SYS ACCESS INTERNALLY (but to keep std. methods optimal? You'd have to periodically move that pagefile.sys partition since data usually always grows & having only 1 hdd, you will be forced to contend w/ that & buy PQMagic too).

STILL:

*DO IT RIGHT, GET A 2ND HDD & PUT A PARTITION ON ITS OUTERMOST TRACKS FOR A 4GB PAGEFILE.SYS PARTITION/DRIVELETTER, & GET THE PERFORMANCE THAT WAY.

EDITING ON 11/16/2006: DOING PAGEFILE.SYS PLACEMENT ONTO ANOTHER DISKDRIVE WILL GET YOU ALL OF THE ABOVE ENUMERATED PERFORMANCE GAINS MENTIONED ON THE TOPIC OF THIS SUBJECT & FAR MORE ALSO I TERMS OF OVERALL PERFORMANCE GAINS.*

AND, since std. mechanical HDD's are pretty cheap, it makes good financial sense as well in terms of 'bang for the buck': For instance, I picked up a Samsung SpinPoint 250gb for $60 the other day... That IS truly, as of this date still a month later now, a great price.

(THERE IS ALSO THE METHOD I EMPLOY IN SOLID-STATE DISKDRIVE USAGE AS WELL. Today most folks will opt for std. mechanical hdd's vs. ssd's & rightfully so for cost + storage value price-per-mb/gb etc.)

APK


----------



## lemonadesoda (Nov 11, 2006)

Follow Alec$ tip. It's a good one. Since windows automatically allocates virtualmemory use across all the pagefiles it has available, you need to REMOVE the C: pagefile to get your optimisations.

However, if you remove C: pagefile you will lose you crashdump.  It's a Windows oddity. I personally NEVER analyse a crshdump, so I'm not bothered about losing it.


----------

