Redis における 2 つの永続性の欠陥の概要

1. RDB 永続モードの欠陥

1. 問題の説明:

同時 200 チャネル、Redis への連続書き込みをシミュレート、4 時間後、A多数のインターフェイス呼び出しが失敗し始め、エラー メッセージは次のとおりでした:

{"data":{"sendResult":null},"base":{"returncode":"99999","returndesc":"系统异常：MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error."},"qrybase":{"total":0,"count":0,"start":0}}

2. 原因分析:

エラー メッセージを解釈し、ディスク領域の不足が原因であると考えました。次のように、ディスクの 42% が残っていることが判明しました:

そこで、エラー メッセージ プロンプトに従って Redis ログを開き、ストレス テストを続行しました。まだエラーが報告されていますが、

は Redis のログ情報から取得できます。バックグラウンドで保存できません: fork: Cannot assign Memory

これは、プロセスによるメモリの不適切な使用 Redis メイン プロセスが占有しているメモリを次のように確認します: ほぼ 55%*4G メモリを占有している

具体的な理由:データをハードディスクに保存するときにメイン プロセスのアニメーションが一時停止される場合、Redis はメイン プロセスのコピーをフォークし、フォーク プロセスでデータをハードディスクに保存する操作を完了する必要があります。メイン プロセスが 2.2 GB のメモリを使用する場合, 子プロセスをForkする際にさらに2.2GBが必要となり、この時メモリ不足でForkが失敗し、データ保存用のハードディスクも故障してしまいます。

3. 軽減策 (問題を根本的に解決できない):

3.1 redis.conf ファイルの構成項目 stop-writes-on-bgsave-error no を変更します (デフォルト値はyes)、つまり、bgsave スナップショット操作でエラーが発生した場合、ディスクへのデータの書き込みを停止します。これにより、後続の書き込みエラーは失敗します。後続の書き込み操作に影響を与えないようにするには、この値を no に変更する必要があります。

3.2 カーネル パラメータを変更する (以下の 3) 方法)、ただし root 権限が必要です:

（1）	编辑/etc/sysctl.conf ，改vm.overcommit_memory=1，然后sysctl -p 使配置文件生效
（2）sysctl vm.overcommit_memory=1
（3）echo 1 > /proc/sys/vm/overcommit_memory

2. AOF 永続モードの欠陥

1. 問題 1 の説明:

Redis マスター ノードとスレーブ ノードの両方で AOF モードが有効になっています。同時接続数は 200 で、シミュレーションは Redis への書き込みを続けました。15 分後、多数のインターフェイス呼び出しが失敗し始め、Linux 仮想サーバーはRedis がハングしていることがわかりました。

インターフェイス エラーは次のとおりです:

{"data":null,"base":{"returndesc":"系统异常","returncode":"999999"},"qrybase":null}
Biz（dubbo）接口报错如下：
2015-06-05 11:28:28.760 [DubboServerHandler-X.X.X.X:20882-thread-173] ERROR  - error while validate jedis!
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

原因分析:

ダボ インターフェイス エラー メッセージから、インターフェイス API 操作 Redis タイムアウトが原因であることがわかります。システム ログと IO 監視から判断すると、以下に示すように、上記の問題は IO ボトルネック (システム IO がビジーすぎる) によって引き起こされていることがわかります。

# システム ログからも、IO ブロック時間が 120 秒を超え、システム セキュリティ メカニズムが原因でマシンがハングしていることがわかります。

概要

テスト結果は、AOF モードには最も明白な欠陥があることを証明しています。つまり、アクセス圧力が高い場合、IO がパフォーマンスのボトルネックとなり、サービスが利用できなくなるということです。

3. 軽減策 (問題を根本的に解決できない)

/etc/sysctl.conf を編集し、次の設定を追加します:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

次に、sysctl -p で設定を行います。ファイルが有効になります。

問題 2 の説明:

2 つのファイル (.aof または .rdb) のサイズがシステム メモリの 80% を超える場合、AOF モードと RDB (スナップショット モード) のどちらが使用されるかの場合、Redis プロセスはシステムダウンによって強制終了され、サービスが利用できなくなります。

概要

上記の問題は、Redis を使用する場合は、事前にシステム メモリ容量を計画する必要があることを示しています。これは、Redis がクラッシュすると大量のデータが失われ、回復できなくなるためです。

redis の詳細については、

redis 入門チュートリアル

列に注目してください。

以上がRedis における 2 つの永続性の欠陥の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。