The EVA8000 with a disk group of 70 spindles (are they 10k or 15k) is not all that fast. You find out what your real I/O limit is by doing a
dd oflag=direct if=/dev/zero of=/path/to/san/mount/test bs=1k count=100000 which will bypass the fs cache. Watch from another terminal with 'vmstat 1' and note the 'bo' values. this is the physical limit that your san config can ingest. That's how I start. From there, you can tune the vm level stuff depending on your io patterns etc. due to thw way the EVA does it's thing 70 spindles is not optimal and best practice for db's on an eva is a seperate disk group. not practical usually but if you can swing it, that much the better. If you, or someone else is running any disk intensive tasks at the same time on that disk group, thats likely the problem. Don't ask the db guy/gal, ask the storage guy/gal. They'll have the tools to track I/O at the fibre and san level and be able to tell who is using what and when. You might find in the end that an dual bus msa30 via a 6402 hp raid card , or msa70 via a P800 outperforms the san by leaps and bounds. I can write 600+ MB to an msa70+P800 all day long with raid, 450MB on raid 5. The san is limited it's IO link, your fiber Also, if this is a high vis app/db, request your storage be allocated as a vraid 1 instead, or even two vraid 0's across two disk groups and software raid 1 them at the host. Hope this helps Corey On Thu, Jul 23, 2009 at 8:32 AM, Mohd Irwan Jamaluddin <[email protected]>wrote: > On Tue, Jul 21, 2009 at 3:37 AM, Anthony Lopez<[email protected]> wrote: > > I have seen something similar and agree it that MySQL is the likely > > culprit. Turning on the slow query log in MySQL may show you some of the > > queries that are taking long but once they start stacking up then > > everything winds up slow and going into the log. Make sure to run the > > explain plan on all your queries and analyze them carefully. A few > > months back we restarted a mysql instance without changing anything and > > I/O went through the roof. Running explain looked ok but when our DBA > > grouped up with the app developer they figured out the mysql wasn't > > taking the best path to retrieving the data. They modified the query > > and load went back to normal. > > > > Thanks for sharing your experience. Unfortunately, I'm not the MySQL > Admin for this server. Do you have any advice that I could talk to > MySQL Admin in order for them to fine-tune their side? > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list >
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
