GNU/Linux >> Linux の 問題 >  >> Linux

10GigE での DRBD のひどい同期パフォーマンス

解決策 1:

DRBD の新しいバージョン (8.3.9 以降) には、調整が必要な動的再同期コントローラーがあります。 DRBD の古いバージョンでは、syncer {rate;} を設定します。 十分でした。今では、動的再同期速度の軽く提案された開始点として使用されることが多くなりました.

動的同期コントローラーは、DRBD の構成のディスク セクションにある "c-settings" で調整されます ($ man drbd.conf を参照)。 これらの各設定の詳細について)。

これらのノード間に 10Gbe を使用し、プロトコル C が使用されているためレイテンシが低いと仮定すると、次の構成により、物事がより速く進むはずです:

resource rd0 {
        protocol C;
        disk {
                c-fill-target 10M;
                c-max-rate   700M;
                c-plan-ahead    7;
                c-min-rate     4M;
        }
        on cl1 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.1:7788;
                meta-disk internal;
        }

        on cl2 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.2:7788;
                meta-disk internal;
        }
}

それでも満足できない場合は、max-buffers を回してみてください 12kまで。それでも満足できない場合は、c-fill-target を上げてみてください。 200 万単位で。

解決策 2:

他の誰かが私がこれらの設定を使用することを提案しました:

        disk {
                on-io-error             detach;
                c-plan-ahead 0;
        }
        net {
                max-epoch-size          20000;
                max-buffers             131072;
        }

そして、パフォーマンスは優れています。

編集: @Matt Kereczman と他の提案に従って、私は最終的にこれに変更しました:

disk {
        on-io-error             detach;
        no-disk-flushes ;
        no-disk-barrier;
        c-plan-ahead 0;
        c-fill-target 24M;
        c-min-rate 80M;
        c-max-rate 720M;
} 
net {
        # max-epoch-size          20000;
        max-buffers             36k;
        sndbuf-size            1024k ;
        rcvbuf-size            2048k;
}

再同期速度が速い:

cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---n-
    ns:133246146 nr:0 dw:2087494 dr:131187797 al:530 bm:0 lo:0 pe:5 ua:106 ap:0 ep:1 wo:d oos:4602377004
        [>....................] sync'ed:  2.8% (4494508/4622592)M
        finish: 1:52:27 speed: 682,064 (646,096) K/sec

これらの設定での再同期中の書き込み速度は優れています (ローカル書き込み速度の 80%、最大ワイヤ速度):

# dd if=/dev/zero of=./testdd bs=1M count=20k
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,3731 s, 731 MB/s

読み取り速度は問題ありません:

# dd if=testdd bs=1M count=20k of=/dev/null
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,4538 s, 729 MB/s

後で編集:

完全な再同期の後、パフォーマンスは非常に良好です (ワイヤ速度の書き込み、ローカル速度の読み取り)。再同期は迅速 (5/6 時間) で、パフォーマンスをあまり低下させません (ワイヤ スピード読み取り、ワイヤ スピード書き込み)。私は間違いなくc-plan-aheadをゼロのままにします。ゼロ以外の値では、再同期に時間がかかりすぎます。

解決策 3:

動的同期レートを有効にするには、c-plan-ahead に正の値を設定する必要があります。 controller.disk c-plan-ahead 15; // 5 * RTT / 0.1s unit,in my case is 15 c-fill-target 24; c-max-rate 720M;


Linux
  1. Ubuntu20.04VPSでWordPressを高速化してパフォーマンスを向上させる方法

  2. 方法:DRBDのレプリケーションと構成

  3. キャッシュソリューションXCacheを使用してWebサイトのパフォーマンスを高速化するにはどうすればよいですか?

  1. Lvmはパフォーマンスに影響を与えますか?

  2. Linux OS サービス「cpuspeed」

  3. 離れた 2 台の Linux サーバー間の大規模なファイル ツリーの双方向リアルタイム同期

  1. MySQL –パフォーマンスの調整と最適化

  2. プログラムでリンク速度を取得しますか?

  3. 32 ビット演算と 64 ビット演算のパフォーマンス