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
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?