ETL性能問題
2691 ワード
影響要因:
生産者と消費者キューレート:実質的に生産者消費者キューの最適化であり、CPUの持続占有率を保証する;
ディスクIOレート:ETLにはファイルの抽出、解析、読み書きがあります.このプロセスには大量のディスク読み書き操作が含まれています.これもパフォーマンスのボトルネックになりやすい場所です.
テストの結果
ここでの重点指標はsvctmとutilの2列で、manは以下の説明を見ることができます.
svctm:機器毎にI/O要求を操作するサービス時間平均
%util:機器操作毎のIO要求におけるCPU時間の割合、1秒におけるI/O操作の利用率、または1秒にどれだけの時間I/Oキューが空でないか.100%に達すると、実はこのサーバのIOがボトルネックになっていることがわかります.
では、なぜ一番前のcpu統計図のiowait項目は5.5%程度しかないのでしょうか.このiowait(すなわちtopのwa%)は、全体的に見て、CPUがIOを待つ時間の割合:wa--iowait Amount of time the CPU has been waiting for I/O to completeを指すからである.すなわち、CPUはIO完了(iowait)を待つために一部の時間を出すことができるが、ディスクの観点からディスクの利用率が満たされている(util%)、この場合、CPUの使用率は高くないかもしれないが、システム全体のQPSはもう上がらず、トラフィックを大きくすると、1回のIO要求がキューに詰まっているため、システム全体の処理性能に影響を及ぼす.
サーバがログ分析に使用する場合は、複数のcrontabのオーバーラップによるマルチプロセスランダムIO(参照:ランダムIO vsシーケンスIO)を回避し、定期的に大きなログを圧縮、解凍しないようにします(このタスクは、ある時間のIOジッタを引き起こす可能性があります). フロントエンドアプリケーションサーバの場合、プログラムがローカルログや例外ログを頻繁に打つことを避ける必要があります. ストレージサービス(mysql、nosql)の場合、できるだけ他のサービスと共用しないで、サービス自体が読み書き分離をして読み書き圧力を低減するように、サービスを個別のノードに配置します.いくつかのbufferパラメータを最適化してIO書き込みの周波数などを低減します.また、ランダムIOを順番IOに変更するLevelDBという古典的な方法も参照できる.
svctmは一般的にawaitより小さく(同時待機のリクエストの待ち時間が重複して計算されているため)、svctmの大きさは一般的にディスク性能に関係し、CPU/メモリの負荷も影響し、要求が多すぎると間接的にsvctmの増加を招く.awaitのサイズは、通常、サービス時間(svctm)およびI/Oキューの長さおよびI/Oリクエストの発行モードに依存する.svctmがawaitに近い場合は、I/Oに待ち時間がほとんどないことを示します.awaitがsvctmよりはるかに大きい場合、I/Oキューが長すぎることを説明し、アプリケーションの応答時間が遅くなり、応答時間がユーザーが許容できる範囲を超えた場合、より速いディスクを交換し、カーネルelevatorアルゴリズムを調整し、アプリケーションを最適化したり、CPUをアップグレードしたりすることができます.
生産者と消費者キューレート:実質的に生産者消費者キューの最適化であり、CPUの持続占有率を保証する;
ディスクIOレート:ETLにはファイルの抽出、解析、読み書きがあります.このプロセスには大量のディスク読み書き操作が含まれています.これもパフォーマンスのボトルネックになりやすい場所です.
テストの結果
iostat -x 2
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 1.60 0.40 0.60 199.80 8.80 98256.80 980.69 143.66 686.58 77.33 688.41 4.99 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 2.20 0.00 8.80 0.00 8.00 0.21 97.27 97.27 0.00 15.64 3.44
dm-1 0.00 0.00 0.00 5.00 0.00 24.80 9.92 2.07 413.92 0.00 413.92 85.04 42.52
dm-2 0.00 0.00 0.00 196.20 0.00 99437.60 1013.64 142.98 697.27 0.00 697.27 5.10 100.00ここでの重点指標はsvctmとutilの2列で、manは以下の説明を見ることができます.
svctm
The average service time (in milliseconds) for I/O requests that were issued to the device.
%util
Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%. svctm:機器毎にI/O要求を操作するサービス時間平均
%util:機器操作毎のIO要求におけるCPU時間の割合、1秒におけるI/O操作の利用率、または1秒にどれだけの時間I/Oキューが空でないか.100%に達すると、実はこのサーバのIOがボトルネックになっていることがわかります.
では、なぜ一番前のcpu統計図のiowait項目は5.5%程度しかないのでしょうか.このiowait(すなわちtopのwa%)は、全体的に見て、CPUがIOを待つ時間の割合:wa--iowait Amount of time the CPU has been waiting for I/O to completeを指すからである.すなわち、CPUはIO完了(iowait)を待つために一部の時間を出すことができるが、ディスクの観点からディスクの利用率が満たされている(util%)、この場合、CPUの使用率は高くないかもしれないが、システム全体のQPSはもう上がらず、トラフィックを大きくすると、1回のIO要求がキューに詰まっているため、システム全体の処理性能に影響を及ぼす.
では、IO負荷が高すぎる問題をどのように回避しますか?具体的な問題の具体的な分析：
svctmは一般的にawaitより小さく(同時待機のリクエストの待ち時間が重複して計算されているため)、svctmの大きさは一般的にディスク性能に関係し、CPU/メモリの負荷も影響し、要求が多すぎると間接的にsvctmの増加を招く.awaitのサイズは、通常、サービス時間(svctm)およびI/Oキューの長さおよびI/Oリクエストの発行モードに依存する.svctmがawaitに近い場合は、I/Oに待ち時間がほとんどないことを示します.awaitがsvctmよりはるかに大きい場合、I/Oキューが長すぎることを説明し、アプリケーションの応答時間が遅くなり、応答時間がユーザーが許容できる範囲を超えた場合、より速いディスクを交換し、カーネルelevatorアルゴリズムを調整し、アプリケーションを最適化したり、CPUをアップグレードしたりすることができます.