0

Swift バージョン 1.8.0 の Swift クラスターに問題があります。クラスターは 3 つのストレージ ノード + プロキシ ノードから構築され、2 回のレプリケーションがあります。各ノードには 2 TB の sata HDD が 1 つ搭載されており、OS は SSD で実行されています。トラフィックは、1 分あたり約 300 個の 1.3 MB ファイルです。ファイルは同じサイズです。各ファイルは、7 日間に相当する値の X-expire-after でアップロードされます。

約 3 か月前にクラスターを開始したとき、アップロードするファイルは大幅に少なく (~150/m)、すべて正常に機能していました。システムにより多くの圧力をかけているため、ある時点で、オブジェクトの期限切れ機能は、アップロードされるほど速くファイルを期限切れにすることができず、ゆっくりとサーバーをいっぱいにしました。

分析の結果、次のことがわかりました。

  • これはネットワークの問題ではなく、インターフェイスが過負荷になっておらず、開いている接続が極端に多いわけでもありません
  • CPU の問題ではなく、負荷は問題ありません
  • RAM の問題ではないようです。64G から 20G まで空きがあります。

ボトルネックはディスクのようです.iostatは非常に明らかにしています:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00    57.00    0.00  520.00     0.00  3113.00    11.97   149.18  286.21    0.00  286.21   1.92 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               2.00    44.00    7.00  488.00   924.00  2973.00    15.75   146.27  296.61  778.29  289.70   2.02 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     3.00   60.00  226.00  5136.00  2659.50    54.51    35.04  168.46   49.13  200.14   3.50 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00  110.00   91.00  9164.00  2247.50   113.55     2.98   14.51   24.07    2.95   4.98 100.00

読み取りと書き込みの待機時間は常にそれほど良いとは限りません:)、数千ミリ秒に達する可能性があり、これはかなり恐ろしいことです。

また、ノード側とプロキシから多数の ConnectionTimeout メッセージが表示されます。

ストレージ ノードの例:

Jul 17 13:28:51 compute005 object-server ERROR container update failed with 10.100.100.149:6001/sdf (saving for async update later): Timeout (3s) (txn: tx70549d8ee9a04f74a60d69842634deb)
Jul 17 13:34:03 compute005 swift ERROR with Object server 10.100.100.153:6000/sdc re: Trying to DELETE /AUTH_698845ea71b0e860bbfc771ad3dade1/container/whatever.file: Timeout (10s) (txn: tx11c34840f5cd42fdad123887e26asdae)
Jul 17 12:45:55 compute005 container-replicator ERROR reading HTTP response from {'zone': 7, 'weight': 2000.0, 'ip': '10.100.100.153', 'region': 1, 'port': 6001, 'meta': '', 'device': 'sdc', 'id': 1}: Timeout (10s)

また、プロキシから:

Jul 17 14:37:53 controller proxy-server ERROR with Object server 10.100.100.149:6000/sdf re: Trying to get final status of PUT to /v1/AUTH_6988e698bc17460bbfc74ea20fdcde1/container/whatever.file: Timeout (10s) (txn: txb114c84404194f5a84cb34a0ff74e273)
Jul 17 12:32:43 controller proxy-server ERROR with Object server 10.100.100.153:6000/sdc re: Expect: 100-continue on /AUTH_6988e698bc17460bbf71ff210e8acde1/container/whatever.file: ConnectionTimeout (0.5s) (txn: txd8d6ac5abfa34573a6dc3c3be71e454f)

Swift にプッシュするすべてのサービスと object-expirer が停止すると、ほとんどの場合、ディスク使用率は 100% のままになります。async_pending トランザクションはありませんが、おそらく object-replicator からの再同期が大量に行われています。すべてがオンになっている場合、ほとんどの時点で 30 ~ 50 またはそれ以上の async_pending トランザクションがあります。

問題を軽減するためにさまざまな解決策を考えましたが、基本的には次のような結果になりました。

  • ストレージ用の SSD は高すぎて実現しない
  • 別の HDD を RAID0 クラスター内のそれぞれとペアにして配置します (迅速なレプリケーションがあります)
  • bcache や flashcache などのキャッシュの使用

この種の問題を経験した人はいますか?根本原因を探すためのヒントやその他の場所はありますか? エクスパイア/レプリケータのパフォーマンスを最適化する可能性はありますか?

追加情報が必要な場合は、お知らせください。

ありがとう

4

1 に答える 1

0

100 万を超えるオブジェクトを含むコンテナがタイムアウトを引き起こす問題を見てきました (sqlite3 db がロックを取得できないため)...コンテナのオブジェクト数を確認できますか?

于 2014-07-17T22:09:54.153 に答える