Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
ツールの利用ポイント †
監視・プロファイル ツールやサポートツールは、「サーバーの監視」のフローチャート中の
- 原因の把握、解決策の決定
- サポートを活用して解決策を決定する。
の部分で使用します。
障害対応のノウハウと利用可能なツールを把握しておくことで、
- 問題発生時に、セルフ・サポートが可能になります。
- また、セルフ・サポートが困難な場合もサポート・エンジニアとの連携がスムーズになります。
- サポート・エンジニアと連携可能な範囲はどこか？
- サポート・エンジニアに提供してもらえる情報は何か？
- サポート・エンジニアに提供すべき情報は何か？
監視系 †
各種リソース †
Windowsタスクマネージャ †
WindowsOS付属の簡易プロセス監視ツール。
プロセス監視 †
パフォーマンスモニタ †
WindowsOS付属のプロセス監視ツール。
Process Monitor †
プロセス監視（各種イベント監視）
Process Explorer †
プロセス監視 / ハンドル数調査 / ユーザモードダンプ取得
- プロセスツリー、タイプ、使用しているDLL、ハンドル、
イメージ（EXE）、性能情報、TCP/IPソケット、.NETバージョンなどの
様々な情報の確認できる。また、使用しているDLL、ハンドルの検索機能も持つ。
- プロセスの開始・終了、ユーザ・モード・プロセス・ダンプの取得も可能（ハングダンプ相当）。
- GDIオブジェクトの数、また、GDIオブジェクトが消費するプールの上限値を確認できる。
（ただし、これにはWinDbgをインストールして、シンボルサーバを設定する必要がある）。
※ シンボルサーバにアクセスするためにはWindbgが必要になるので
Handle †
ハンドル数調査
DB監視 †
SQL Server系
ツール †
- Management Studio
- クエリ・アナライザ → クエリ・エディタ
- SQLプロファイラ（SQLトレース）
- インデックスチューニングウィザード → データベース・エンジン・チューニング・アドバイザ
- システムテーブル/動的管理ビュー
- レポート（各種 標準レポート、Performance Dashboard Reports）
ログ †
- エラーログ
- 起動時の-T オプションでトレースフラグを設定。
- DBCC TRACESTATUSで確認可能。
- トレース ログ
T-SQLファイルを作成し実行する（sqlcmdから実行する等）。
- ブロッキング情報
- ブロッキング情報（sys.dm_exec_request動的管理ビュー）
T-SQLファイルを作成し実行する（スケジューラでsqlcmdから実行する等）。
- ブロッキング情報（sp_blocker_pss80ストアド）
- ブロッキング（トレースのblocked process reportイベント）
T-SQLファイルを作成し実行する（sqlcmdから実行する等）。
- スケジューラ情報（sys.dm_os_schedulersビュー）
T-SQLファイルを作成し実行する（スケジューラでsqlcmdから実行する等）。
- 長時間実行クエリ、ストアド情報（sys.dm_exec_query_stats、_sql_text動的管理ビュー）
T-SQLファイルを作成し実行する（スケジューラでsqlcmdから実行する等）。
- データベース・ミラーリング情報
いずれも、T-SQLファイルを作成し実行する（スケジューラでsqlcmdから実行する等）。
- エンドポイントとコネクション情報（sys.database_mirroring_endpoin、_connectionsカタログビュー）
- プリンシパルとミラー情報（sys.database_mirroringカタログビュー）
- 監視サーバ情報（sys.database_mirroring_witnessesカタログビュー）
- MSDTC系
- MSDTCトレース、GUIとレジストリから設定。
- CommunicationManager?エラー・トレース、レジストリから設定。
ネットワーク監視・プロファイル †
ツール †
- Wireshark
- パケットキャプチャとパケット分析
- 管理：マクロ分析、プロファイル：ミクロ分析
ログ †
- Wiresharkなどのネットワークモニタツール
- 負荷分散装置のログ
- ファイアウォール装置のログ
- スイッチのログ
システム情報収集 †
Microsoft Product Support Report（MPS_Report） †
環境変更時や障害発生時の各種ログの収集ツール
（各製品毎のエディションが用意されている）
デバッグ ツールセット †
Debugging Tools for Windows †
ライブ・デバッグ・ダンプ取得・分析 †
CDB †
NTSD †
KD †
,etc. †
IISライブ・デバッグ、ダンプ取得・分析 †
ADPlus †
アンマネージド・ヒープ解析 †
UMDH：User Mode Dump Heap
ダンプ系 †
ユーザモード プロセスダンプ †
UMPD（User Mode Process Dumper ） †
ユーザモードプロセスダンプ取得
WER（Windows Error Reporting） †
Windowsエラーレポートの情報を取得
ダンプサマリ †
Dumpchk.exe †
メモリ ダンプ ファイルの簡易検証
Debug Diagnostics †
ユーザモードプロセスダンプの取得・分析（サマリの生成）
プロファイラ †
ユーザモード †
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オブジェクト
参考資料 †
パフォーマンスカウンタ †
メモリ空き容量 †
未使用ページリスト、ゼロページリスト、スタンバイ リストの合計
- Memory\Available Bytes:
バイト単位の空きメモリのサイズ
- Memory\Available Kbytes:
キロバイト単位の空きメモリのサイズ
- Memory\Available Mbytes:
メガバイト単位の空きメモリのサイズ
- Memory\Pool Paged Bytes:
ページ プールのサイズ
- Memory\Pool Nonpaged Bytes:
非ページ プールのサイズ
- Memory\Commited Bytes:
コミットされた仮想メモリのサイズ
メモリ使用量＠プロセス毎 †
- Process(*)\Private Bytes:
コミットされた仮想メモリのサイズ（他のプロセスと共有できない
- Process(*)\Virtual Bytes:
コミットと予約の双方の含む仮想メモリのサイズ
- Process(*)\Working Set:
使用物理メモリのサイズ（他のプロセスと共有している部分も含む）
- Process(*)\Pool Paged Bytes:
ページ プールのサイズ
- Process(*)\Pool Nonpaged Bytes:
非ページ プールのサイズ
マネージド・メモリ＠プロセス毎 †
- .NET CLR Memory\# Bytes in all Heaps:
- GCヒープに割り当てられたコミットと予約の双方の含む仮想メモリのサイズ
- Gen 0 Heap Size、Gen 1 Heap Size、Gen 2 Heap Size、および Large Object Heap Size カウンタの合計値
- .NET CLR Memory\Gen 0 heap size:
Gen 0 に割り当てられる最大の仮想メモリ サイズ（コミットと予約の双方の含む）
- .NET CLR Memory\Gen 1 heap size:
Gen 1 に割り当てられる最大の仮想メモリ サイズ（コミットと予約の双方の含む）
- .NET CLR Memory\Gen 2 heap size:
Gen 2 に割り当てられる最大の仮想メモリ サイズ（コミットと予約の双方の含む）
- .NET CLR Memory\Large Object Heap size:
Large Object Heapに割り当てられる仮想メモリ サイズ（コミットと予約の双方の含む）
- .NET CLR Memory\# Total committed Bytes:
GCによって現在予約されている仮想メモリのサイズ。
- .NET CLR Memory\# Total reserved Bytes:
GCによって現在コミットされている仮想メモリのサイズ。
ハンドルリソースリーク †
- Process(_Total)\Handle Count:
プロセス全体のオープンされているハンドル数
- Process(_Total)\Thread Count:
プロセス全体のスレッド数
- Objects\Events:
イベント数
- Objects\Mutexes:
ミューテックス数
- Objects\Processes:
プロセス数
- Objects\Sections:
セクション数
- Objects\Semaphores:
セマフォ数
- Objects\Threads:
スレッド数
ハンドルリソースリーク＠プロセス毎 †
- Process(*)\Handle Count:
対象プロセスでオープンされているハンドル数
- Process(*)\Thread Count:
対象プロセスのスレッド数
ハンドルリークはカーネルモードメモリの圧迫につながる。
マネージド・ソース・リーク＠プロセス毎 †
- .NET CLR LocksAndThreads?\# of current logical Threads:
Heap（パフォーマンス オブジェクト） †
- Heap\Committed Bytes:
ヒープマネージャによるのコミットサイズ
- Heap\Allocs - Frees:
ヒープの割り当て解放数の差
以下の設定で有効になる。
参考資料 †
ページングの分析はMemory\Page Read/secを参照する。
ヒープ解析 †
アンマネージド †
UMDH：User Mode Dump Heap
マネージド †
ダンプ解析 †
アンマネージド †
マネージド †
カーネル メモリ スペース †
一般ユーザーのために設計されていないことに注意してください。カーネル・デバッガに既に精通しておりウィンドウズの内部についての知識を持っており、カーネル・モード・プログラムをデバッグする基礎的な技術を持っているユーザを想定しています。
カーネル オブジェクトのハンドル †
タスクマネージャ †
パフォーマンスカウンタ †
Sysinternals Handle †
メモリ プール（ページ プールと非ページ プール） †
タスクマネージャ、パフォーマンスカウンタ †
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?の１番目：「標準ヒープの容量」のサイズ
SharedSection?の２番目：「インターラクティブ・ヒープの容量」のサイズ
- ターミナル・サービスのデクストップ・ヒープが枯渇している場合
ターミナル・サービスでは「全デスクトップ・ヒープの容量」のサイズが小さめに設定されてている。
これを拡大すると、ターミナル・サービスの同時接続可能セッション数を圧迫したりする可能性がある。（カーネル・メモリ領域を圧迫するため）
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
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
