☰

Solaris SunOS 5.10 でスチール時間データにアクセスするにはどうすればいいですか?

tag-icon • tag-icon performance virtual-machines solaris performance-monitoring
Solaris SunOS 5.10 でスチール時間データにアクセスするにはどうすればいいですか?

実行している Solaris のバージョンは、top でスチール時間を報告するには古すぎると思います。この古いバージョンの Solaris でこの情報を取得する方法はありますか。基本的なバージョン情報は次のとおりです。

-bash-3.2$  uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32

私はこれらの Sun VM システムに関する専門知識をまったく持っていないので、誤解している可能性があり、この状況で必要なことを行うにはもっと良い方法があるかもしれません。Intel のメンタル モデルを適用すると、CPU が混雑しているのではないかと思いますが、それをどのように測定すればよいでしょうか。

アップデート

Intel 風の用語を許してください。基本的に、1 つのブレードで 2 つの VM を実行しています。1 つはアプリケーション サーバーで、もう 1 つはアプリケーションの SSO サポートを提供します。アプリケーション サーバーの速度が大幅に低下する瞬間があり、サード パーティの SSO アプリケーションが機能しなくなる瞬間もあります。

サイロや政治的な問題も絡んでいるため、SSO ホストや実際のハードウェア レイヤーを可視化することはできません。

私の現在の運用上の仮説は、SSO アプリケーションが異常な状態になると、CPU を大量に占有し、アプリケーション サーバーが負荷に対応するために十分な実計算時間を確保できなくなるというものです。アプリケーションの GC ログを分析したところ、次のようなエントリが目立っていました。

[Times: user=0.71 sys=1.36, real=1.47 secs]

これは通常、10 個の並列 GC ワーカー スレッドで発生し、user >> real >> sys異常な時間パターンの原因の 1 つは、十分な CPU を取得できない VM です。(スワップは行われず、システムはすべて SSD ベースであるため、IO 待機は問題になりません。)

この時点で、この理論を証明するのに役立つデータを入手する必要があります。Linux の知識があれば、top の st% をチェックするだけです。Google で検索すると、Solaris の最新バージョンでも同じことができると書かれています。問題は、Solaris の最新バージョンを実行していないことです。

答え1

ここでの本当の問題は、パフォーマンスの低下であるようです。また、Solaris 10 T1000/T2000 サーバーでは、steal-time はおそらく無意味です。

ゾーン内で実行しているかどうかを確認するには、/usr/bin/zonenameコマンドを使用します (場所は Solaris のバージョンによって異なる場合があります。、、およびも確認してください/bin) /sbin/。/usr/sbinがzonename以外の値を返す場合はglobal、ゾーン内で実行しています。

何らかの理由でコマンドにアクセスできない場合は、ゾーン内にいるかどうかを確認するために使用できるコマンドがzonenameいくつかあります。まず、以下を探します。psinit

ps -ef | grep init

initPID のプロセスが見つからない場合は1、ゾーン内にいます。zsched(IIRC) を探すこともできます:

ps -ef | grep zsched

それが自身の親である 1 つのプロセスを返す場合 (PID と PPID の両方が同じで より大きい場合1)、ゾーン内で実行されています。

ゾーン内にいる場合は、リソース制限が発生して速度が低下する可能性があります。ただし、そうなる可能性は低いです。

何それ以外ただし、サーバー上で実行されているのはどれですか? 他のゾーンも含みます。Sun T シリーズ サーバーで、ZFS ARC と、Oracle データベースなどの巨大なメモリ ページを使用するアプリケーションとのやり取りによって発生した、説明されているような非常に厄介なパフォーマンスの問題を見たことがあります。

ZFS ARCは4kのメモリページを使用するため、メモリが断片化します。そして、断片化します。全てサーバーのメモリが不足しています。サーバーがその状態になり、プロセスが大量の大きなメモリページを必要とする場合、カーネルは小さなページをまとめて大きなページにまとめる必要があり、大量のメモリを移動する必要があります。これはすべてシングルスレッドで行われます。初期のTシリーズサーバー上の単一のスレッドは遅いサーバーは、ネットワーク経由で多数の接続を処理する Web サーバーやデータベース サーバーなど、待機時間の長い膨大な数のスレッドを処理するように設計されているためです。

そのため、カーネルは長期間にわたって、メモリの小さなページを大きなページに統合するだけの作業を行うことになります。

その後、ZFS ARC は、大容量ページを使用するプロセスが完了し、断片化されたページを取得します。

あなたもまさに同じ問題を抱えているのではないかと思います。

調べるには、

echo ::memstat | mdb -k

ゾーンを実行している場合は、グローバル ゾーンで root として実行します。空きメモリが非常に少ない場合、この問題が発生する可能性があります。

これを調べるには、グローバル ゾーンから root として次の dTrace スクリプトを実行し、カーネルが時間を費やしている場所を特定します。

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

これをファイルにコピーし、hot.d実行可能ファイル ( chmod 755 hot.d) に設定して、グローバル ゾーンから root として実行します。

./hot.d

速度低下を感じたらこれを実行してください。 を出力してから10～20秒ほど実行しmatched 1 probe、その後 で中断してくださいCTRL-C。すると、多く出力の大部分は気にする必要がないものです。ただし、スタック トレース出力の最後の少数は、サンプリングされた最も一般的なものであり、カーネルが時間を費やしている場所を示します。

そうすれば、問題がどこにあるのかが明確にわかります。問題を完全に解決するには正確さが足りず、さらに調査する必要があるかもしれませんが、どこを調べればよいかはわかります。

idleまたはを含むスタック トレースが多数ある場合は、ユーザー スペースの問題が発生しています。上記の dTrace スクリプトで を に置き換えてユーザー スタックを取得すると、waitこれを特定できる可能性があります。stack()ustack()

関数名の中にスタックトレースがたくさんある場合はcoalesce、カーネルが大量のメモリページの作成に時間を費やしています。これを修正するには、メモリを解放する必要があります。おそらくZFS ARCのサイズを制限し、場合によっては大幅に制限する必要があります。膝蓋骨パフォーマンスの低下を防ぐために、いくつかのサーバーで ZFS ARC を 1 GB 未満に削減しました。

関連情報