Redisストールのトラブルシューティング
サーバー上でいくつかのredisインスタンスが実行されています。同時にストールが発生するインスタンスに接続する複数のWeb層サーバーもあります。 当時はパケットキャプチャがあり、次のWireshark IOグラフのように、TXトラフィックとRXトラフィックの両方でストールが発生していることがわかりました。 redis呼び出しには相関するスパイクがありましたが、タイムラグによる影響であり、原因ではなかったと思います。 15 / sのサンプリング間隔（これはカウンターとして収集されます）では、平均136のメモリ割り当てストールがありました。 また、同時に移行されたNUMAページの数が通常とは異なるように見えました。 上記は正常に見えますが、グラフに見られる他の300を超えるスパイクと比較して異常になる2つの連続したデータポイントがありました。 メモリの圧縮の失敗と圧縮の停止には、相関するスパイクもありました。 ここには多くのメモリ情報がありますが、私のLinuxメモリの知識は、ストールを説明するためにこれらすべての情報をまとめる良い物語を実際に仮定するほど深くはありません。Linuxのメモリに関する深い知識（およびおそらくredisに関する深いメモリに関する知識）を持っている人は、この情報の一部を結び付けることができますか？ 15秒間隔で/ proc / vmstatからすべての統計を収集します。そのため、これに追加すると思われるデータがある場合は、リクエストしてください。私は、特にallocストール、numaマイグレーション、およびコンパクションストール/失敗など、興味深いアクティビティがあると思われるものを選びました。合計は次のとおりで、20日間の稼働時間をカバーしています。 [kbrandt@ny-redis01: ~] uptime 21:11:49 up 20 days, 20:05, 8 users, load average: 1.05, 0.74, 0.69 [kbrandt@ny-redis01: ~] cat /proc/vmstat nr_free_pages 105382 nr_alloc_batch 5632 nr_inactive_anon 983455 nr_active_anon 15870487 nr_inactive_file 12904618 nr_active_file 2266184 nr_unevictable 0 nr_mlock 0 …