基本的に、私の質問は Solaris 仮想マシンのメモリ割り当てに関するものです。
私は 2 台の Solaris 8 仮想マシン上で、いくつかの古い Sun ONE 6 Java Web サーバーを実行しています。使用されているスワップ領域は適度な量であることがわかりますが、これがこれらのマシンに RAM を追加する必要があることを示しているかどうかはよくわかりません。
サービスのピーク時間 (通常は午前中) には、これらのサーバーがホストする Web アプリケーションの応答時間は最大 11 秒まで跳ね上がります (比較的単純な Web ページの読み込みアクションには多少不利です)。ピーク時間以外の平均応答時間は約 5 秒です。
以下の出力から、これらのマシンの RAM 使用量について何を推測できますか? この情報は十分でしょうか? それとも、サーバーのメモリ不足を排除するために他のコマンドを実行する必要がありますか?
最後に、セットアップの中核には Java アプリケーションがあるため、次の点についても検討しました。
1) ヒープのオブジェクト割り当てをトレースして、潜在的なメモリ リークを検出します。
2) パフォーマンス プロファイリングを実行して、これがネットワークの遅延に関連しているかどうかを確認します。アプリケーションが単一の Oracle データベースと通信するため、これについて言及しましたが、ネットワーク セグメンテーションの観点から見ると、それらは非常に近いため、これが当てはまるとは思えません。
皆様から提供していただけるあらゆる洞察とフィードバックに感謝します。
お時間を割いてご協力いただきありがとうございました。
サーバー1:
40 processes: 38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle, 0.4% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
12676 webservd 112 29 10 616M 242M sleep 103:37 0.48% webservd
18317 root 1 59 0 23M 19M sleep 67:24 0.08% perl
9479 support 1 59 0 6696K 2448K cpu/1 0:11 0.05% top
8012 root 10 59 0 34M 704K sleep 80:54 0.04% java
1881 root 33 29 10 110M 13M sleep 33:03 0.02% webservd
7808 root 1 59 0 83M 67M sleep 7:59 0.00% perl
1461 root 20 59 0 5328K 1392K sleep 6:49 0.00% syslogd
1691 root 2 59 0 27M 680K sleep 4:22 0.00% webservd
24386 root 1 59 0 15M 11M sleep 2:50 0.00% perl
23259 root 1 59 0 11M 4240K sleep 2:42 0.00% perl
24718 root 1 59 0 11M 5464K sleep 2:29 0.00% perl
22810 root 1 59 0 19M 11M sleep 2:21 0.00% perl
24451 root 1 53 2 11M 3800K sleep 2:18 0.00% perl
18501 root 1 56 1 11M 3960K sleep 2:18 0.00% perl
14450 root 1 56 1 15M 6920K sleep 1:49 0.00% perl
サーバー2
42 processes: 40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle, 0.4% user, 0.8% kernel, 0.0% iowait, 0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
5607 webservd 74 29 10 284M 173M sleep 20:14 0.21% webservd
15919 support 1 59 0 4056K 2520K cpu/1 0:08 0.09% top
13138 root 10 59 0 34M 1952K sleep 210:51 0.08% java
13753 root 1 59 0 22M 12M sleep 170:15 0.07% perl
22979 root 33 29 10 112M 7864K sleep 85:07 0.04% webservd
22930 root 1 59 0 3424K 1552K sleep 17:47 0.01% xntpd
22978 root 2 59 0 27M 2296K sleep 10:49 0.00% webservd
13571 root 1 59 0 9400K 5112K sleep 5:52 0.00% perl
5606 root 2 29 10 29M 9056K sleep 0:36 0.00% webservd
15910 support 1 59 0 9128K 2616K sleep 0:00 0.00% sshd
13106 root 1 59 0 82M 3520K sleep 7:47 0.00% perl
13547 root 1 59 0 12M 5528K sleep 6:38 0.00% perl
13518 root 1 59 0 9336K 3792K sleep 6:24 0.00% perl
13399 root 1 56 1 8072K 3616K sleep 5:18 0.00% perl
13557 root 1 53 2 8248K 3624K sleep 5:12 0.00% perl
答え1
サーバーの RAM が不足しているかどうかを確認するには、vmstat コマンド出力の sr 列が便利な指標になります。vmstat 10 10参照期間とピーク期間 (10 秒ごとに 10 サンプル) 中に何かを実行し、出力を投稿するだけです。swap -s出力も役立ちます。 vmstat の代わりに、次を実行することをお勧めします。sar -g 5 5
いずれにしても、"top" 出力によると、server2 は RAM が不足しているようです。 Solaris には、仮想メモリと物理メモリのコンシューマーを特定するのに役立つ可能性のある、top に似たサポートされたコマンドがあります。
prstat -s rss -n 5
prstat -s size -n 5
答え2
これらのスナップショットで私が注目したのは次の点です。
- 多数のPerlプロセス
- 複数の webservd プロセス
- マシンは98%と99%がアイドル状態です
これらの事実から、次のような疑問が生じます...
- perl プロセスの数を減らすことはできますか?
- スレッド化された Web サーバー モデルに切り替える方法はないのでしょうか?
- マシンにストレスがかかっているとき、システムトップはどのように見えるでしょうか?
最後に、これを追跡するために次の操作を行います。
- Wireshark などのネットワーク スニファーを使用して、HTTP プロセスのどの部分が実際に遅延しているかを確認します。接続ですか? ページの配信ですか? ページの動的部分の配信ですか?
- HTTP ストレス ツールを入手し、Web サーバーにストレスを与えて、その反応を確認します。vmstat と top を使用して応答を監視します。これを行うには、ターミナルで screen を使用するのが便利です。
幸運を！
答え3
メモリ使用量を追跡する最も簡単な方法は、システム アカウンティングだと私はいつも思っています。使用量は大きく変動する可能性があるため、使用パターンを確認するには少なくとも 1 週間は確認することが重要です。
「sys」crontab を編集すると、スクリプト /usr/lib/sa/sa1 のコメント アウトされた実行がいくつか表示されます。実行頻度によって、保存されるアカウンティング データの時間解像度が決まります。私は通常、24 時間 365 日のシステムでは次のようにします。
20,40 * * * * /usr/lib/sa/sa1
これにより、/var/adm/sa に月ごとの統計情報が保存されます。次に、sar を使用して、そこに保存されている任意の日のメモリ統計情報をダンプします。3 日が私にとってピークの日だったとします。
sar -f /var/adm/sa/sa03 -g
最も注目すべき列は pgscan/s です。この数値が長期間にわたって 200 を超える場合、システムのメモリが不足しています。100 の場合、メモリを増やすことでメリットが得られる可能性はありますが、パフォーマンスの低下はそれほど大きくありません。最近ではディスク スワップがメモリよりもずっと遅いため、短期間のジャンプを除いて 0 に維持するようにしています。