Redisが大きなデータセットをロードすると、一部のLinuxシステムが非常に遅くなります

Redisユーザーからレポートを受け取りました。Linuxとそのスケジューラーの分野の専門家ではないので、何を返信すればよいかわかりませんが、（Redisプロジェクトとして）この種の問題を特に把握する必要があります。将来的には、Redisクラスターと同様に、1つのボックスで多数のRedisインスタンスを同時に実行する予定です。だから私はここでいくつかの助けを求めています。

問題：

• カーネル：「Linux redis1 2.6.32-305-ec2＃9-Ubuntu SMP Thu Apr 15 08:05:38 UTC 2010 x86_64 GNU / Linux」
• 十分な空きRAM、重要なI / Oを実行する他のプロセスはありません。
• 重要、実サーバーではなく、EC2ビッグインスタンスで実行します。仮想化されていない環境では、そのようなものを見たことはありません。EC2インスタンスは、「ハイメモリエクストララージインスタンス17.1 GBメモリ、6.5 ECU（3.25 EC2コンピューティングユニットを備えた2つの仮想コア）、420 ​​GBのローカルインスタンスストレージ、64ビットプラットフォーム」でした。

基本的に、大きなRedisインスタンスを再起動すると、システムが非常に遅くなり、シェルを入力できなくなります。Redisがインスタンスをロードするとき、CPUを100％使用し（データを可能な限り高速にロードします）、dump.rdbファイルを順番に読み取ります。ロードはI / OバウンドではなくCPUバウンドであるため、I / Oはそれほど高くありません。

なぜ2つのCPUと十分なRAMを備えたディスクがディスク上にスワップされていないのに、なぜこの作業負荷で動作を停止する必要があるのでしょうか？

私は、これがEC2インスタンスであるという事実と多くの関係があるという印象を持っているので、使用されている仮想化テクノロジーに関連して、私はいつもRedis 24 GBデータセットを問題なく（他のRedisインスタンスでも）高負荷で実行）。

ヒントをありがとう！

サルバトーレ

編集：ツイッターから受け取ったフィードバックを追加します：

@ezmobiusから：@antirezの最初の操作は、/ mntまたはローカルの一時ドライブから試して、そのEBSのフレキネスを確認することです。最初にディスク全体で0をddする必要があります。

from @dvirsky：@antirezまさにそのようなec2ノードで多くのredisインスタンスを実行しています。私はbgsaveの速度低下に気づきましたが、この現象には気づきませんでした。

「top」からの出力は、いくつかの手がかりをもたらす可能性があります。左上の「％stelen」というラベルの付いたフィールドには、同じ物理ボックス上の他のゲストに転送されたハードウェアCPUの量が反映されます。ハイパーバイザーが別のゲストにより多くのCPUを割り当てることを決定した場合、特に長時間実行されるCPU集中タスクを実行している場合、この種の速度低下が見られました。

それがあなたの問題かどうかはわかりませんが、チェックする価値があります。

EC2インスタンスでも同じ問題が発生しました。おそらくRedisとは関係ありません-高いIOが進行している場合（たとえば、redisがダンプファイルをロードしている場合）に発生します。

アマゾンフォーラムでこのスレッドをご覧ください：https : //forums.aws.amazon.com/thread.jspa?messageID=215406

私はさまざまなカーネル/イメージを試しましたが、今では正常に動作します（古い2.6.21カーネルで）。

100％の負荷とフリーズシェルが発生したときに表示されるCPUスチール（xx.x%stCPU行の右側）を確認する必要がありtopます。スチールは、ハイパーバイザーによってマシンから実際のCPUサイクルがどれだけ盗まれ、別のマシンに与えられるかを表します。CPUスチールは、仮想化環境にのみ関係します。マイクロインスタンスにその正確な問題があり、CPU集中型タスクを実行する場合、基本的に約1時間ほど（私のタスクが終了するまで）インスタンスを使用できなくなりました。

このトピックの詳細については、GregのRamblingsに関するこの投稿をお読みください。グレッグの言葉を借りれば、これはマイクロインスタンスでのみ発生するはずです。