2

I have a simple, not quite so simple question: why the heck is protocol A slower than B and C in my setup? I mean, I've been stuck on this for over a week now, tried "all" the configurations, played with max-buffers max-epoch-size, sndbuf-size, rcvbuf-size, etc etc.

I understand that Protocol A doesn't need to wait for the data to reach the other node whatsoever, Protocol B considers the write done as soon as it reaches it, and C only when its written in the second node. So, basically, its supposed to go like that in terms of speed: A > B > C, right?

Also I understand the buffer/cache matter, that at some point, protocol B, and mostly A, loses performance due to full use of cache, so that the "stack" becomes congested. Therefore, a big amount of writes (larger ones, mostly) is supposed to make it slower. I ran a serious amount of tests, benchmarked it with hdparm, dd, bonnie++, iozone (a whole bunch of sheets, days of work) and it still doesnt make sense; even the small files/writes gets slower with Protocol A and B.

Can anybody help me make it go as its supposed to?

Thank you all.

Both servers with Debian 9 fresh installed. DRBD working with LVM. global_common.conf as it follows (played with some of the commented itens)

  global {
    usage-count no;
    # minor-count dialog-refresh disable-ip-verification
    # cmd-timeout-short 5; cmd-timeout-medium 121; cmd-timeout-long 600;
}

common {

     syncer {
        #rate 10M;
            # "hot area" aumenta o tiempo de resync pmas diminui os updates nos metadados
        # area pequena synca mais rapido mas a replicação fica mais lenta
        #al-extents 65533; #maximo
    }


    handlers {
        #Cria snapshot automaticamente assim que uma sincronização é iniciada
        #before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh";
        #remove o snapshot em caso de sucesso na resync
                #after-resync-target "/usr/lib/drbd/unsnapshot-resync-target-lvm.sh";
        # a reversão é um snapshot comum: lvconvert -M
    }

    startup {

        #wfc-timeout 0;
        #degr-wfc-timeout 15;
    }   

    options {

    }

    disk {
        #on-io-error detach;    

    }

    net {
        protocol C;

        #sndbuf-size          8000k;
        #rcvbuf-size          8000k;
            #timeout                   60;
            #connect-int               10;
            #ping-int                  10;
            #ping-timeout               5;
            #max-buffers                20000;
            #max-epoch-size             20000;
            #cram-hmac-alg         "sha1";
            #shared-secret  "appname-drbd";

    }
}
Jhonatan Cruz
  • 21
  • 1
  • Can you share your resource configurations? The resource configuration for your Protocol A testing and your Protocol C testing should be good enough. – Matt Kereczman Jun 12 '18 at 14:20
  • Hi, thanks for answering. All my configuration is on the global file, I have no especific configuration on my resource. Right now I have no access to it, but it only contains my DRBD device, the /dev/mapper/ disk and IP addresses. I left the meta-disk thing as default (internal). Same for the ports. – Jhonatan Cruz Jun 12 '18 at 18:15

0 Answers0