1. 背景
反馈linux磁盘IO高，部署在服务器上的服务，响应很慢，需要排查解决；
2. 問題の分析と解決策
1. IO を占有するプロセスを特定する
サーバーに入って直接トップ分析を行うと、下図の wa 値が非常に高く、IO 負荷が非常に高いことを示しています。さらにどのプロセスが IO 消費量が多いかを確認すると、下図に示すように、redis サーバー プロセスの書き込み IO が非常に高いことが分かりました。興味があり、すぐにこの問題の分析プロセスを記録するためにスクリーンショットを作成しました。書き込みファイルの速度が非常に高く、Redis の RDB プロセスであることを確認する必要がなく、スナップショット メモリをディスクに書き込むプロセスが遅いです
。
;
2. なぜそんなに多くの時間がかかるのか
なぜIOをそんなに食べるのですか？
上図からわかるように、プロセスの書き込み速度は約 30M/s であるため、RDB ファイルのサイズを確認してみましょう、下図は約 4G、30M/s の速度に応じて、約 40000/30=1333 秒かかります。したがって、現時点では、サーバーの IO 能力が比較的低いと思われます。サーバーの IO
パフォーマンスを検証する方法: 次のコマンドを実行します。これは、G ファイルをディスクに書き込むことを意味し、時間がかかる状況を確認します。基本的なピーク値は 60M/s です。私自身の Linux テスト環境の 1 つでディスク パフォーマンスをテストします。370M/s は、4G ファイルをローカルに書き込むことを意味し、10 秒未満
です
。
3. 解決方法
上記の分析から、サーバー自体のディスク IO パフォーマンスが比較的低いことがわかります。そのため、Redis RDB プロセスは 4G ファイルをディスクに書き込み、書き込み速度は 3M/s で非常に遅く、やや標準的なディスク IO は基本的に数百 M/s に達する可能性があるため、ディスクのパフォーマンスをチェックするか、ハードウェアを交換するために運用と保守にフィードバックします。
3. まとめ
从上述的过程来看，RDB的过程是很依赖磁盘IO性能的，但是RDB的过程是不阻塞Redis的正常的执行，一旦是RDB文件的写入导致的服务器IO高，是会影响到该服务器上的其他服务进程的性能；
也从另外一个角度来讲，RDB的过程似乎把内存大小控制在4g左右是个比较合理的值，因为内存大的实例，Fork子进程这个过程必然会相对耗时些，同时持续会写入会更长，对磁盘性能是考验；如果内存不足，但是需求很高，并发很高，倒是可以部署多节点的集群模式，即表达的意思是，部署20个4g的redis节点，比部署4个20G的redis集群节点，性能更佳，但是带来的是运维上和机器的成本；