| Author |
San Performace with SQl Server
|
|
| saradhi 2005-08-25, 7:46 am |
| hi everyone,
Am presenlty Testing the I/o performance on the new CX-500 San From Emc
And Hba From Emulex,The LUn Size is 1 TB and when doing the Testing
with SQlIO Tool with a I/o block size-8 i get 39.3
MB/sec for Random write requestes but when doing the same with Random
Read
requests i get 6.04 MB/sec as the output,the read/Write cache is
enabled with read cache set to 288 and write to 1198,We have a
sqlserver Oltp Enviroment with mostlty Read Intensive Operations , iam
wonering how can i increase the Read i/o ,The Lun design looks bad we
should have made smaller Luns and Shared the Data and Log Files among
them ,will i get any performance if i set read cache to low value or
turn off the read cache or should i recomend to rebuild the san design
to smaller chunks , i am not so well versed in san
design , what i want is best perfromance for my sql serverr IO ,Pls
Suggest
Thanks,
Saradhi
| |
| victor.engle@gmail.com 2005-08-26, 5:48 pm |
| Saradhi,
The problem is most likely read cache as you suspect. The cx500 is a
midrange array and has limitations with regards to cache and i.o paths.
You can probably improve i/o performance for random reads by using
mirrored raid groups rather than raid-5. 2D+2D is probably what you
want for performance sensitive requirements including your logs.
Regarding smaller luns, you probably can get more performance with them
if you're carefull about how you assign the luns to the host. For
example you would get good performance if you have 5 2d+2d raidgroups
and you create a 36G lun from each and assign them to your host then
stripe the luns on the host side. In that configuration you would have
20 spindles powering your volume. If that methodology is followed for
all storage allocations you would maximize your array's performance and
reduce hot spots etc.
I don't think I would change your cache configuration. If you use any
raid-5 then you really need to keep all that write cache.
Regards,
Vic Engle
| |
| saradhi 2005-08-26, 5:48 pm |
| We Have Raid 10 On our San ,do you think using raid 10 the stats look
very bad for random IO with your experience
and with raid 10 what cache settings are better for a OLTp environment
Thanks,
Saradhi
| |
| victor.engle@gmail.com 2005-08-26, 5:48 pm |
| Those stats do look poor for raid-1+0. I think I would consider more
read cache in that case. Also I would review the raid set
configuration. If you have large raid sets you may not be using read
cache effectively because large stripes may be read into cache for
small random reads which are expected with oltp. This sort of pollutes
your read cache with unnecessary data. Are your raid groups using
larger sets than 2D+2D? If so, consider a relayout where you're using
mostly 2d+2d.
Regards,
Vic Engle
| |
| saradhi 2005-08-26, 5:48 pm |
| I think we have 4D+4D Raid Group sets ,In this Situtation what is the
best Setting For the Read Cache for our Hba Emulex(2GB)
>From the Present Config
Thanks,
Saradhi
| |
| victor.engle@gmail.com 2005-08-26, 5:48 pm |
| Saradhi,
I think 4d+4d will yeild very good sequential read/write performance
but for random read/write I think the stripe size become more of an
issue with mores disks in the stripe. So 2d+2d may be better for random
read/write. If your disk I/O is characterized as primarily random read
with maybe 10-15% random write then I would configure more read cache.
Vic
| |
|
| A few suggestions for tuning a Clariion Array.
1. Hopefully you licensed Navi Analyzer. (If you are serious about tuning a
Clariion Array you need this tool.)
2. The best document to start with is EMC CLARiiON Best Practices for Fibre
Channel Storage. (If you have a powerlink account you should be able to get
this document.)
3. The EMC Annual technical conference has several good presentations on
performance. (Ask for any presentation by Dave Zeryck or Bruce Zimmerman.)
| |
| fenderelectric@yahoo.com 2005-08-31, 5:53 pm |
| PLEASE do what GG says, the previous poster (Victor) may mean well but
he's way off base here - nothing he has said makes sense with regard to
the CX. More Read cache won't help -- you have the cache set up just
fine -- don't worry about stripe sizes, pay attettion to how many
disks you are getting busy,
If the IOPS don't make sense then pay more attention to the host
queues.
You should get about 120 IOPS per disk, if they are small IO then your
MB/s value won't be very high, multiply IOPS * IO size, you can work it
out yourself.
ASssuming 4 KB IO that 6 MB/s is about 1500 IOPS, what you'd expect
form about 12 drives working pretty hard.
You got more IOPS from writes as the response time of a write is very
short, the CX500 caches those of course, versus a read which is limited
by disk speed.
There is another paper on Powerlink "EMC CLARiiON Fibre Channel
Fundamentals" you might want to start with that.
| |
| victor.engle@gmail.com 2005-09-01, 5:51 pm |
| With regard to the array's cache aren't we more interested in IOPS that
the port is capable of. I know that Hitachi array ports are capable of
about 5000IOPS and I assumed the same was likely true of the clariion.
It really only makes sense to me to start calculating performance of
physical disks if you've more or less given up on improving performance
by maximizing hits from read cache. Also assuming that every IO is a
single disk block is extremely unlikely even for OLTP apps.
| |
| fenderelectric@yahoo.com 2005-09-01, 5:51 pm |
| Victor - in open systems most of the re-reads hit host buffers. Read
cache in midrange systems is used primarily for read-ahead. Random
reads *do* depend almost solely on the disk performance. The CX ports
can do about 40,000 IOPS each. I don't think we're hitting the limit
here :-)
Just check out the "marketing" IOPS numbers and divide by number of
ports.
For real-world performance, the CX performance papers in Powerlink have
more realistic workloads. If you don't have access to Powerlink then I
assume you don't own a CLARiiON, and if you do not own one I cannot see
how you can comment on their characteristics or performance.
| |
| victor.engle@gmail.com 2005-09-02, 7:46 am |
| Thanks Fender, I know what marketing numbers are. When I mention 5000
IOPS I mean that through performance monitoring I know that host's disk
performance become degraded when an array port begins to exceed 5000
IOPS in real world conditions. 40000 IOPS per port is only possible in
a lab. I do have access to Powerlink but I'll admit that my
responsibilities are primarily Hitachi enterprise class arrays so I am
by no means a clariion performance expert.
I do think that your advice to the Saradhi to research performance on
Powerlink is actually very good advice. My comments are based on
several years of storage and open systems experience and are intended
to be helpfull and contribute to the discussion since this is a
discussion group.
|
|
|
|