Redis のパフォーマンスの問題の概要、トラブルシューティング、およびチューニング

序文

Redis のパフォーマンス トラブルシューティング ツールと問題現象の分析と処理を紹介します。

1. 共通のツールと手段

Redisで提供されるコマンド

1. INFOコマンド

返回关于 Redis 服务器的各种信息和统计数值。
--主要包含以下信息：
server : 一般 Redis 服务器信息；
clients : 已连接客户端信息；
memory : 内存信息；
stats : 一般统计信息；
replication : 主/从复制信息
cpu : CPU 计算量统计信息
commandstats : Redis 命令统计信息
cluster : Redis 集群信息
keyspace : 数据库相关的统计信息

特定の情報については、redis 接続情報の取得など、info message コマンドを使用します。

Redis メモリ情報:

特定の詳細については、中国語のドキュメント https://www.redis.net.cn/order/3676.html を参照してください。

2. 監視コマンド

实时打印出 Redis 服务器接收到的命令，我们一般用这个命令来查询当前Redis正在执行哪些命令，可以短暂开启，不会阻塞Redis，压测验证多少对性能有点性能 大概20%；
比如说Redis进程CPU高了，那我们可以利用这个命令来查询Redis正在执行哪些命令

戻り値を分析してみましょう:
   1635769163.753976 [0 127.0.0.1:3337] "set" "wufeng" "aaaa" 1635769175.259109 [0 127.0.0.1:3337]
   "get" "wufeng" 1635769190.040828 [ 0 127.0.0.1:3337] "
   セット" "五峰" "1111" 1635769192.420104 [0 127.0.0.1:3337
   ] "取得" "五峰"

   たとえば、最初の行の 1635769163.753976 はタイムスタンプで、単位は s;
[0 127.0.0.1:3337]、つまり、Redis ライブラリ 0 で実行されるコマンドの 127.0.0.1:3337 に接続された set コマンドの場合、Redis サービスにパフォーマンスの問題があるときに監視コマンドを数秒間実行し、
   これらの同時コマンドを 1 秒ごとにカウントすることができます。問題を判断するためにどのコマンドが実行されるか。

3.slowlogコマンド

Redis Showlog 慢查询日志，
查询执行时间指的是不包括像客户端响应(talking)、发送回复等 IO 操作，而单单是执行	一个查询命令所耗费的时间。

現在の時点で最新の 10 個のコマンドを取得します。slowlog 3 つの

コマンド結果の分析を取得します。

時点とタイムスタンプがあり、それを監視と分析に使用でき、どの時点でどのコマンドを実行するのにどれくらいの時間がかかるかがわかります。

スロー クエリ ログ キューの設定:
   スロー クエリのしきい値、つまり、スロー クエリ ログに記録される時間を超過した時間を取得します。これにより、クエリの実行時間を何マイクロ秒 (マイクロ秒、1 秒 = 1,000,000 マイクロ秒) で記録する必要があるかが決まります。
     時間を取得します
          CONFIG GET throwlog-log-swer-than

          、つまり、デフォルトのスロー クエリしきい値は 10000 マイクロ秒、つまり 10 ミリ秒です。
     時間の設定:
          CONFIG set throwlog-log-swer-than 5000

ここでは、5000 マイクロ秒、つまり 5 ミリ秒に設定します。値は小さすぎてはいけません (キューは頻繁に置き換えられるため、履歴値を確認するのは簡単ではありません)。また、大きすぎてもいけません (問題を無視するのは簡単です）

スロー クエリ ログ FIFO キューの設定:
エントリ数を取得します
。 CONFIG GET throwlog-max-len、デフォルトは 128、
保存されるエントリの数を設定します
。 CONFIG SET lowlog-max-len 1000、1000 に変更します。

4.bigkeysコマンド

--bigkeys,用来查找大对象value的命令；

どれがビッグキーですか?
    String 型: その大きさは、単一の値が非常に大きいという事実に反映されており、bigkey は一般に 10KB を超えると考えられています。String 型オブジェクトが 10M あると正式環境で分析しました。まだ問題はありませんが、顧客の数が増えると常に潜在的な危険があり、後で通信が最適化されます。非文字列型: ハッシュ、リスト、セット、順序付きセット。需要の観点から、同時実行性は高くありませんが、絶対的ではありません
    。

–bigkeys を使用して bigkey を検出します。
    コマンド redis-cli -h ip -p port -a XXX --bigkeys を実行します。

以下は、現在のクラスター環境のノードの 1 つから抜粋したものです。

bigkey によってもたらされる隠れた危険:
    1. Redis はシングルスレッドであるため、通常、bigkey の操作には時間がかかります。つまり、Redis がブロックされる可能性が高く、クライアントのブロックやフェイルオーバーが発生します。これらは通常、遅いクエリで発生します。

この種の Bigkey ソリューションの場合: 1.
    E10 の新しいキャッシュは、データを圧縮して保存するための圧縮機能戦略、またはビジネス向けの自己圧縮処理を提供します; 2. 同時実行性
    の高い
    Bigkeyの場合     、ローカル キャッシュを採用します。

5.ベンチマークコマンド

--benchmark命令，一般是用来作基准测试的，比如新上一台服务器，测试下简单的get set命令是否可以达到官方给的10多w的qps；

詳細については、次の記事を参照してください;
    Redis パフォーマンス テスト - redis-benchmark チュートリアル https://blog.csdn.net/yangcs2009/article/details/50781530
    

6. レイテンシーコマンド

latency测试运行中Redis的延迟，实现原理是不断的发送ping命令计算平均耗时；

    たとえば、下の図はローカル 127.0.0.1 テストを示しています。テスト中、右側のウィンドウで監視コマンドを実行して、実行されているコマンドをクエリします。これらはすべて ping コマンドであることがわかります。テスト結果から、このマシンでの Redis 遅延の最適値は通常約 19 マイクロ秒です。これは Redis のパフォーマンスをテストする手段でもあります。遅延監視を有効にします: CONFIG SET latency-monitor-threshold 100 #Unit ミリ秒、応答が 10 を超えていることを示します0 ミリ秒が監視されます。デフォルトは 0 で、オフ状態を示し

ます
。

レイテンシ 最新のコマンド

127.0.0.1:6379> latency latest
1) 1) "command" #事件名称
   2) (integer) 1405067976 #延迟发生的时间戳
   3) (integer) 251 #延迟 毫秒
   4) (integer) 1001 #事件的最大延迟

遅延履歴コマンド

127.0.0.1:6379> latency history command #查看commend事件的历史延迟 返回160个元素
1) 1) (integer) 1405067822 #时间戳
   2) (integer) 251 #延迟
2) 1) (integer) 1405067941
   2) (integer) 1001

個人的には、閉じた方が良いと思います。このコマンドの有用性は感じません。slowlog よりも優れています。

他の意味

1. Redisのメモリダンプ分析

主に既存のオープンソース ツールに依存します。推奨されるリンクは次のとおりです。

1. RDR ツールを使用して、Redis のキーが占有しているメモリを表示する https://blog.csdn.net/huantai3334/article/details/113464340
2. rdbtools ツールを使用して Redis rdb ファイルを解析します https://www.cnblogs.com/cheyunhua/p/10598181.html

2. CPU 使用率の問題

1. 大規模な同時実行での CPU の使用率の高さ; 同時実行の
   高さを判断する方法:
   Redis の 1 秒あたりのクエリ数を確認する; –info stat

192.168.0.190:6382> info stats
# Stats
total_connections_received:3578768   ##所有连接数 累积
total_commands_processed:29111456557 ##服务器执行的命令数 累积
instantaneous_ops_per_sec:18570 ## 每秒执行的命令数
total_net_input_bytes:8788037875385  ## 网络流量-流入
total_net_output_bytes:162162655775051 ##网络流量-流出
instantaneous_input_kbps:5034.16 ##网络流量-流入-KB/sec
instantaneous_output_kbps:16361.97  ## 网络流量-流出-KB/sec
rejected_connections:0
sync_full:1
sync_partial_ok:0
sync_partial_ok:0
sync_partial_err:1
expired_keys:427378621
expired_stale_perc:1.11
expired_time_cap_reached_count:8
evicted_keys:1050467
keyspace_hits:11020187003   ## 命中的 Key数量   
keyspace_misses:1112525439  ## 未命中的 Key数量
pubsub_channels:5
pubsub_patterns:2
latest_fork_usec:845
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
192.168.0.190:6382>

	查看当前都是在执行什么命令；--monitor
	查看当前是否存在慢查询；	--- slowlog get

上記のコマンドを使用して、たとえば、どのようなビジネスが無限ループで redis に同時にクエリを実行しているかを確認します。その原因は、いくつかの遅いクエリです。2. 同時実行が小さい場合、CPU の負荷が高くなります。redis の qps が低い場合、CPU の負荷が高く、つまり、アルゴリズムの複雑さと IO の問題にすぎない遅いクエリがあります。このとき、slowlog コマンドを使用してクエリを実行します。3. CPU100 プロセスが Redis の RDB 永続スレッドである場合があります。区別に注意
し
て
ください
。

3. 接続数

Redis 接続数が多いという問題については、まず info client コマンドを使用して Redis 接続数を監視する方法について説明します。

192.168.0.190:6381> info clients
# Clients
connected_clients:2311   ###保持连接数
client_longest_output_list:0 ### 最大的输出缓冲区
client_biggest_input_buf:0 ### 最大的输入缓冲区
blocked_clients:0 ###阻塞的连接数
192.168.0.190:6381>

比如上述连接数2311是公司测试环境集群某一节点的连接数，看起来是挺大的，那如何判断是否正常，我们可以利用命令 clients list，来输出连接的详细信息，比如IP，执行的是什么命令等；
比如下面的命令结果，基本都是在执行ping，auth命令，是因为公司几十个服务都在连接一个Redis集群，客户端有开启连接检测功能，还有就是集群之间的通讯等维持着一定的连接数，所以整体是正常的；

如何判断有异常，主要是看这些连接是否是空闲很长的，即上面截图的idle=，空闲异常长极大说明连接泄漏了；
临时的解决方案：
修改redis.conf 里面的 time out 参数，使redis服务器主动断开连接；
然后看这个cmd= 一般是什么命令，结合redis操作的相关代码，进行排查；

さらに、ここにはもう 1 つのパフォーマンス ポイント、つまり入力バッファと出力バッファの問題があります。事例の追跡調査では、monitor コマンドがメモリの問題を引き起こすことが示されています。Redis5.0 は INFO コマンドのキャッシュ統計を最適化します。クライアント モジュール
https://www.cnblogs.com/chou1214/p/14470057.html

4. メモリの問題

1. メモリ不足、スワップの頻繁な交換による
   Redis の読み取りと書き込みが遅い、ディスク IO の読み取りと書き込みがメモリの読み取りと書き込みよりもはるかに遅い、
   スワップの使用を判断する方法:
        used_memory > used_memory_rss の場合、Redis はこの時点で既に SWAP を使用しており、実行パフォーマンスに影響します、
        または mem_fragmentation_ratio < 1 の場合。

192.168.0.190:6381> info memory
# Memory
used_memory:166958840  ## 是Redis使用的内存总量，它包含了实际缓存占用的内存和Redis自身运行所占用的内存(如元数据、lua)。它是由Redis使用内存分配器分配的内存，所以这个数据并没有把内存碎片浪费掉的内存给统计进去
used_memory_human:159.22M ##redis现在占用的内存，有可能包括SWAP虚拟内存。
used_memory_rss:196255744 ##从操作系统上显示已经分配的内存总量。或者系统已分配的内存
used_memory_rss_human:187.16M ## 好看点的方式展示内存使用M为单位
used_memory_peak:247161800  ##redis的内存消耗峰值(以字节为单位)
used_memory_peak_human:235.71M
used_memory_peak_perc:67.55% ##used_memory_peak_perc：使用内存达到峰值内存的百分比，即(used_memory/ used_memory_peak) *100%
used_memory_overhead:55086750
used_memory_startup:6802568
used_memory_dataset:111872090
used_memory_dataset_perc:69.85%
total_system_memory:33566666752
total_system_memory_human:31.26G
used_memory_lua:83968
used_memory_lua_human:82.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction  ##淘汰策略
mem_fragmentation_ratio:1.18 ##内存的碎片率，used_memory_rss/used_memory --4.0版本之后可以使用memory purge手动回收内存
mem_allocator:jemalloc-4.0.3
active_defrag_running:0 ##表示没有活动的defrag任务正在运行，1表示有活动的defrag任务正在运行（defrag:表示内存碎片整理）
lazyfree_pending_objects:0 ##表示redis执行lazy free操作,在等待被实际回收内容的键个数
192.168.0.190:6381>

          解決策:
               1. メモリを適切に増やし、maxmemory を制限し、適切なメモリ交換戦略を調整します;
               2. rdb ファイルを分析して、どのキーが常にメモリを占有しているか、およびそれが正常かどうかを確認します; 前のセクションを参照してください。

2. メモリ不足、メモリ外のキャッシュ キーの頻繁な置き換えは、
   アプリケーションの低速化、キャッシュ ヒット率の低下、および Redis の頻繁な書き込みにつながります。
   キーがメモリ外に置き換えられたことを判断する方法:
   maxmemory 制限によりリサイクルおよび削除されたキーの数を示す info stats コマンドの結果の evicted_keys の値によって判断できます。置き換えは頻繁です
   。

   解決：

   1. メモリを適切に増やし、maxmemory を制限し、適切なメモリ交換戦略を調整します。
   2. rdb ファイルを分析して、どのキーが常にメモリを占有しているか、またそれが正常かどうかを確認します。前の説明を参照してください。

3. メモリの断片化の問題と解決策
        個人的にはチューニングが難しいと思っていますが、できることはキャッシュに適さない頻繁に更新されるビッグキーに対処することです; Redis のメモリ
        断片化の原因と解決策https://www.manongdao.com/article-2429933.html

メモリ断片化率を軽減できるソリューション (Redis4 以降):
     Redis は、メモリ断片化の自動クリーニング メカニズム専用のパラメータ設定を提供します。Redis リクエスト処理のパフォーマンスに対するデブリ クリーニングの影響を軽減するために、パラメータを設定してデブリ クリーニングの開始と終了のタイミング、および CPU 占有率を制御できます。
     まず、自動メモリ デフラグを有効にします:
          config set activedefrag yes
     次に、メモリ クリーンアップをトリガーする条件を設定します:
          active-defrag-ignore-bytes 100mb: メモリ断片化のバイト数が 100MB に達すると、クリーンアップが開始されます; active-defrag-threshold- lower 10: メモリ断片化スペースが、オペレーティング システムによって
          Redis に割り当てられた合計スペースの 10% を占めると、クリーンアップが開始されます。
     最後に、クリーンアップ操作が占める CPU 時間の割合の上限と下限を制御します:
          active-defrag-cycle-min 25: 自動クリーンアップ プロセスで使用される CPU 時間の割合が 25% 以上であることを示し、クリーンアップが正常に実行できるようにします。active-defrag-cycle-max 75: 自動クリーンアップ プロセスで使用される CPU 時間の割合が 75% 以下であることを示します
          。

5. 永続性の問題

Redis 永続化の 2 つの方法:

1. RDB
2. AOF

    詳細については、ブログ RDB および AOF プロセス https://www.cnblogs.com/iamsach/p/8490387.html を参照してください。

     これら 2 種類の永続性の観点から見ると、Fork サブプロセス、RDBFork サブプロセス、AOF 書き換え Fork サブプロセスのプロセスという共通のパフォーマンス ポイントがあり、メイン プロセスはオペレーティング システムが提供する fork 関数を呼び出すサブプロセスを作成します
     。
     メインプロセスはfork実行時に自身のメモリページテーブルを子プロセスにコピーする必要があり、インスタンスが大きい場合、コピー処理に時間がかかります。
     同時に、このフォーク プロセスは大量の CPU リソースを消費するため、フォークが完了する前に Redis インスタンス全体がブロックされ、クライアント リクエストを処理できなくなります。この時点で CPU リソースがすでに不足している場合、フォークにはさらに時間がかかり、第 2 レベルに達することもあり、Redis のパフォーマンスに重大な影響を及ぼします。

フォーク サブプロセスの影響を確認する方法:
     INFO コマンドを実行すると、内部の Stats フィールドには、最後のフォークに費やされた時間をマイクロ秒単位で示すlatest_fork_usec が含まれます。この時間は、
     メイン プロセスがフォーク サブプロセス内にあり、インスタンス全体がブロックされ、クライアント リクエストを処理できないときの時間です。これに時間がかかる場合は、注意が必要です。つまり、この期間中、Redis インスタンス全体が利用できない状態になります。

     もう 1 つは、RDB が Redis メモリ スナップショットをディスクに書き込むことです。このプロセスはディスク IO に非常に特化しています。このプロセスは Redis プロセスをブロックしませんが、サーバー上に他のインスタンスやサービスがある場合は影響を受けます。

他に RDB 操作がある場所:
     データ永続化のための RDB の生成に加えて、マスター/スレーブ ノードが初めてデータ同期を確立するとき、マスター ノードは RDB を生成するためのサブプロセスも作成し、それを完全同期のためにスレーブ ノードに送信します。したがって、このプロセスは Redis のパフォーマンスにも影響します。また、一般に運用と保守のバックアップに使用される save コマンドまたは bgsave コマンドの手動実行もあります。キャッシュ シーンのバックアップは必要ですか?
     ?

解決策:
     1. Redis インスタンスのメモリを制御します: 10G 未満に保つようにします。フォークの実行にかかる時間は、インスタンスのサイズに関係します。インスタンスが大きくなるほど、時間がかかります。消費時間はシステムにも関係します。仮想マシンは物理マシンよりも時間がかかります。 4. マスター/スレーブ データベースの完全同期の可能性を低減します。マスターとスレーブの完全同期を避けるために、 repl-backlog-size パラメータを適切に      増やし
      ます
     。

6. 現場での事例デモンストレーションと分析の併用、改善の余地あり

ケース 1: RDB によって引き起こされる高い Linux IO 負荷、https://blog.csdn.net/wf_feng/article/details/121182522;
ケース 2: アイドル オブジェクトのトラブルシューティングのための Redis タイムアウト待機、https://blog.csdn.net/wf_feng/article/details/121046703?spm=1001.201 4.3001.5501
ケース 3:

7. Redis の速度低下に関するチェックリストを要約する

• 現在の環境で Redis インスタンスのベースライン パフォーマンスを取得し、それが遅いかどうかを判断します。
• スロークエリコマンドを使用しましたか? その場合は、他のコマンドを使用して低速クエリ コマンドを置き換えるか、集計計算コマンドをクライアントに配置します。
• 時間のかかるフォーク子プロセス。
• 同時実行性、つまり 1 秒あたりのクエリ数が非常に高いかどうか。
• ネットワークトラフィックがピークに達したかどうか。
• メモリがいっぱいで、スワップ交換が発生しました
• ビッグキーは存在しますか？
• Redis AOF 構成レベルとは何ですか? ビジネスレベルでは本当にこのレベルの信頼性が必要ですか? 高いパフォーマンスが必要であり、同時にデータ損失を許容する場合は、構成項目 no-appendfsync-on-rewrite を yes に設定して、AOF 再書き込みと fsync によるディスク IO リソースの競合を回避できます。その結果、Redis レイテンシが増加します。もちろん、高性能と高信頼性の両方が必要な場合は、AOF ログを書き込むディスクとして高速なソリッド ステート ディスクを使用するのが最適です。
• Redis インスタンスの実行環境で透過的ヒュージ ページ メカニズムが有効になっていますか? その場合は、メモリ ヒュージ ページ メカニズムを直接オフにしてください。
• Redis マスター/スレーブ クラスターは実行されていますか? その場合は、マスター/スレーブ レプリケーション中に大きな RDB ファイルをロードしてスレーブ データベースがブロックされないように、マスター データベース インスタンスのデータ サイズを 2 ～ 4 GB に制御します。