Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, I've been having a problem with performance of DRBD while the secondary is connected, and I've tried various things (which have helped) but not resolved the issue. So last night I upgraded to DRBD 8.3.15 and have been running with that for the past 6 hours or so. I also enabled the option: on-congestion pull-ahead; and changed my protocol to A (because I couldn't enable that option otherwise). Since then, I've received the following log messages: Dec 20 08:16:57 san1 kernel: [1235131.854167] block drbd2: Congestion-extents threshold reached Dec 20 08:16:57 san1 kernel: [1235131.854172] block drbd2: conn( Connected -> Ahead ) pdsk( UpToDate -> Consistent ) Dec 20 08:17:00 san1 kernel: [1235134.535128] block drbd2: helper command: /sbin/drbdadm before-resync-source minor-2 Dec 20 08:17:00 san1 kernel: [1235134.536144] block drbd2: helper command: /sbin/drbdadm before-resync-source minor-2 exit code 0 (0x0) Dec 20 08:17:00 san1 kernel: [1235134.536148] block drbd2: conn( Ahead -> SyncSource ) pdsk( Consistent -> Inconsistent ) Dec 20 08:17:00 san1 kernel: [1235134.536151] block drbd2: Began resync as SyncSource (will sync 8756 KB [2189 bits set]). Dec 20 08:17:00 san1 kernel: [1235134.543422] block drbd2: updated sync UUID 75FEFEE50FF154E9:59B7F817FEF13BD6:8E57A8552E6B2153:8E56A8552E6B2153 Dec 20 08:17:01 san1 kernel: [1235135.764082] block drbd2: Resync done (total 1 sec; paused 0 sec; 8756 K/sec) Dec 20 08:17:01 san1 kernel: [1235135.764086] block drbd2: updated UUIDs 75FEFEE50FF154E9:0000000000000000:59B7F817FEF13BD6:8E57A8552E6B2153 Dec 20 08:17:01 san1 kernel: [1235135.764091] block drbd2: conn( SyncSource -> Connected ) pdsk( Inconsistent -> UpToDate ) Dec 20 08:17:01 san1 kernel: [1235135.828036] block drbd2: bitmap WRITE of 0 pages took 0 jiffies Dec 20 08:17:01 san1 kernel: [1235135.828038] block drbd2: 0 KB (0 bits) marked out-of-sync by on disk bit-map. How might I read this information to determine what the shortfall in performance is? It would look like there was some blocks (or portions of blocks) total 8756KB that the secondary fell behind on. This doesn't seem like a lot to fall behind, and considering that everything was caught up again in around 4 seconds. Is there perhaps some additional buffering or tuning I could do within DRBD (or on the secondary) to allow an additional 16M worth of buffering available? Of course, the above is just one instance of falling behind, and if it happens frequently enough, or by a large enough value, then the only solution will be to upgrade the hardware in the machine. However, if it is only falling behind by small amount then I'd rather just increase the buffering a bit. Regards, Adam -- Adam Goryachev Website Managers www.websitemanagers.com.au