| Author |
EMC CX600 to combine spindles or not?
|
|
| themeanies 2005-02-22, 5:46 pm |
| I have a Win2K3 Server which runs SQL 2000. Attached to it are 7 LUNs.
In particular three of the LUNs are seeing 900-1200ms latencys in Read
and Write performance. All three of these LUNs are RAID1+0 4 spindles
per LUN 73GB 15K RPM FC disks.
What I've thought of doing is destroying all 3 LUNs and creating 1 big
12 disk RAID1+0. I'd then move all the data that was previously on the
three separate LUNs to this one 12 disk LUN. These disks currently hold
database data, logs and indexes respectively. Originally these were
designed to reduce contention, but the latency seems now to be more of a
penalty than the contention on one large drive.
Is there anything else I should consider here? Is this the wrong move
completely? Thanks for any input.
tM
| |
| oracle 2005-02-22, 5:46 pm |
| I would recommend you continue to keep your database and logs on seperate
luns as these will have differing I/O profiles. Databases are typically
random access whereas transaction logs are typically sequential.
Doing a little research on the filesystems can have a huge effect on
performance especially when it comes to the NTFS cluster size (block size).
Sizing the block size in conjunction with the underlying RAID-0 stripe unit
size can dramatically help. For example, Windows uses a default block size
of 4k when formating large filesystems. SQL server has a page size of 8k and
I believe it can transfer data in extents of 8 pages at a time. What this
equates to is the application making I/O requests in up to 64k chunks to an
underlying 4k based filesystem. This can introduce huge latency due to
massive I/O overhead. All of a sudden that single application I/O results in
up to 16 back-end I/O's. The net result is that you are generating a lot of
I/O and not doing much work. Increase I/O can increase the disk queue depth
and the avg. disk write time etc, subsequently driving up the latency
numbers.
Without knowing more about your database, whether its an OLTP or Dataware
application it's hard to identify the exact problem. From experience I've
found that tuning the filesystem can reap the greater benefit.
My recommendation, do the research before you change spread the I/O load
over more disks and effect performance on other systems.
Just my 2 cents.
Brian.
"themeanies" <themeanies@nowhere.net> wrote in message
news:111nblt74dfrbb8@corp.supernews.com...
>I have a Win2K3 Server which runs SQL 2000. Attached to it are 7 LUNs. In
>particular three of the LUNs are seeing 900-1200ms latencys in Read and
>Write performance. All three of these LUNs are RAID1+0 4 spindles per LUN
>73GB 15K RPM FC disks.
>
> What I've thought of doing is destroying all 3 LUNs and creating 1 big 12
> disk RAID1+0. I'd then move all the data that was previously on the three
> separate LUNs to this one 12 disk LUN. These disks currently hold
> database data, logs and indexes respectively. Originally these were
> designed to reduce contention, but the latency seems now to be more of a
> penalty than the contention on one large drive.
>
> Is there anything else I should consider here? Is this the wrong move
> completely? Thanks for any input.
>
> tM
| |
|
|
| themeanies 2005-02-23, 5:49 pm |
| oracle wrote:
> I would recommend you continue to keep your database and logs on seperate
> luns as these will have differing I/O profiles. Databases are typically
> random access whereas transaction logs are typically sequential.
You are probably right.
>
> Doing a little research on the filesystems can have a huge effect on
> performance especially when it comes to the NTFS cluster size (block size).
> Sizing the block size in conjunction with the underlying RAID-0 stripe unit
> size can dramatically help. For example, Windows uses a default block size
> of 4k when formating large filesystems. SQL server has a page size of 8k and
> I believe it can transfer data in extents of 8 pages at a time. What this
> equates to is the application making I/O requests in up to 64k chunks to an
> underlying 4k based filesystem. This can introduce huge latency due to
> massive I/O overhead. All of a sudden that single application I/O results in
> up to 16 back-end I/O's. The net result is that you are generating a lot of
> I/O and not doing much work. Increase I/O can increase the disk queue depth
> and the avg. disk write time etc, subsequently driving up the latency
> numbers.
I've got to look into this some more. Do you know of a way to tell what
the NTFS cluster size is on an already formatted disk? I have a couple
of spare disks that I'll bind and play with to see if I can get any
better performance out of them.
>
> Without knowing more about your database, whether its an OLTP or Dataware
> application it's hard to identify the exact problem. From experience I've
> found that tuning the filesystem can reap the greater benefit.
This server has 35 databases, all small except 1. The 1 large DB 120GB
mdf and 95GB ldf are one their own LUNs. This db also has many indexes
which are on their own LUN as well. tempdbx4 sits on it's own set of
spindles and the other 34 db's are on 2 LUNS. The big DB is OLTP, very
large transactions not like a shopping cart or banking transaction.
>
> My recommendation, do the research before you change spread the I/O load
> over more disks and effect performance on other systems.
>
> Just my 2 cents.
>
> Brian.
>
Thanks for your advice.
tM
| |
|
|
| Maxim S. Shatskih 2005-02-24, 7:45 am |
| > I've got to look into this some more. Do you know of a way to tell what
> the NTFS cluster size is on an already formatted disk?
CHKDSK will do.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
| Brian Purcell 2005-02-24, 5:45 pm |
| > This server has 35 databases, all small except 1. The 1 large DB 120GB
> mdf and 95GB ldf are one their own LUNs. This db also has many indexes
> which are on their own LUN as well. tempdbx4 sits on it's own set of
> spindles and the other 34 db's are on 2 LUNS. The big DB is OLTP, very
> large transactions not like a shopping cart or banking transaction.
>
If you're dealing with large I/O's try formating your NTFS filesystem with
64K blocks, see how it performs. You could then try slightly smaller at 32K
and compare.
It's very much trial-and-error.
Brian
| |
|
| What are your array cache settitings (read cache size write cache size, and
cache page size?)
for most windows apps, page size should be 8k, read cache 100MB, and all the
rest configured as write cache. (3072MB max).
"themeanies" <themeanies@nowhere.net> wrote in message
news:111nblt74dfrbb8@corp.supernews.com...
> I have a Win2K3 Server which runs SQL 2000. Attached to it are 7 LUNs.
> In particular three of the LUNs are seeing 900-1200ms latencys in Read
> and Write performance. All three of these LUNs are RAID1+0 4 spindles
> per LUN 73GB 15K RPM FC disks.
>
> What I've thought of doing is destroying all 3 LUNs and creating 1 big
> 12 disk RAID1+0. I'd then move all the data that was previously on the
> three separate LUNs to this one 12 disk LUN. These disks currently hold
> database data, logs and indexes respectively. Originally these were
> designed to reduce contention, but the latency seems now to be more of a
> penalty than the contention on one large drive.
>
> Is there anything else I should consider here? Is this the wrong move
> completely? Thanks for any input.
>
> tM
| |
| Neil Jowsey 2005-02-28, 5:46 pm |
| What did you use to measure the latency?
N.
[vbcol=seagreen]
> What are your array cache settitings (read cache size write cache
> size, and cache page size?)
>
> for most windows apps, page size should be 8k, read cache 100MB, and
> all the rest configured as write cache. (3072MB max).
>
>
> "themeanies" <themeanies@nowhere.net> wrote in message
> news:111nblt74dfrbb8@corp.supernews.com...
| |
|
| experience ;-)
"Neil Jowsey" <N.Jowsey@leeds.ac.uknospam> wrote in message
news:Xns960B9F749188NJowseyleedsacuk@129
.11.77.138...[vbcol=seagreen]
> What did you use to measure the latency?
>
> N.
>
| |
| themeanies 2005-03-01, 2:45 am |
| Cache page size is 8K. Each SP has 4GB Cache 128MB for Read, 512MB to
the SP Os and 2048MB to Write cache. I'm not able to allocate any more
than 2048 to the Write cache.
tM
Bruce wrote:
> What are your array cache settitings (read cache size write cache size, and
> cache page size?)
>
> for most windows apps, page size should be 8k, read cache 100MB, and all the
> rest configured as write cache. (3072MB max).
>
>
> "themeanies" <themeanies@nowhere.net> wrote in message
> news:111nblt74dfrbb8@corp.supernews.com...
>
>
>
>
----== Posted via webservertalk.com - Unlimited-Uncensored-Secure Usenet News==----
http://www.webservertalk.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| themeanies 2005-03-01, 2:45 am |
| win2K3 perfmon. Physical Disk\sec per Read and sec per Write.
Neil Jowsey wrote:[vbcol=seagreen]
> What did you use to measure the latency?
>
> N.
>
>
----== Posted via webservertalk.com - Unlimited-Uncensored-Secure Usenet News==----
http://www.webservertalk.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
|
|
|
|