図面の設計を行うシステムのDBサーバーで、原因不明のままOSがフリーズするという現象が発生し、利用部門からのクレームが多く寄せられていました。

従来使用していた監視ツールの情報を元に分析を試みましたが、原因が分からないままでした。

そこでIIMにご依頼いただきES/1による性能分析を行わせていただきました。

まずは、リソースの状況を確認したところ、OSのフリーズが起きた時間帯で、メモリ内の非ページプールの使用量が124MBに近くなっていることが分かりました。

非ページプールとは、メモリ内のページアウトが行われない領域で、このサーバーでの非ページプールの上限値は128MB（※）となっており、Windowsの特性上この上限値に達するとOSがダウンする可能性があります。

（図1：非ページプール使用量の状況）

※通常、32Bbit Windowsの非ページプール上限値は通常256MBですが、こちらのお客様ではWindowsのオプション設定により上限値を128MBに設定されていました。

さらに分析を進めると、フリーズが起きた時間帯に、Oracle接続セッション数が400近くになっていることが分かりました。

（図2：Oracle接続セッション数の状況）

上記の状況より、Oracleのセッション数が増加し400セッションに近づくと、メモリの非ページプールの使用量が不足し、OSがフリーズしていたと考えられ、その旨をお客様に報告いたしました。

IIMの報告を受け、暫定的にセッション数を制限するために、システム利用者に対して同時に開くオンライン画面を1利用者あたり2画面までというルールを徹底し、セッション数が増えないようにしました。

その後、開発部に依頼し、画面を開いたままの状態になるとセッションを切る、というアプリケーションの改訂を行いました。

アプリケーションの改訂をおこなった結果、非ページプールの使用量を減らすことができOSのフリーズが解消できました。

自社で半年かけて分からなかった問題点が迅速に特定できES/1の必要性を確認いただけました。