Redis タイムアウトのトラブルシューティングの分析例

数日前の作業中、突然、Redis がクラッシュしたというアラートを受け取り、多くの人が特定の Redis 接続タイムアウトについて議論していました。最初は大きな問題があると思いましたが、しばらくすると回復するとは誰にもわかりませんでした。その際、サーバーにログインして監視を確認してみました。初めて QPS を見てみましょう:

QPS が高くないことがわかりますが、一定期間データが取得できなかったのはなぜですか?次に、Redis の CPU 使用率を調べ続けます:

CPU が飽和していることがわかります。グラフが壊れている理由もこれで説明できます。これは、redis がシングルスレッドであり、CPU を 100% 使用した後は他のコマンドを処理できず、zabbix も処理できないためです。情報を実行します。コマンドは qps から取得されます。この問題の原因が CPU の飽和であることはすでにわかっていますが、その理由は何でしょうか?次に、CPU 使用率が高い期間中に遅いログがあるかどうかを引き続き確認します:

これは CPU 使用率の上昇の原因ではないようなので、トラブルシューティングは困難です。この例はマスター ノードとスレーブ ノードです。次に、スレーブ ライブラリの CPU 使用率を見てみましょう:

くそー、何が起こっているの? スレーブ ライブラリで使用されていない CPU が 74% も使用されるのはなぜですか?これは科学的ではありませんか?とにかく、スレーブ ライブラリからの遅いログがあるかどうかを確認してください:

くそー、何が起こっているのですか？誰もスレーブライブラリを使用していません。読み取り専用かどうかを確認します:

127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103> 

これは読み取り専用のようで、混乱しました。最後に、メイン ライブラリにはこの時点で有効期限が切れた大きなキーがあり、メイン ライブラリの有効期限が切れたキーの遅い操作では遅いログが記録されないことに突然気づきました。スレーブ ライブラリのキーの有効期限は、次の方法で削除されます。 DEL 命令を開始するメイン ライブラリ。このとき、スレーブ ライブラリはスロー ログを記録します。上記のスロー ログから、DEL 操作の最大値は 335ms であることがわかります。アプリケーションの接続タイムアウトが発生するのも不思議ではありません。

コマンド info commandstats を再度使用して、次の内容を確認します。

以上がRedis タイムアウトのトラブルシューティングの分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。