Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Jun 12, 2007 at 12:17:52PM -0700, Ben wrote: > On Jun 12, 2007, at 11:34 AM, Lars Ellenberg wrote: > > >whether or not the tcp buffer fills up or not does not change things. > >in this case the tcp buffer does only what it was supposed to do, > >smooth the tcp stuff. having a larger buffer (which, depending on your > >actual network performance may never fill up) cannot possibly increase > >latency? > > Doh. Of course. Thanks for point out the obvious to me. :) > > >>>>3. What's a reasonable formula for determining max-buffers? Does > >>>>increasing them imply I should increase something else too? > > > >if you tune it too small, io will throttle on it. > >to not thottle here, it should be larger than the maximum expected > >amount of in-flight io (io requests submitted but not yet completed). > > I see. I don't suppose there happens to be a way to see what my in- > flight io high/average watermark currently is? to get a rough estimate, use (disk throughput) * (average-to-max latency) the default of 2048 @ 4k -> 8M is sufficient to saturate a of-the-shelf single disk, even when assuming some worst case latency of ~100ms 70 MByte/sec * 100 ms -> 7MB most of the time only a fraction of that should be used. btw, this is only interessting for the secondary side, mostly. you also can monitor the "lo:" values in /proc/drbd on both nodes, or the "ap:" value on the Primary, an see whether you can find a maximum... -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.