[DRBD-user] Significant write performance degredation LVM vs DRBD
m.watts at eris.qinetiq.com
Mon Jan 26 13:47:30 CET 2009
On Monday 26 January 2009 11:42:38 Florian Haas wrote:
> On 01/26/2009 12:28 PM, Mark Watts wrote:
> > On Friday 23 January 2009 18:13:55 Florian Haas wrote:
> >> Mark,
> >> On 01/23/2009 05:01 PM, Mark Watts wrote:
> >>> The following test was used to obtain a write average:
> >>> # for loop in `seq 1 10`; do echo "Writing to /empty, loop $loop"; dd
> >>> if=/dev/zero of=/empty bs=$(( 1024 * 1024 * 1024 )) count=4; done
> >> You're not writing to your disk, but to your page/buffer cache. Add
> >> "oflag=direct".
> > Ok. We've realised that we don't have the controller batteries either, so
> > we're going to get some and re-test.
> If that is the case, it may well be that your controller is disabling
> its write cache unless a battery is present (all sane controllers ought
> to have that behaviour). That would mean you are writing in
> write-through mode all along. So assuming that with "oflag=direct" your
> write throughput is way less than you expect, that may be a possible
Well, checking the raid config with the HP CLI utility, its saying that the
controller cache is providing 100%Read / 0%Write accelleration, so this will
probably improve with a battery. Looks like its disabled the caches on the
I'm still mildy confused why (without oflag=direct) the DRBD volume is so much
slower than the plain LVM volume. Is this because we're using Protocol C?
> > Yep, GigE here. Having said that, if everything else is capable/tuned of
> > going faster then we should be hitting 100M almost all the time, right?
> For direct streaming writes, yes. 100 to 105MB/s should be nothing out
> of the ordinary.
OK. The actual app is a mostly-write database (PostgreSQL) so we probably
won't be seeing sequential writes unless we're lucky.
Mark Watts BSc RHCE MBCS
Senior Systems Engineer
QinetiQ Applied Technologies
GPG Key: http://www.linux-corner.info/mwatts.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linbit.com/pipermail/drbd-user/attachments/20090126/e11f6a9b/attachment.pgp
More information about the drbd-user