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, Oct 21, 2008 at 5:56 AM, Peter Sabaini <peter at sabaini.at> wrote: > On Tuesday 21 October 2008 11:14:52 Bart Coninckx wrote: >> > On Sat, Oct 18, 2008 at 09:18:33PM +0200, Petersen, Joerg wrote: >> > > Well, my experience is that 8.0.7 is the fastest DRDB... >> > > Later Versions just got slower! >> > > Try: no-disk-flushes >> > > and: no-md-flushes >> > > if you are using DRBD >= 8.0.13 >> > > Not completely same to 8.0.7 but near to it... >> > >> > to recommend a known buggy version for imagined performance reasons is >> > not particular HA. >> > >> > > Hi Lars, >> > > >> > > I did these: >> > > >> > > node1:/opt # hdparm -t /dev/drbd0 >> > > >> > > Do these tests make any sence? >> > >> > if you care for write performance, >> > why are you doing read benchmarks? >> >> These are the only benchmarks I know how to do on both DRBD and non-DRBD >> partitions without destroying data. >> >> I actually care for both read and write performance obviously, since users >> will be both reading and writing I guess (file and mailserver). >> >> What I just did is copying a 2.5 GB file to different locations. Mind you, >> the file is on the same harddrive (on /). These are the results: >> >> >> to ext3 filesystem on /dev/drbd0: 17MB/sec >> to /opt (on the same LVM VG as drbd0): 20 MB/sec >> to / (non LVM, non DRBD): 24 MB/sec >> >> So it seems there is a slight performance drop for DRBD, but the overall >> performance is not that good. >> >> What is striking though, is that a scp to the other node results in a >> performance of about 60 MB/sec. >> >> Is there any logical explanation for this? Is this because of my copy tests >> read and write to the same drive? Can this explain the drop from about 60 >> MB/sec to about 20 MB/sec? > > Probably. > > I found it important to make very sure you know exactly what you are measuring > before doing any test. In order to do this, try to measure isolated facts. > > Eg. to make certain you're measuring only read or write performance, > use /dev/zero as a data source, respectively /dev/null as a target to > eliminate interaction between parameters. > Recent versions of opensuse have a performance bug in /dev/zero, so even that can cause a misleadingly low result. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com