web-dev-qa-db-ja.com

軽負荷のためのApache / httpdによる高いCPU使用率、「perfrecord」はvmware / hardwareを指します

RHEL7カーネル3.10.0-1062、4 CPUVMWareインスタンスでApache2.4を実行し、WebLogicプロキシプラグインを使用してWebLogicバックエンドへの非常に基本的なリバースプロキシを実行します。サーバーは、数百人のユーザーで約1 MByte /秒をプッシュし、SSLをリッスンし、SSLをWebLogicと通信しています。 Apacheの構成は非常に基本的であり、RewriteRule行またはその他の一般的なパフォーマンスシンクが2つだけです。 VMWareの統計では、オーバーコミットは示されていませんが、ゲストのCPU使用率も100％で示されています。

Linux POVから、サーバーは100％のCPU使用率で稼働し、実行キューは16を超え、ApacheはすべてのCPU時間を使用しています。 'perf record -a -g'を1分間実行し、フレームグラフを作成すると、httpdプロセス（フレームグラフごとにすべてのCPUの97％を使用）で次のような驚くべき時間の使用法があることがわかります。

基本的に、これら2つの顕著な外れ値の外側では、すべてのランタイムは、ApacheのリスニングループとWebLogicプラグインの発信トラフィックの両方からの2つのlibc呼び出し、poll_nocancelとread_nocancelの内部で費やされます。

基盤となるハードウェアは問題ないようで、Linuxカーネルパラメーターは問題ないようですが、このサーバーで実行される1秒あたりの実際の命令数は非常に遅いようです。 'perf'ツールを使用してさらに分析するためのアドバイスはありますか？サーバーにアクセスできないため、他のユーザーに実行するコマンドを提案することしかできません。

linuxperformancevmware-esxihttpdperf
2
Dan

スキニーディープスタックを削除するためにトリミングされた、静的形式のフレームグラフ：

flamegraph showing read_tsc

はい、CPU上のサンプルの多くはシステムコールに関連しています。たくさんのpoll（）とその結果のread_tsc（）、いくつかのread（）、そして明らかにいくつかのシステムコールのオーバーヘッドは、system_call_after_swapgs（）で費やされた時間を与えられます。

これで、インフラストラクチャのallレイヤーのパフォーマンスのバグと非効率性の検索になります。アイデアの不完全なリスト：

ハイパーバイザー

VMware上のTSCについては、 KB 65186 を参照してください。

TSCが非同期であると誤って検出された場合のパフォーマンスの問題（65186）

症状起動中に、vmkernelは、「TSCが参照タイマーとして無効になっています：複数のクロックドメイン」または「TSCが参照タイマーとして無効になっています：NUMATSCが分岐しています」というフレーズを含むメッセージをログに記録します。

その後、仮想マシンはrdtsc命令を実行するときに異常に低いパフォーマンスを示します。

原因最新のx86互換マシンでは、ハードウェアにより、すべての論理CPUのTSC（タイムスタンプカウンター）レジスタが起動時に同期され、ソフトウェアによって変更されない限り常に同期されているため、TSCを単一として扱うことができます。グローバルリファレンスタイマー。 ESXiは、このような同期されたTSCを備えたマシンで最適に動作します。 ESXiは、同期されていないTSCを備えたマシンもサポートしていますが、パフォーマンスが大幅に低下します。特に、ホストに同期されていないTSCがある場合、仮想マシンでのrdtsc命令の実行は100倍ほど遅くなる可能性があります。

現在のいくつかのマシンでは、ファームウェアによって提供される特定のACPIテーブルフィールドの解釈が異なるため、ESXiはホストTSCが非同期であると誤って検出します。現在、ほとんどのHPESuperdomeシリーズマシンがこの問題の影響を受けています。

解決策現時点では、この問題の解決策はありません。

回避策注：実際に同期されたTSCがないマシンにはこの設定を適用しないでください。そうした場合、TSCが離れすぎたときにマシンが最終的にクラッシュし、クラッシュする前に混乱を招く症状が発生する可能性があります。

ホストが確実にTSCを同期している場合は、次のブートオプションを使用して、vmkernelにTSCをグローバル参照タイマーとして使用させることができます。

esxcli system settings kernel set
 --setting=timerForceTSC --value=TRUE

強制TSC回避策の代わりに、代替ハイパーバイザーでホストをテストすることを検討してください。 KVM、Hyper-V、ベアメタルなど。いずれにせよ、この問題の軽減は、TSC機能に費やす時間が100分の1になることで明らかです。

応用

wl_ssl_conn_recvは80％の確率でスタックに含まれています。 httpdソースコードで見つからないので、これはWebLogic関数である必要があります。

費やした時間の一部は、最終的にはpoll（）とTSCに関連しているため、同期されたTSCを最初にチェックする方が早いでしょう。それでも、 WebLogicパフォーマンスの調整 を調べてください。

HTTPS会話

また、ネットワーク上でのプロトコル会話がどのように見えるかを分析します。つまり、httpsのパフォーマンスはどうですか。パケットのキャプチャと分析を試して、応答時間がどのようになるかを確認してください。接続の速度を定量化します。1秒あたり30は、300とはかなり異なります。

HTTP/2の実装には効率があるかもしれませんが、WebLogicでそれを行う方法がわかりません。

セキュリティパッチ

CPU時間のかなりの部分は、syscallに関連しています。 Spectre/Meltdown および [〜＃〜] mds [〜＃〜] に対して有効にしたパッチと緩和策を評価します。これらは、syscallの重いワークロードで比較的高いパフォーマンスヒットをもたらすことが知られています。さまざまなレベルの緩和策をテストし、全体的なセキュリティ管理に基づいてリスク評価を行います。

キャパシティプランニング

たぶん、少なくともこのシステムが現在どのように調整されているかというと、4つのCPUでは不十分です。より多くのインスタンスまたはより多くのCPUで問題にハードウェアを投入することは効率的ではないかもしれませんが、少なくとも他のものを微調整しながら物事を応答性に保つことができます。

1
John Mahowald