次のようなシナリオがあります:
srv01 srv02 srv03
srv03 上で実行されている Gluster ボリューム「vol1」があり、すべてのサーバーが I/O に使用できます。vol1 には、数 KB から 3 ～ 4 MB の範囲の多数の混合サイド イメージが含まれており、合計量は約 1.5 TB です。
Glusterのバージョンは3.6.2です
これは万能薬ではなく、多少の調整が必要ですが、かなりうまく機能します。
ここで、srv03 のブリックを他のサーバーに複製する必要があります。
問題は、srv03 の CPU が 100% まで急上昇し、通常のリクエストを処理できないことです。ネット トラフィックは低くなります。
オプションは次のとおりです:
cluster.data-self-heal-algorithm: フル
cluster.self-heal-daemon: オフ
パフォーマンス.キャッシュサイズ: 1GB
レプリケーションの実行中はサービスを実行し続けなければなりません。ご提案をお待ちしています。
答え1
私も似たような状況に取り組んでいます。ボトルネックが CPU である場合は、減らすとcluster.background-self-heal-count効果があると思います (デフォルトは 16)。言い換えると、「クライアントが 17 個のファイルを開こうとすると、17 番目でハングして自己修復を待つ」ということです (https://botbot.me/freenode/gluster/msg/45681458/）。