On 7/26/2013 6:58 PM, Chris Knipe wrote:
The issue that we have identified is caused by seek time - hundreds of clients simultaneously searching for a single file. The only real way to explain this is to run 100 concurrent instances of bonnie++ doing random read/writes... Your disk utilization and disk latency essentially goes through the roof resulting in IO wait and insanely high load averages (we've seen it spike to over 150 on a 8-core Xeon - at which time the application (at a 40 load average already) stops processing requests to prevent the server crashing).
back in the day (many years ago) when I worked for IBM we had disk controllers that would queue and sort pending reads so that the heads would seek from low tracks across the disk to high tracks and then back to low. This resulted in very low seek _averages_. The controller was smart enough to make sure that if a write occurred, chronologically later reads got the right data, even if it had not been physically written to disk yet.
Is there such a controller available now? bill -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
