Before investing time in MySQL tweaks/settings -- properly configuring your I/O subsystem is key.
Regardless of underlying filesystem, if you write to many separate tables sequentially, you'll end up with disk fragmentation. Extent based allocation, and pre-alloc patches can serve to help, but increasing sequential disk accesses is critical.
If you're brave, one evil solution could be to place each table on its own partition.
A few other solutions:
1) noatime - a MUST
2) nodiratime - a MUST
3) turn off dir_index (ext3)
4) data=writeback if you have a battery backed RAID controller
5) Get your stride, RAID stripe, OS Page, and Database Page sizes aligned right. This is of huge importance.
6) Use memory/caches/anything to migrate your disks to sequential I/O. Prevent the head from seeking and you can improve throughput.
7) RAID10. One of my first databases utilized RAID6. The overhead regarding writes was abysmal.
8) RAID-N -- Have a hot spare. You don't want rebuilding to wait until you get around to finding a replacement drive.
9) RAID Controller - If you have a split Read/Write cache, allocate as much memory as possible to writes. If you have contiguous blocks, reads can be quick even if you have a cache miss.
10) Memory caching - Linux allows you to tune the dirty memory ratio. Do it! Standard installations are tuned towards desktop / OLTP servers.
11) Swappiness - Oh the religious debate this creates... Do you want your memory allocated for the application/database/data caching, or used so that the guy with a 8hr stale SSH session can have snappy performance?
Wednesday, August 13, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment