#15　分析事例

ES/1 CSシリーズ

分析事例

メモリ

突然のサーバー不調の原因分析

開く

今回は、BIサーバーが月に1,2回ほど突然に不安定な状態になり、困っていると相談を受けた事例をご紹介します。

相談内容

サーバーの不調の発生タイミングはピーク日や特定の曜日といった規則性はない
事象が発生するとサーバーへのリモート接続も不可能になり調査ができず、OSリブートを緊急で実施するしか対処方法がない
メモリが怪しいと考えているものの自社での原因特定が難しく、性能データから原因を特定してほしい

1．ES/1で取得した性能データから事象発生日の状況を確認し判明したこと

一時的にページアウトが3500ページほど発生はしているが、物理メモリの空きは3GB以上あり、物理メモリが不足している状態ではない
通常は、プログラムAとプログラムBがメモリを互いに使用している状況
事象発生時は、プログラムA、Bともにメモリ使用量が大きく、ページファイル使用率が100%に達している

2．別の視点から見た結果、物理メモリサイズを超えて仮想メモリ量を使用し続けている事が判明

3．ページアウトの発生状況からページファイル使用率が100%に達している事が気になり、ページファイルサイズを確認

ページファイルの設定は、OS自動になっているにも関わらず物理メモリサイズに対して8GBしか割り当てられていない
先ほど気になった、ページアウト数とページファイル使用率の関係が少し見えてきた

チューニング

物理メモリを追加するのではなく、ページファイルサイズを大きくすることを提案

通常であれば物理メモリの追加を検討するところですが、最近のディスク性能は大幅に改善されているため、ページアウトによるディスク負荷増加による性能影響を考慮して、今回はページファイルサイズを大きくすることを提案しました。

下図は、ページファイルサイズを3倍にした後のグラフです。

このグラフで、チューニング前は、ページファイル使用率が100％にあたるラインは、チューニング後は33％のラインになります。このラインを超えている日は、プログラムがそれを超えてメモリを要求していた事が分かります。チューニング前であれば、使用率が100％に張り付くところ、ページファイルサイズを大きくしたことで100％に達していない事が確認できます。

チューニング後

以前のような突然のOSの不調はなくなり、I/Oに目立った増加もありませんでした。

まとめ

今回はメモリ増強をせずページファイルサイズを大きくしたので、コストをかけず問題を解決できた事例でした。
サーバーをリプレースする際に、設定値が見直されることなくそのまま引き継がれ、サーバーのリプレースを繰り返すうちに、設定値が最適値とかけはなれてしまうことがあるかと思います。業務量、データ量は多くなる傾向ですから、適宜、設定値を見直すことが必要です。今回の記事が今までは問題とならなかった設定値を見直すきっかけになりましたら幸いです。

執筆者

Y.I.　

営業技術本部技術サービス統括部技術サービス2部　部長

主にCS製品を利用したリソース、ミドルウェア情報からの性能管理サポートに従事
近年は、上記に加えAPM製品を利用したユーザー体感レスポンスやアプリケーション視点も加えた性能管理サポートにも従事

#15 分析事例