> We're using PERC 6/i with 4 x 10k 2.5" 146GB drives in RAID10. > > I currently do a straight-forward CentOS install onto the logical > drive, > creating two partitions, one small one for /boot and the other across > the rest of the disk which I make an lvm PV and slice it up using lvm. > > The main performance bottleneck for us is write performance for MySQL. > > Could I get better performance by doing things differently?
With only 4 spindles, there isn't necessarily a lot you can do in terms of physical configuration of the RAID array. (other than RAID-0, but I assume you care about redundancy) There are some software configuration changes that might gain you something. Some things to consider are: type of file system, the mount options for those file system, and using the 'noop' i/o scheduler over the 'cfq' default. Although it doesn't apply for most databases, write-through is *sometimes* faster than write-back for really, really large sequential writes. I/O tuning for MySQL databases is a pretty involved process with many factors to consider, which result in different I/O requirements. E.g., in some applications, InnoDB tables prefer sequential I/O over random I/O performance due to transaction logging and re-ordering which in a way takes the random I/O patterns and streamlines some of it into sequential I/O patterns; in these cases the conventional rule-of-thumb of preferring random I/O performance for databases doesn't apply. You'll need to consider how the "write performance bottleneck" is coming about. Is it simply due to a lot of write queries or transactions? Or, are the writes due to large joins that are creating really large temporary tables? In the later case, you can create a really fast partition and use it exclusively for MySQL's temp space. Some approaches include using tmpfs (if you have enough extra memory), SSDs(SLC variety), and mounting with ext2 instead of a journaling file system (all else being equal, ext2 usually outperforms in writes over ext3,xfs,jfs,rfs). It's important to find the "cause" of the write performance bottleneck, and then figure out how to tackle that specific issue. Sometimes, using 'mytop' and 'iotop' can help correlate which specific query results in the I/O bottleneck. Sometimes it is even possible to address the problem by simply re-designing the query. In some cases, a complicated JOIN in the databases is less efficient than doing it within the application; so adding a little more code in the application can result in better performance (i've seen examples of something like this that resulted in 12x faster performance). Hope that gives you some ideas... -Bond _______________________________________________ Linux-PowerEdge mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/linux-poweredge Please read the FAQ at http://lists.us.dell.com/faq
