Pagefile in RAID 0 very important for all of you , i think., setting u

[kitsun]

Hey guys,
My specs : q6600 3,0 ghz ; MB : striker extreme bios 1501 ; memory 4gb of ddr2 corsair XMS2; x2 8800 ultra sli ; HDD : maxtor 250 gb ( system) maxtor 350 gb (games films) maxtor 500 gb ( applications) ; 2x WD raptors raid 0 ( pagefile only)
I was wandering if someone could help with finding the 'right' issue for my raid 0 setup ;
I am a power gamer , specially LineAge II game . Since Im running 7-8 clients (windows) of this game a very big bunch of pagefile is required;
I am running windows XP 32k , so the largest ammount of physical memory i got is 3,5 gigs ( in bios shows 4gb)
It is not enough to 'complete' all of those needs that 7 Clients of LineAge ( gracia part 2 freeshard) requires.
Therefor i bought 2x WD Raptor . To make some raid 0 striping only for Page File
There is a problem with that. Since the single segment of a page is a 4kb file, how is it supposed to be splitted into 2 hard disks simultaneosly ?
The smallest stripe block size I can get from my bios raid setups is 4 kb
If there was a 8kb file , it would perfectly 'fit' the raid since 8kb can be greatly splitted into two 4kb parts so 2 HDDs could write those two 4kb files at the same time, this is called raid 0 perfomance key . Im a right ?
But since we got a 4kb pagefile segment size.. How would it fit the raid controller? no way !?
Please help me with undestanding those things . I found many ppl saying that pagefile runs better on raid 0 HDDs , but the question that remains to be answered is WHY ?
Thanks to all in advance , i will realy appreciate your help , im trying to solve this issue for 4 days, found many threads about ' stripe size VS block (cluster) size' , pagefile on a raid 0' .. but all that ppl are too wrong , they talk much but the information is useless.
The key words are : Pagefile running on raid 0 config . What stripe block size should i set up to run pagefile better ? and what about cluster size ? setting the raid for the best perfomance at operating small , 4 kb files.
thank you all again,

 

[geofelt]

The best solution to page file problems is to do less paging.
Ram is cheap, install a 64 bit os, and add 4gb.

For fast paging, a good slc ssd like the Intel X25-E might do the job well.

Otherwise a velociraptor might be best. Because of the small 2.5" form factor, and 10k rpm, the access time is about as good as it gets in conventional drives. I see little value in raid-0 which optimizes large sequential data transfers. If you bought a separate raid controller with a vary large cache buffer, you might do well also.

 

[kitsun]

Thank you much geofelt, but the question was about setting up a right stripe block size to run best pagefile on a raid 0 setup ( 2xRaptors ADFD 74 gb with 32 mb buffer )
I can not buy a solid state disk since i already spent 210 euros for two raptors
The point was to create a fast machine with high write read speeds, i got 2 Raptors
I want it to run ONLY pagefile ;
Thanks in advance,

 

[kitsun]

I can not install a 64bit OS to get more RAM because i got many programs with 32 bit architecture installed in my C:/
I know that the best solution to this would be running the 64bit OS with 8 gigs of RAM without pagefile at all.
But in my situation it is not a way out

 

[geofelt]

Many 32 bit programs will run very nicely together. The sum of the working sets is what the 8gb addresses. You will still need a page file because 7-8 tasks may well exceed 8gb.

Raid-0 is not your answer. Raid-0 gets it's performance by simultaneously writing stripes, overlapping the data transfer time. To get that savings, it must do two positioning operations instead of one. If positioning(seek + latency) time is large relative to data transfer time, it will take longer. A page write of a 4k page takes very little data transfer time.

To best utilize your hardware, I think the best you can do is to put a dedicated page file only on each of the raptors.

 

[sub mesa]

geofelt: that is only true if you choose a low stripesize so that two or more disks would be handling one virtual I/O. That will only increase MB/s (sequential operations) and not IOps. Since the seek times take up most of the time it takes to handle an I/O request, there is little benefit in choosing this strategy.

Instead, there is no good reason a stripesize cannot be as large as 1MB or 4MB. This would ensure that any virtual I/O request is handled by one disk, so other disks are ready to handle a second request simultaniously, which is much faster since both seek to a different sector and that will really speedup things.

Dumb RAID-engines will always read or write full stripes, which is rather silly since these are rather costly. But they make raw I/O performance tested like HDtune look better artificially, even though filesystems will always use read-ahead and can do this much more intelligently. A good RAID engine would allow smaller reads/writes than the stripesize. In that sense a stripesize can only be too low, since it should be equal to or larger than the size of the largest I/O (normally 128KiB). Also, a large stripesize would negate the performance penalty caused by stripe misalignment, which is common on all windows-based RAID-systems unless manually corrected, which only few people do or are even aware of.

In Linux and BSD, RAID potential can be exploited very efficiently, with IOps going up rapidly as more disks are added, and the scaling appears to be linear. In Windows, getting maximum performance out of your RAID is more complicated.

 

[jrst]

The 4KB memory page size is not the same as the size of paging I/O operations they *may* be the same, but larger I/O's are done wherever possible.

The size of those I/O's can vary tremendously. E.g., reads are typically done in clusters of at least 8 pages (32KB); writes will be coalesced into the maximum possible (which could be anywhere from 1 page (4KB) in the worst case, to as many pages as can be written in a single I/O. It's highly variable based on workload, and requires detailed run-time performance analysis.*

The simplest, easiest, and overall best performance is to spread paging files across as many disks as possible, then let Windows handle it. Windows will balance activity across those page files. Letting Windows see the physical disks (as opposed to hiding them in a RAID array), will also let it make more intelligent decisions.

Instead of trying to RAID 0 the Raptors, it would be better to:

1. Determine how much total space you need for paging = TPS.

2. Divide TPS by the number of drives N = DPS.

3. For each drive N:
a) Optional: Create a separate partition large enough for a file of size DFS; format the partition with a 64KB cluster size.
b) Create a page file of size DPS; fix the size, don't give it a range and let Windows allocate as-needed.

4. Reduce the size of the page file on your C: partition to the minimum (typically ~2MB if you want a minimal dump), or eliminate it completely.

5. Reboot.

6. Use the rest of the space on those drives for something else.

Optional: You have 5 physical disks including the Raptors. You might try using more than just the Raptors for paging. May help or hurt or not make much of a difference. If you'd do, ensure the pagefiles you create on those other drives are not fragmented.


* Edit: Writes to the page file occur for pages that are in memory and that have been modified (aka "dirty pages"). Reads from the page file are for those pages which have been previously modified and are no longer in memory. Pages which are read-only (e.g.,code) are not written to the page file but thrown away; cheaper to do that and read them from the source than write those read-only pages to the page file. While details differ, every modern VM-capable OS behaves in a similar fashion.

 

[jrst]

sub mesa -- Not to go too far OT, but I think you'll find the "whole stripe" and alignment issues are limited primarily to fakeraid RAID 5, as RAID 5 requires a read-modify-write (except when whole stripes are written), whereas RAID 0 and RAID 1 do not.

That said, I agree that fakeraid generally sucks, and may be worse than non-RAID, even for RAID 0 or RAID 1 if it doesn't properly exploit the parallelism of multiple disks. (Some do an OK job of optimizing transfer rates, and as you said look good on some benchmarks; anything else seems to be too much for them.)

 

[specialk90]

Just to add my 2 cents: the alignment issue was fixed starting with Vista because Vista now uses 2048kb default for the beginning. Forgive me as I don't recall the exact terms but there are many tests online.

The alignment issue does exist for Raid 1 and 10 according to a very in-depth article.
http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-series.html

The term I was looking for is "Partition Offset". The above article is great and actually can leave you more confused than before reading it.

 

[kitsun]

thank you guys, i will do something right now , the best idea was to split arround the pagefile across 2 or 3 hdds instead of setting them up for a raid 0

 

[sub mesa]

Alignment plays no role in RAID1 situations, where there is no stripesize. Only if the implementation treats it as a RAID0 when reading, which only few implementations do, may it be affected by a misalignment. The best most RAID1 engines can do is 'round-robin': a scheme that interleaves the I/O between the two disks in a mirror.

specialk90 is correct though, it seems Vista partitions with 2048 offset sectors, being a 1MiB (1024*1024) offset, which is compatible with any stripesize up to 1MiB. For 4-disk RAID5's this might not be enough, since 1MiB/3 would not compute to any usable stripesize. However, the misalignment will be gone for any casual RAID0 or RAID 0+1/1+0 systems.

Unfortunately, many people are still using Windows XP, which is still doing things the old way (63 sectors meaning a 31.5KiB offset, the worst possible offset because all stripes with any stripesize are going to be misaligned). You can correct this manually with BartPE and other tool collections, but migrating to Vista or Windows 7 might be easier. Be sure to wipe the disk and let Vista/W7 create the partition table itself, or it may decide to keep the misalignment due to compatibility reasons.