web-dev-qa-db-ja.com

専用ギガビットでのDRBDの再同期速度が非常に遅い

私は2つのノードでDRBDを設定し、昨日それを使い始めました。約1時間後、パーティションの50％が再同期されました。さらに12時間経過しました。これは最大79％で、非常にゆっくりと動いています。

これはcat/proc/drbdが示すものです：

 1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r-----
    ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852
        [==============>.....] sync'ed: 79.2% (90076/431396)M
        finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec

ネットワークトラフィックを確認しました。1Gインターフェイスで1M〜20Mを使用しています。これがすべて行われている間にiperfを実行してみたところ、930Mの読み取りがありました。シンクロレートを10M、50M、500Mに調整して、無駄にしようとした。運もないままパケットサイズを微調整。

ステータスからわかるように、ここでの注意点は、プライマリノードに一貫性がないことです。したがって、再同期の実行中、OSは基本的にセカンダリノードで動作していると想定しています。しかし、スループットが非常に低いことを考えると、同期が速くない理由がわかりません。

次に試すことができるものについてのアイデアはありますか？予想される76時間の完了は、私が期待するものではありません:(特に理由がわからないので、一種の停止が発生した場合、アレイを迅速に一貫性のある状態にする方法がわかりません。

ありがとう！

編集： netセクションで次の設定を試みましたが、役に立ちませんでした。

sndbuf-size       512k;
max-buffers      20480;
max-Epoch-size   16384;
unplug-watermark 20480;

編集2：明らかな理由もなく、すべての設定の調整をやめた後、速度は10〜30Mに跳ね上がりました。最大98.8％同期し、最大30万に落ちました。どちらのサーバーのログにもメッセージはありません。偶然にも、このパーティションで実行されるMySQLデータベースでのINSERTアクティビティが急上昇しています。何か案は？

編集3：バージョン：8.4.2（api：1/proto：86-101）

drbd
7
Sergey

@Nilsのコメントの後、ディスクの使用状況を調査し始めました。また、システムをDRBDに再構成する前に使用していたよりも多くの読み取りを取得していることに気付きました。さらなる調査では、ディスク使用率がほぼ100％であり、そのときに実行されていたバッチプロセスの速度が低下していることがわかりました。ほとんどの読み取りを排除するためにバッファープールサイズを増やすようにMySQL構成を修正すると、問題が修正されたように見えます。

したがって、問題は、ドライブが非常にビジーであり、DRBDが要求する多くの再同期作業を処理できないことでした。

3
Sergey

同期レートを強制してみてください

drbdsetup /dev/drbd0 syncer -r 100M

再起動後に構成のsyncer {}を使用して設定することもできます

1
Mike