On Sat, Jun 8, 2013 at 10:00 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>> But I have neither any firsthand experience nor any
>> empirical reason to presume that the write limit needs to be lower
>> when the read-rate is high.
>
> No argument from me that that this is an uncommon issue. Before getting
> into an example, I should highlight this is only an efficiency issue to me.
> If I can't blend the two rates together, what I'll have to do is set both
> read and write individually to lower values than I can right now. That's
> not terrible; I don't actually have a problem with that form of UI
> refactoring. I just need separate read and write limits of *some* form. If
> everyone thinks it's cleaner to give two direct limit knobs and eliminate
> the concept of multipliers and coupling, that's a reasonable refactoring.
> It just isn't the easiest change from what's there now, and that's what I
> was trying to push through before.
OK, understood. Let's see what others have to say.
> On the throughput graph, + values above the axis are write throughput, while
> - ones are reads. It's subtle, but during the periods where the writes are
> heavy, the read I/O the server can support to the same drive drops too.
> Compare 6:00 (low writes, high reads) to 12:00 (high writes, low reads).
> When writes rise, it can't quite support the same read throughput anymore.
> This isn't that surprising on a system where reads cost more than writes do.
That is indeed quite a surprising system, but I'm having trouble
seeing the effect you're referring to, because it looks to me like a
lot of the read peaks correspond to write peaks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company