「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ツールの利用ポイント †
監視・プロファイル ツールやサポートツールは、「サーバーの監視」のフローチャート中の
- 原因の把握、解決策の決定
- サポートを活用して解決策を決定する。
の部分で使用します。
障害対応のノウハウと利用可能なツールを把握しておくことで、
- 問題発生時に、セルフ・サポートが可能になります。
- また、セルフ・サポートが困難な場合もサポート・エンジニアとの連携がスムーズになります。
- サポート・エンジニアと連携可能な範囲はどこか?
- サポート・エンジニアに提供してもらえる情報は何か?
- サポート・エンジニアに提供すべき情報は何か?
システム情報収集 †
監視系 †
各種リソース †
こちらを参照。
Windowsタスクマネージャ †
WindowsOS付属の簡易的な各種リソース監視ツール。
プロセス監視 †
Process Monitor †
プロセス監視(各種イベント監視)
Process Explorer †
プロセス監視 / ハンドル数調査 / ユーザモードダンプ取得
- プロセスツリー、タイプ、使用しているDLL、ハンドル、
イメージ(EXE)、性能情報、TCP/IPソケット、.NETバージョンなどの
様々な情報の確認できる。また、使用しているDLL、ハンドルの検索機能も持つ。
- プロセスの開始・終了、ユーザ・モード・プロセス・ダンプの取得も可能(ハングダンプ相当)。
- GDIオブジェクトの数、また、GDIオブジェクトが消費するプールの上限値を確認できる。
(ただし、これにはWinDbgをインストールして、シンボルサーバを設定する必要がある)。
※ シンボルサーバにアクセスするためにはWinDbgが必要になるので
Sysinternals Handle †
このプログラムの GUI ベースのバージョンは、Process Explorer
アプリケーション固有ログ †
例えば。
DB監視 †
WAS監視 †
クラスタ監視 †
クラスタログ
ネットワーク監視・プロファイル †
ツール †
- Wireshark
- パケットキャプチャとパケット分析
- 管理:マクロ分析、プロファイル:ミクロ分析
ログ †
- ネットワークモニタツール
- 負荷分散装置のログ
- ファイアウォール装置のログ
- スイッチのログ
デバッグ ツールセット †
Debugging Tools for Windows †
Windows Performance Recorder (WPR) †
トレースデータを採取するコンポーネント
Windows Performance Analyzer (WPA) †
トレースデータを GUI で表すコンポーネント
ライブ・デバッグ・ダンプ取得・分析 †
CDB †
NTSD †
KD †
,etc. †
IISライブ・デバッグ、ダンプ取得・分析 †
ADPlus : Auto Dump+
アンマネージド・ヒープ解析 †
UMDH:User Mode Dump Heap
プロファイラ †
ユーザモード †
Visual Studio †
- Visual Studioプロファイラ
Visual Studio 2010 Premium / Ultimate付属のマネージド・コード・プロファイラ
CLR Profiler †
マネージド・コード・プロファイラ(メソッドの呼出回数・時間、メモリ割当・消費、オブジェクト接続・ルート追跡)
マネージド・コード・プロファイラ(ライブ・デバッグ & ダンプ分析)
Managed Stack Explorer †
マネージド・コード・プロファイラ(スレッド ダンプ)
C#アプリでデットロックぽい問題が発生したと聞いて.NETでのスレッドダンプ調べてみました。
元ネタはここです。
http://stackoverflow.com/questions/190236/how-do-i-make-a-thread-dump-in-net-a-la-jvm-thread-dumps
Managed Stack Explorerを使う方法とWinDbgを使う方法紹介されてますが、
WinDbgはデバッカだし、簡単なManaged Stack Explorerを使う方法について書いてみたいと思います。
DevPartner? Studio †
マネージド・コード・プロファイラ
その他のマネージド・コード・プロファイラ †
Rational PurifyPlus? for Windows †
アンマネージドコードプロファイラ
カーネルモード †
Driver Verifier †
カーネルモードドライバのデバッグ/メモリ分析
Memory Pool Monitor †
カーネルモードドライバのメモリ分析
Desktop Heap Monitor †
デスクトップ・ヒープのメモリ分析
メモリ・リーク †
タスクマネージャ †
「パフォーマンス」タブ †
【】内はVista以降
- 合計(システム)
リソースの数
- ハンドル
- スレッド
- プロセス
- 【起動時間】
- 【ページ・ファイル、コミット】
- 物理メモリ
物理メモリのサイズ
- 合計
- 利用可能【空きメモリ】:
- 利用可能な物理メモリ(空き) → Memory\Available Bytes
- 未使用ページリスト、ゼロページリスト、スタンバイ リストの合計
- システムキャッシュ【キャッシュ済み】:
以下の次の 5 種類のワーキングセットの合計
- システム キャッシュ ページ
- ページ プール
- Ntoskrnl.exe 内のページング可能なコードとデータ
- デバイス ドライバ内のページング可能なコードとデータ
- システム マップドビュー
- コミット チャージ
仮想メモリのサイズ → Memory\Commited Bytes
- カーネル メモリ
カーネル モードで使用しているメモリのサイズ
「プロセス」タブ †
- 仮想メモリ
- 仮想メモリサイズ【メモリ - コミット サイズ】
仮想メモリのサイズ(非共有メモリの仮想メモリの使用量)
= コミットされたサイズ、つまりプライベートバイト → Process(*)\Private Bytes
- ページ プール【メモリ - ページ プール】
プロセスのページ プールのサイズ
- 非ページ プール【メモリ - 非ページ プール】
プロセスの非ページ プールのサイズ
- 物理メモリ(ワーキング セット)
以下のメモリ使用量は、トリミング可能なスペースも含めたワーキング セット全体のサイズを表示しており、他のプロセスの実行状態によって増減するので仮想メモリ(メモリ使用状況)を確認するための値としては適切ではない。
- メモリ使用量【メモリ - ワーキング セット】
当該プロセスの物理メモリ使用量【ワーキング セット】のサイズ
- 最大メモリ使用量【メモリ - ピーク ワーキング セット】
当該プロセスを起動してから現在までにおける、物理メモリ使用量【ワーキング セット】の最大値
- メモリ デルタ【メモリ - ワーキング セット デルタ】
プロセスによって使用される物理メモリ使用量【ワーキング セット】使用量の変化量。
- 【メモリ - プライベート ワーキング セット】
プロセスが使用しているワーキング セットのうち、
他のプロセスと共有できない(=トリミングできない)容量だけを表すサブセット
※ XP、2003には存在しない。
- リソース
- ハンドルの数
- スレッドの数
- USERオブジェクト
- GDIオブジェクト
参考資料 †
こちらを参照。
ヒープ解析 †
アンマネージド †
UMDH:User Mode Dump Heap
マネージド †
ダンプ解析 †
アンマネージド †
マネージド †
カーネル メモリ スペース †
一般ユーザーのために設計されていないことに注意してください。カーネル・デバッガに既に精通しておりウィンドウズの内部についての知識を持っており、カーネル・モード・プログラムをデバッグする基礎的な技術を持っているユーザを想定しています。
カーネル オブジェクトのハンドル †
タスクマネージャ †
パフォーマンスカウンタ †
Sysinternals Handle †
カーネル オブジェクトのハンドル(リソースリーク)確認
このプログラムの GUI ベースのバージョンは、Process Explorer
メモリ プール(ページ プールと非ページ プール) †
タスクマネージャ、パフォーマンスカウンタ †
Memory Pool Monitor ユーティリティ (Poolmon.exe) †
ページ プールと非ページ プール、およびターミナル サービス セッション用に
使用されるメモリ プールからのメモリ割り当てに関してOSが収集するデータを表示する。
これによりカーネルモードで動作するモジュール(ドライバ)のリーク問題を検出可能(必要に応じてgflagsを設定することで割り当ての際に、ドライバをある程度識別可能なTagが付与される)。
WinDbg+Kdの!poolused拡張コマンド †
Driver Verifier †
プール・トラッキング機能を有効にした状態で(プールトラッキング機能は負荷があるので、本番に適用する場合は検証が必要)
カーネル メモリ スペースをダンプ出力し、これを分析することでカーネルドライバのメモリ・リークを確認する。
Sysinternals Notmyfault †
基本的にはブルースクリーンを発生させるためのツールであるが、この他にも、指定した増分値で非ページ プールまたはページ プールのいずれかにリークを発生させるオプションがある。
Desktop Heap Monitor †
Desktop Heap Monitorで、Service-0x0-3e7$\Default の情報が、Session 0 へログインしないと確認できない件。
Windbg+LiveKd?の!dskheap拡張コマンド †
チューニング方針 †
当該デスクトップのUsed Rateの合計が100%以下であれば他のデスクトップに影響を与えることは無い。しかし、余裕を持たせるため、当該デスクトップのUsed Rateの合計は、50-70%以下になるようにする。
チューニング方法 †
- 領域のサイズ変更を伴わないチューニング
- USERオブジェクトなどのリークがあった場合は対応する。
- 例外的に、サーバのSession0のインタラクティブ・ヒープが枯渇している場合
サーバ上でサービスがLocalSystem? アカウントで実行されていて、スタートアップ オプションの [デスクトップとの対話をサービスに許可] チェック ボックスがオンに(→ SERVICE_INTERACTIVE_PROCESS flag を含んでいる)なっているサービスでは、"Session0\Winsta0\Default"(インターラクティブ・ヒープ)が使用されるため、ここがリークする可能性がある。対応:必要に応じて、対話の許可を外すか、実行アカウントに任意のユーザアカウントを選択する。
- サーバのSession0のノン・インタラクティブ・ヒープが枯渇している場合
- 同時実行サービス数が多い
起動の度にウィンドウ・ステーションとセッション、対応するノン・インターラクティブ・ヒープが新規作成されるためノン・インターラクティブ・ヒープ用の残領域を使い切る場合がある。
なお、Vista以降では、この問題は発生しない(自動的にサイズの拡張が行われる)。対応:必要に応じて、「全デスクトップ・ヒープの容量」のサイズを大きくする。以下のレジストリ値の設定を変更する(MB単位)。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Control\Session Manager\Memory Management\SessionViewSize?
- ユーザサービスから多くのプロセスを起動しているシステム
子プロセスは親プロセスの設定を継承するため、同一のウィンドウ・ステーションとセッション、対応するノン・インターラクティブ・ヒープが使用される。
このため、サービスから新たなプロセスを起動した場合、当該ノン・インターラクティブ・ヒープを使い切る場合がある。
対応:必要に応じて、「ノン・インターラクティブ・ヒープの容量」のサイズを大きくする。以下のレジストリ値のSharedSection?の3番目の値の設定を変更する。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Control\Session Manager\Memory Management\SessionPoolSize?
SharedSection?の1番目:「標準ヒープの容量」のサイズ
SharedSection?の2番目:「インターラクティブ・ヒープの容量」のサイズ
- ターミナル・サービスのデクストップ・ヒープが枯渇している場合
ターミナル・サービスでは「全デスクトップ・ヒープの容量」のサイズが小さめに設定されてている。
これを拡大すると、ターミナル・サービスの同時接続可能セッション数を圧迫したりする可能性がある。(カーネル・メモリ領域を圧迫するため)
USERオブジェクト、GDIオブジェクト †
- USERオブジェクト:デスクトップ・ヒープを消費
- GDIオブジェクト:ページ プール、セッション プールを消費
タスクマネージャ †
Sysinternals Process Explorer †
GDIオブジェクトの数、また、GDIオブジェクトが消費するプールの上限値を確認できる(ただしWinDbgをインストールして、シンボルサーバを設定する必要がある)。
Sysinternals Testlimit †
Sysinternals の Testlimitユーティリティを実行すると、USERオブジェクト、GDIオブジェクト数の制限を
簡単に確認することができる(可能な限りまUSERオブジェクト、GDIオブジェクトを作成する)。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion?\Windows
USERProcessHandleQuota?とGDIProcessHandleQuota?には、ひとつのプロセスが利用できる。
最大のUSERオブジェクトとGDIオブジェクトの数が設定されている。デフォルトの値は 其々10,000。
#1つのセッションで作成できる USERオブジェクト、GDIオブジェクト数に対する制限は 其々65,535
GDIView †
その他 †
Tags: :インフラストラクチャ, :Windows, :障害対応, :性能, :デバッグ, :ツール類