Performance depends entirely on what you are doing and how you are doing it.
What is writing to the disk? DB, Files, buffer stream?
Who is doing the writing? (with as much detail as possible, down to
the application framework if you know it)
How is that data being used?
How much total data is being write in a full productivity cycle?
What does the peek and trough of that cycle look like?
Repeat the questions above for reads.
Only then can you talk about reducing I/O. Other wise I am going to
say get a few high quality Sata 6 raid card with fat cache and do raid
0 - OR switch everything over to flash drives and pay the 1990's
storage prices :)
On Fri, Oct 1, 2010 at 6:23 AM, Alex Dean <
alex@crackpot.org> wrote:
>
> On Oct 1, 2010, at 3:32 AM, der.hans wrote:
>
>> Am 30. Sep, 2010 schwätzte Eric Shubert so:
>>
>>> Which elevator is being used?
>>> (cat /sys/block/sda/queue/scheduler)
>>
>> noop anticipatory deadline [cfq]
>>
>>> Using async i/o? Synchronous writes are very slow.
>>
>> Hmm, not familiar with libaio. Looks like we have it installed.
>>
>>> I presume ext3, since you referred to noatime. If you have directories with many files (e.g. Maildir), dir_index option can help.
>>
>> Yeah, ext3. Mostly it's a few DB files and some log files. No mail
>> directories.
>
> FWIW: A few years ago, I recall seeing somewhat-improved benchmark performance from MySQL after switching to the deadline scheduler.
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)