Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 09/01/2010 06:29 PM, Robert Verspuy wrote: > *Latency: (changed to write 1000 times 4k)* > > DRBD Connected: > 4096000 bytes (4.1 MB) copied, 24.7744 seconds, 165 kB/s > > DRBD Disconneted: > 4096000 bytes (4.1 MB) copied, 0.198809 seconds, 20.6 MB/s > I've moved the meta-data to a ramdisk on both servers, but the latency is still the same. Also tried the deadline scheduler, enable / disable One other thing I saw was the amount of interrupts on de secondary server. The 8 SATA disks are connected to 2 sata controllers. During the latency test the amount of interrupts on the primary server on the sata_mv card is around 1170. on the secondary server on the sata_mv card is around 1804. On the primary server on the ahci card is around 376 On the secondary server on the ahci card is around 4308 So for the ahci driver I have about 10 times more interrupts on the secondary server, then on the primary server. I just tried to add the options no-disk-barrier, but no difference. When added no-disk-flushes, I suddenly got good performance numbers: So the extra latency is somewhere in the flushing part by drbd on the md device. But why is the flushing on the secondary much slower, compared to flushing on the primary? I also tested this with running db01 as primary, disconnected db02, and running the latency test on /dev/drbd0. I assume (because now I'm still writing to the drdb device but without active secondary), that drbd is still running the flushes on /dev/md2? Also tested this while making db02 primary, and db01 secondary, to see if there would be any raid problems on db02, but I get exactly the same results. When running the the latency test on the primary without secondary attached [root at db02 drbd]# cat /proc/drbd version: 8.3.8 (api:88/proto:86-94) GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild at builder10.centos.org, 2010-06-04 08:04:09 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown B r---- ns:4000 nr:4000 dw:12000 dr:0 al:1 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:4000 [root at db02 drbd]# dd if=/dev/zero of=/dev/drbd0 bs=4k count=1000 oflag=direct 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.205476 seconds, 19.9 MB/s With secondary arracted: [root at db02 drbd]# cat /proc/drbd version: 8.3.8 (api:88/proto:86-94) GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild at builder10.centos.org, 2010-06-04 08:04:09 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate B r---- ns:8000 nr:4000 dw:12000 dr:4000 al:1 bm:2 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0 [root at db02 drbd]# dd if=/dev/zero of=/dev/drbd0 bs=4k count=1000 oflag=direct 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 27.4238 seconds, 149 kB/s But when using Protocol C, and no-disk-barrier and no-disk-flushes, I get: [root at db01 drbd-test]# dd if=/dev/zero of=/dev/drbd0 bs=4k count=1000 oflag=direct 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.504855 seconds, 8.1 MB/s I also see according to dstat, that the 4.1 MBytes are saved to disk on the secondary within 2 seconds after the dd command. The documentaton states that you must not use no-disk-barrier and no-disk-flushes when you don't have a raid controller with battery backup. But is this really gonna give me problems? Both servers have 2 power supplies, attached to 2 power feeds in a data centre. So the change both servers will loose power at the same time is already very minimal. And even then both server loose power, the postgresql database is ACID, so there will always be a consistent data. Then I may have lost a few database updates / inserts, but we're not going to run a database for banking or a nuclear power reactor :) So I think I will setup DRBD with Protocol C and no-disk-barrier and no-disk-flushes. -- *Exa-Omicron* Patroonsweg 10 3892 DB Zeewolde Tel.: 088-OMICRON (66 427 66) http://www.exa-omicron.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100902/583095c9/attachment.htm>