この記事は Alibaba Cloud の日本サイト の環境（ドキュメントやアカウント、そのアカウントでの検証結果）に基づいて記載しています。 日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります（そのほとんどは国際サイトの方が日本サイトよりも多機能になっている）。記事の内容は適宜最新化する予定です。
トラブルシューティングの最終手段といえばメモリダンプですが、Alibaba Cloud ECSでは利用可能でしょうか？ 前回、中途半端に終わったテストについて実施結果を追加しました。
目次
1. 公式のドキュメントセンター
ドキュメントセンターで”メモリダンプ”をキーワードに検索します。 参考になりそうなのはECS Windows Serverの仮想メモリを構成する方法 – Elastic Compute Serviceの1件のみとなりそうです。 このドキュメントを確認してみます。
ポイントは２つです。
- ECSのWindows Sererでは”仮想メモリ”は無効となっている
- Blue Screen発生時にメモリダンプ出力するには”仮想メモリ”を事前に有効としておく
ほかにもパフォーマンス観点では仮想メモリを使用しないことを推奨していること、メモリが必要な場合はアップグレードすることなどが記載されています。
しかし、既定で仮想メモリが無効であることはシステム導入時にはしっかりと意識して設計する必要がありますね。 少なめのメモリの検証環境でも実際の本番環境でもメモリ枯渇した場合の動作の想定とその場合の対処を考えておく必要があります。（後述しますがWIndows Server 2016では仮想メモリは既定で有効でした）
2. ECSの仮想メモリ構成
ECSのWindows Serverについて仮想メモリの構成を実際に確認してみます。
公式ドキュメントの記載から”ページングファイルなし”になっているかと予想したのですが、実際の設定は”すべてのドライブのページング ファイルサイズを自動的に管理する”ということで、仮想メモリは有効になっていました。
また仮想メモリの割り当てサイズは”1227″MBです。
また、メモリダンプの設定は”自動メモリ”であることも確認出来ました。この設定ですとカーネルメモリダンプしか取得できないので、”完全メモリダンプ”への変更が望ましいですね。 もちろん、メモリダンプを解析する必要がない（または解析するサポート体制を持っていない、解析するツール・スキルを持っていない）場合は気にしなくてもよい話です。
なお、”デバッグ情報の書き込み”のオプションは以下の5つになります。 メモリダンプの解析を想定している場合は”完全”を選んでおきましょう。
| メモリダンプの種類 | ダンプファイルサイズ | 保存方法 |
| 完全 | 物理メモリ＋300MB | 上書き |
| アクティブ | OS稼働時のメモリ空間に依存 | 上書き |
| カーネル | OS稼働時のメモリ空間に依存 | 上書き |
| 最小 | 64bit Windowsで256KB | 新規 |
| 自動 | OS稼働時のメモリ空間に依存 | 上書き |
なお、確実にメモリダンプを取得したい場合は、メモリダンプ専用のドライブを追加することを推奨します。 既定のシステムドライブ（WindowsでいうとC:ドライブ）の場合、空き領域が無い場合に失敗するケースもあるためです。
3. ”完全メモリダンプ”に変更する
公式ドキュメントの記載内容と異なり仮想メモリは既定で有効でした。 ”完全メモリダンプ”に変更します。
コントロールパネル＞システムとセキュリティ＞システムから”システムの詳細設定”をクリックします。
タブ”詳細設定”から起動と回復の”設定”をクリックします。
”完全メモリダンプ”に変更します。
変更後はOSの再起動が必須となります。
OS再起動後、構成を確認します。 仮想メモリは変更前の”1227MB”から”2304MB”に変わりました。 ECSとして搭載しているメモリの2GBにあわせてストレッチされたようですね。
メモリダンプ設定も”完全メモリダンプ”に変わりました。
4. メモリダンプをテストする
以下のドキュメントを参考にダンプキー（右Ctrl+Scroll Lock+Scroll Lock)を有効にし、コンソールのVNCから実行しますが強制的なCrashに成功しません。
https://blogs.technet.microsoft.com/askcorejp/2014/08/10/339/
考えられる原因としては、VNC接続の場合、キーボードレイアウトが”標準 PS/2キーボード”となっており、日本語キーボード環境からScroll Lockが発行出来ていない可能性です。
まず、VNCコンソールからキーボードを確認します。
コマンドプロンプトから”msinfo32.exe”を実行します。 ”標準 PS/2キーボード”となっていることが確認できます。 いわゆる英語キーボードです。
また、ソフトウェアキーボードを利用し、キーの入力状況を確認します。
ソフトウェアキーボードを起動した状態で物理キーボードのキーを押下すると、対応するキーの色が変わります。 Ctrlは反応しますが、SclLKは反応しません。この状況ではCtrl+SclLK+SclLKは実行できないというとになります。
デバイスマネージャからキーボードをJP106に変更したり、言語の設定からキーボードのレイアウトを日本語キーボードに変更したり、色々と試行錯誤しましたが強制的なメモリダンプは実行出来ませんでした。
本当は英語キーボードで試すとよいのですが手元にないためテスト出来ません。
NotMyFault を利用したダンプ
あきらめてツールを利用したダンプでテストすることにします。
以下のサイトからツールをダウンロードし、任意のフォルダに展開します。
https://docs.microsoft.com/ja-jp/sysinternals/downloads/notmyfault
Windows Server 2016条にc:\memdumpディレクトリを作成し、そこに展開したツールを配置します。
コマンドプロンプトから”NotMyFault64.exe /crash”を実行します。
無事？、Crashさせることが出来ました。
自動的に再起動されるのを待ち、サインインします。
強制的にシステムが停止されたためサインイン時にシャットダウンイベントの追跡ツールから確認のダイアログが表示されます。
ダンプファイルは%SystemRoot%\MEMORY.DMPに出力される設定です。エクスプローラから確認します。
”MEMORY.DMP”ファイルが生成されたことが確認出来ました。 サイズも2GBと完全メモリダンプの期待通りの動作を確認出来ました。
5. まとめ
キー入力によるメモリダンプは実行できませんでしたが、ツール”NotMyFault”を利用したメモリダンプは確認出来ました。
Windows Serverを利用する場合はトラブル時の調査に備えて”完全メモリダンプ”に設定変更すること、また、事前にNotMyFaultツールも配置しておくとよいでしょう。
取得したメモリダンプの解析についてはまとまった時間を確保して別途解説したいと思います。
以上
