お察しのとおり、ディスクのスループットに問題があります。背景を説明するために私が見たものは次のとおりです。nodetool tpstats3 つのノードからの出力には、次の行がありました。
Pool Name Active Pending Completed Blocked All time blocked
FlushWriter 0 0 22 0 8
FlushWriter 0 0 80 0 6
FlushWriter 0 0 38 0 9
私が懸念している列は、すべての時間のブロックです。完了に対する比率として、多くのブロッキングがあります。フラッシュライターは、memtable をディスクにフラッシュして、JVM がメモリ不足になったり、大規模な GC の問題が発生したりしないようにする役割を果たします。memtable は、テーブルのメモリ内表現です。ノードがより多くの書き込みを行うと、ノードがいっぱいになり始め、フラッシュする必要があります。その操作は、ディスクへの長い順次書き込みです。それをブックマークしてください。話を戻します。
フラッシュライターがブロックされると、ヒープがいっぱいになり始めます。それらがブロックされたままになると、リクエストがキューに入れられ始め、最終的にノードが OOM になります。
圧縮も実行されている可能性があります。コンパクションは、SSTableをメモリに長時間連続して読み取り、次にソートされたマージ結果を長時間連続してフラッシュします。シーケンシャル IO の増加。
したがって、ディスクに対するこれらすべての操作は順次実行されます。ランダム IOP ではありません。ディスクが同時シーケンシャル読み取りと書き込みを処理できない場合、IOWait が急上昇し、要求がブロックされ、Cassandra は非常に悪い日になります。
あなたはCephを使用していると述べました。Ceph での Cassandra のデプロイが成功した例はまだ見たことがありません。しばらく持ちこたえた後、シーケンシャル ロードで転倒します。短期的に最も簡単な解決策は、ノードを追加して負荷を分散させることです。中期的には、シーケンシャル ディスク ロード用にスタックを最適化する方法を見つけることですが、最終的には失敗します。長期的には、実際のディスクと共有ストレージからデータを取得します。
私は何年にもわたって Cassandra を使用しているクライアントに、「ストレージにイーサネット プラグがある場合、それは間違っています」と相談してきました。