この質問は、RHEL5.3の/ proc/vmstatに記録されている特定のメトリックの定義に関連しています。
Nmonを使用して、1時間で1日のワークロードを実行する2500人のユーザーをシミュレートする負荷テストを監視しています。最近、パフォーマンスが低下し、さまざまな考慮事項を診断して除外しているところです。
VmwareESXでRedHat Enterprise Linux Serverリリース5.3(Tikanga)を実行しています。私が焦点を当てている物理サーバーは、実行とOracle Application Server(これは、ApacheHTTPサーバーとOC4JJ2EEコンテナーで構成されます)です。
私が表示しているnmonチャートは、pswpinメトリックへの一貫した割り当てを示しています。要約すると;最小= 4312;最大= 245352; avg =86734。Nmonは、「kBytespersecond」で測定されたこれらの値を示します。
次のメトリックは、テスト全体を通じてゼロです。
ページングとスワッピングについての私の理解を考えると、このメトリックの組み合わせが何を意味するのかについて私は混乱しています。
私の質問:
現時点では、パフォーマンス低下の原因として仮想メモリの問題を除外しようとしています。
EDIT:テスト全体で多数のfork()呼び出しの証拠が見つかりました。 Apacheデーモンが疑われます。しかし、プロセスの作成がこれらのメトリックの原因である可能性がありますか?
EDIT: nmonからのVM出力の典型的なサンプルを追加しました。フォーマットが不十分であることをお詫びします。
ご回答ありがとうございます。
T0001 -1 22 -1 -1 -1 150 -1 -1 -1 5196046163 -1 0 30 100199751 3060 -1 0 -1 885 -1 -1 -1 46163 -1 -1 18 -1 828189171 -1 -1 3838 -1 -1 -1 -1 -1 165231
03:07:23 Paging and Virtual Memory nr_dirty nr_writeback nr_unstable nr_page_table_pages nr_mapped nr_slab pgpgin pgpgout pswpin pswpout pgfree pgactivate pgdeactivate pgfault pgmajfault pginodesteal slabs_scanned kswapd_steal kswapd_inodesteal pageoutrun allocstall pgrotated pgalloc_high pgalloc_normal pgalloc_dma pgrefill_high pgrefill_normal pgrefill_dma pgsteal_high pgsteal_normal pgsteal_dma pgscan_kswapd_high pgscan_kswapd_normal pgscan_kswapd_dma pgscan_direct_high pgscan_direct_normal pgscan_direct_dma
03:07:33 -1 99 -1 -1 -1 241 0 0 0 77526 0 0 0 824 0 0 0 0 0 0 0 0 77526 0 0 0 0 0 0 0 78216 0 0 0 0 0 0
03:07:43 -1 10 -1 -1 -1 262 0 0 0 21653 0 0 8 500 2 0 0 0 0 0 0 0 21653 0 0 0 0 0 0 0 17675 0 0 0 0 0 0
03:07:53 -1 69 -1 -1 -1 257 0 0 0 115744 0 0 0 724 0 0 0 0 0 0 0 0 115744 0 0 0 0 0 0 0 -79544 0 0 0 0 0 0
03:08:03 -1 69 -1 -1 -1 196 0 0 0 81202 0 0 0 628 0 0 0 0 0 0 0 0 81202 0 0 0 0 0 0 0 -18335 0 0 0 0 0 0
03:08:13 -1 81 -1 -1 -1 205 0 0 0 29051 0 0 0 352 0 0 0 0 0 0 0 0 29051 0 0 0 0 0 0 0 24449 0 0 0 0 0 0
03:08:24 -1 91 -1 -1 -1 131 0 0 0 122795 0 0 0 1172 0 0 0 0 0 0 0 0 122795 0 0 0 0 0 0 0 9640 0 0 0 0 0 0
03:08:34 -1 6 -1 -1 -1 182 0 0 0 74914 0 0 4 372 1 0 0 0 0 0 0 0 74914 0 0 0 0 0 0 0 -24477 0 0 0 0 0 0
03:08:44 -1 38 -1 -1 -1 200 0 0 0 42957 0 0 4 464 1 0 0 0 0 0 0 0 42957 0 0 0 0 0 0 0 42778 0 0 0 0 0 0
03:08:54 -1 6 -1 -1 -1 141 0 0 0 89751 0 0 36 1000 9 0 0 0 0 0 0 0 89751 0 0 0 0 0 0 0 -9665 0 0 0 0 0 0
03:09:04 -1 6 -1 -1 -1 171 0 0 0 74740 0 0 4 516 1 0 0 0 0 0 0 0 74740 0 0 0 0 0 0 0 -24583 0 0 0 0 0 0
03:09:14 -1 10 -1 -1 -1 179 0 0 0 56063 0 0 0 500 0 0 0 0 0 0 0 0 56063 0 0 0 0 0 0 0 56384 0 0 0 0 0 0
03:09:24 -1 6 -1 -1 -1 74 0 0 0 75623 0 0 0 696 0 0 0 0 0 0 0 0 75623 0 0 0 0 0 0 0 -23994 0 0 0 0 0 0
03:09:34 -1 6 -1 -1 -1 137 0 0 0 75466 0 0 8 972 2 0 0 0 0 0 0 0 75466 0 0 0 0 0 0 0 -23837 0 0 0 0 0 0
03:09:44 -1 3 -1 -1 -1 153 0 0 0 72535 0 0 4 460 1 0 0 0 0 0 0 0 -927465 0 0 0 0 0 0 0 -26880 0 0 0 0 0 0
03:09:54 -1 6 -1 -1 -1 170 0 0 0 56775 0 0 0 284 0 0 0 0 0 0 0 0 56775 0 0 0 0 0 0 0 56895 0 0 0 0 0 0
03:10:04 -1 6 -1 -1 -1 166 0 0 0 74756 0 0 0 1116 0 0 0 0 0 0 0 0 74756 0 0 0 0 0 0 0 -24568 0 0 0 0 0 0
03:10:14 -1 6 -1 -1 -1 148 0 0 0 78043 0 0 0 432 0 0 0 0 0 0 0 0 78043 0 0 0 0 0 0 0 -21241 0 0 0 0 0 0
03:10:24 -1 64 -1 -1 -1 189 0 0 0 64057 0 0 0 412 0 0 0 0 0 0 0 0 64057 0 0 0 0 0 0 0 60788 0 0 0 0 0 0
pgpgin - Number of kilobytes the system has paged in from disk per second.
pgpgout - Number of kilobytes the system has paged out to disk per second.
pswpin - Number of kilobytes the system has swapped in from disk per second.
pswpout - Number of kilobytes the system has swapped out to disk per second.
Pswpinカウンターを増やした各ページでpgpginも増えるはずだと87%確信しています。あなたはそうではないと言います。うーん。
これは単純すぎて確認できないかもしれませんが(申し訳ありません!)...観察するメトリックがpgpginではなくpswpinであることを200%確信していますか?後者は次のように解釈されます。プロセスはいくつかのファイルを読み取っています。
他の説明は、アプリケーションがテストの前に大幅にスワップアウトされ、システムが大量の空きメモリを取得したことです。また、テスト中は、ファイルの読み取り/書き込みを行わずに、「生き返る」(コードの実行が進むにつれて常にスワップインする)ことを確認しています。しかし、なぜそのようなシナリオでpgpginがpswpinに沿って増加しないのかは、私の理解を超えています。
たぶんあなたのチャートは微調整されているので、pswpinはpgpginから差し引かれていますか?これをバックアップする1つのポイントは、両方のメトリックが通常ページ(/ proc/vmstat内)にあり、KB/sに変換されていることです。
編集:これはESX関連の可能性があります。私のワイルドな推測では、これはバルーニングまたは透過ページ共有(TPS)のいずれかの副作用です。 ESXのesxtopを介して分析 できますか?これが 別のesxtopガイド です。
編集:あなたのnmon統計は壊れているようです。まず、実際の指標よりも多くの列名があります(つまり、最後の列のデータがありませんpgscan_direct_dma
)。 pgpginが欠落しているだけでなく、ビジー状態のシステムに存在するはずのメトリックに-1または0の値がたくさんあります。 Pgstealとpgrotatedがありますが、時にはネガティブであり、それは不可能です。
それで、/ proc/vmstatを見てください、そこで何が起こっているのですか?また、他のツールを使用してnmon統計を確認します。