Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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. You could even try to establish a baseline by copying bits from /dev/zero to /dev/null ; if you kernel doesn't have any problems this should be pretty fast, eg.: % dd if=/dev/zero of=/dev/null bs=1M count=100000 oflag=sync 100000+0 records in 100000+0 records out 104857600000 bytes (105 GB) copied, 2.16213 seconds, 48.5 GB/s (thats on my work box, note that this number varies probably wildly depending what other tasks are running) Then do the same with a naked partition (if youve got some free space), an LVM partition, an LVM partition with a filesystem and finally a DRBD partition (assuming you're certain that your network is flawless; if not you should test your network separately). This should give you some hints where your performance is lost. Hope this helps, peter. > > Thank you. > > > Bart > > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user -- http://sabaini.at