cluster size and performance

[Bob]

Archived from groups: microsoft.public.win2000.file_system (More info?)

I have a programmer on my staff who is giving me difficulties.

we have a database server (progress), win2000 sp4, quad processor, 4gb ram,
raid 0+1 (3 drives stripe set, mirrored) with 4k default cluster size.

this server's disk I/O performance is abysmal.

First, the guy argues that there's any value to defragging (he think's there
is none).

second, i mentioned since we are using a db application that supports 8k or
greater cluster sizes, that we should consider increasing the cluster size
on the volume.

so here's my delimma. I need to find an article to PROVE to him that larger
cluster sizes CAN have a performance increase in situations like this.

does any one have any links on articles about cluster size and performance?

i tried googling, and all i can come up with is just generic or non specific
info. In other words, they say that increasing cluster size COULD increase
performance for large file size (multimedia, database). but none of them
actually PROVE it.

i need to find a doc that i can show him to stuff up his littlee...uh...you
get the picture.

anyways, i suggested we take and do an in house performance test: setup a
test server, 4k clusters, benchmark. set to 8/16k cluster size, benchmark,
compare. he thinks it is a waste of time (mainly because it might prove that
I know what i'm talking about).

anyways, i've since learned that this guy won't take my word for it no
matter what I say. so i have to find a documented expert source to prove it.

i searched MS's kb. couldn't find anything.

i'm so desperate to prove to this guy that my suggestion to increase cluster
size could help us with Disk i/o. (i've done enough perfmonning to
demonstrate clearly it's not processor, memory, network. it's disk).

we've got a 7gb database that can be set to 8/16k cluster sizess. i
suggested we set the file system volume to 16/32/64, set the db
approproately and give it a real world test.

he's not interested.

so....i have to find a reputable whitepaper / source that clearly shows
larger cluster size in a db / ntfs file environment could help improve
cluster size.

if i'm wrong, then i've learned something. it seems to me that if a db has
to read several pages of data 4k at a time, rather than 64k at a time, that
we are not being efficient. it seems to me that if we could utilize larger
clusters, it'd be a potential boost to disk performance.

help me either 1) prove i'm wrong, or 2) help me get him to see the light. I
hate situations like this. but i guess it's real world. they don't want to
take my word for it. fine.

HELP! I'm an IT Pro in distress who's being told he doesn't have a clue!
help me find the clue!

 

[Guest]

Archived from groups: microsoft.public.win2000.file_system (More info?)

Some folks just don't want to listen to reason.

Here is a pdf concerning raid and defrag
http://www.raxco.com/products/perfectdisk2k/whitepapers/pd_raid.pdf


"bob" wrote:

> raid 0+1 (3 drives stripe set, mirrored) with 4k default cluster size.
This concerns me since 0+1 would be 4 drives minimum. My 0+1 is 6 drives
with one hot spare. Hot spare is VERY important in 0+1 since the loss of a
single drive reduces the raid level to 0.
See here
http://www.acnc.com/04_01_0_1.html

Might want to look at the array and its configuration. Ideally you split
this across two channels thereby reducing the bus contention between
different disk requests. I use two channel raid cards for this.

Here is something on database block size
http://www.ixora.com.au/tips/block_size.htm

MS SQL recommendation for 16K blocks
http://www.ctlcorp.com/support/sql/admin.html
though it looks like with MS SQL 8k is default
http://www.wilsonmar.com/1sql.htm

Here is some more page size advice
http://www.sleepycat.com/docs/gsg/C/dbconfig.html#pagesizeAdvice

From my Google read I get that with databases you can use larger pages
depending on the database manufacturer. It really is a simple matter of
math. If you know what the block size that is being written then you know an
even increment of that number will be a good disk block size. It is also
clear that if you have a 32K write that 4K blocks means 8 writes and most
likely not contiguous. Whereas that same write to a 32K disk block is a
single write. It doesn't take a rocket scientist to figure out which is
faster: 8 writes vs. 1 write.

It appears to be that you can adjust the page size used by the database and
then match that with the disk block size from my reads but I can't find the
magic number. The magic number is in what increments is the disk written to.

For example Ms page file ops in memory is done in 4K increments. But when
writing from memory to the disk it’s done in 64K increments. So 64K blocks
are ideal for page file operations and not 4K ones

 

[Guest]

Archived from groups: microsoft.public.win2000.file_system (More info?)

Optimizing NTFS Performance
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_punq.asp

Optimizing NTFS
http://www.microsoft.com/technet/archive/winntas/tips/winntmag/optntfs.mspx

Note: The first article is written for XP and the second one for NT.
Keep in mind that the NTFS versions are different for all (NT,W2K & XP)
syetems so results may vary.

John

bob wrote:

> I have a programmer on my staff who is giving me difficulties.
>
> we have a database server (progress), win2000 sp4, quad processor, 4gb ram,
> raid 0+1 (3 drives stripe set, mirrored) with 4k default cluster size.
>
> this server's disk I/O performance is abysmal.
>
> First, the guy argues that there's any value to defragging (he think's there
> is none).
>
> second, i mentioned since we are using a db application that supports 8k or
> greater cluster sizes, that we should consider increasing the cluster size
> on the volume.
>
> so here's my delimma. I need to find an article to PROVE to him that larger
> cluster sizes CAN have a performance increase in situations like this.
>
> does any one have any links on articles about cluster size and performance?
>
> i tried googling, and all i can come up with is just generic or non specific
> info. In other words, they say that increasing cluster size COULD increase
> performance for large file size (multimedia, database). but none of them
> actually PROVE it.
>
> i need to find a doc that i can show him to stuff up his littlee...uh...you
> get the picture.
>
> anyways, i suggested we take and do an in house performance test: setup a
> test server, 4k clusters, benchmark. set to 8/16k cluster size, benchmark,
> compare. he thinks it is a waste of time (mainly because it might prove that
> I know what i'm talking about).
>
> anyways, i've since learned that this guy won't take my word for it no
> matter what I say. so i have to find a documented expert source to prove it.
>
> i searched MS's kb. couldn't find anything.
>
> i'm so desperate to prove to this guy that my suggestion to increase cluster
> size could help us with Disk i/o. (i've done enough perfmonning to
> demonstrate clearly it's not processor, memory, network. it's disk).
>
> we've got a 7gb database that can be set to 8/16k cluster sizess. i
> suggested we set the file system volume to 16/32/64, set the db
> approproately and give it a real world test.
>
> he's not interested.
>
> so....i have to find a reputable whitepaper / source that clearly shows
> larger cluster size in a db / ntfs file environment could help improve
> cluster size.
>
> if i'm wrong, then i've learned something. it seems to me that if a db has
> to read several pages of data 4k at a time, rather than 64k at a time, that
> we are not being efficient. it seems to me that if we could utilize larger
> clusters, it'd be a potential boost to disk performance.
>
> help me either 1) prove i'm wrong, or 2) help me get him to see the light. I
> hate situations like this. but i guess it's real world. they don't want to
> take my word for it. fine.
>
> HELP! I'm an IT Pro in distress who's being told he doesn't have a clue!
> help me find the clue!
>
>
>
>