COMPANY

ブログ

ログファイルを使用したトラブルシュート

21.07.2011
by Thomas Maul

このブログでは4D Summit 2011プレクラスでThomas Maulが説明する話題の一部を紹介します。プレクラスに参加することで、参加者は4Dのシニアエンジニアからマスターレベルのスキルを学ぶことができます。

 

「サーバーの動作がとても遅くなることがある」、「サーバーが期待通りに動作しないことがある」。そのような指摘をユーザーから受けることがあります。この種の問題は最も扱いが難しいものであります。特に多数のユーザーが接続している状況では、「何をしたらこうなりましたか」と尋ねても、答えが出るものではありません。


ログをとり、その読み方や解析の方法を知ることで、私たちはこのような問題の多くについて何が起きているのかを知ったり理解したりできるようになります。さらに良いことには、サーバーの動作を監視するツールを平常時に使用することで、顧客が問題を目にする前に、潜在する問題を素早く発見し、解決することができます。

 

4D v11 SQLより、4D Serverで多種のログを取得することができるようになり、サーバーの動作や問題をオフラインで解析、理解することの助けとすることができます。プレクラスのこの部分では、この目的のために作成された4つのツールに焦点を当てて説明します。

 

4D Cache Log Analyzer

GET CACHE STATISTICコマンドを使用して得られる結果を記録し、解析するツールです。このツールによりキャッシュメモリの振る舞いを明確に観察することができます:

 

Cache log

 

このツールからはまた空きブロック、物理および仮想メモリ等のキャッシュ使用量に関する情報も得られ、アプリケーションのメモリ必要量を計算するのに役立ちます。
 

Memory

 

これらのデータを使用すればトラブルシュートだけでなく、アプリケーションのメモリ必要量も解析することができ、特定のアプリケーションで5, 10, 25, 50, 100ユーザーごとのメモリ関連設定の最適値を知ることができます。

 

4D Info Report Component 3.0

Information Report Componentは実行環境に関する重要な情報を収集するのに役立ちます。使用しているハードウェア (コンピューターのタイプ、CPU、メモリ等)、OS (例えばWindows Server R2 SP1)、4Dのバージョン、さらには使用メモリの状況やユーザー数、プロセス数などを記録します:

 

Manufacturer:                  	PowerEdge R710
Computer Kind:                 	x64-based PC
Total RAM:                     	16384 MB
Number of Processors:          	2
Processor Name:                	Intel Xeon  E5520
CPU Speed:                     	2.27 GHz
Total number of Cores:         	8
Total number of CPU threads:   	16
Operating System:              	Windows Server 2008 Standard SP1 
                                (64-bit)
Application type:              	4D Server (64-bit)
Application version:           	v12 release 2  (F0021220)

このコンポーネントはすべてのサーバーアプリケーションに含めておくべきであり、状況を解析するための第一ステップで使用されます。例えば以下のグラフは一週間のユーザー数、ユーザープロセス数、そして使用キャッシュの動作状況を示したものです:

 

Cache analysis

 

4D Pop Data Analyzer

4D Pop Data Analyzerは4Dデータファイルのサイズや内容を解析するコンポーネントです。このツールを使用してレコードの最小サイズや最大サイズ、実際のデータに基づくサイズ、テーブルのフラグメンテーション状況を知ることができます。

 

4D Pop Data Analyzer

 

Network Log Analyzer

4D Serverのネットワークログを取得すると、あっという間に大量のログデータが書き出されます。ここから単純に問題点を探し出すことは困難です。Network Log Analyzerはとても遅い、あるいはとても大きなパケットなどの例外に焦点を当てています。

 

Network Log Analyzerはすべてのパケットを5分間隔でグループ化するので、素早く問題のありそうな部分を特定することができます:

 

Network log analyzer

 

この例では明らかにサーバーが過負荷になっています。平均応答時間は0.5から5秒の間で、一つのリクエストへの最長応答時間は113秒です。

 

ダブルクリックすると関連する処理を見ることができます:

 

Network log analyzer detail

 

パケットはかかった時間によってソートされているので、113秒かかった処理を簡単に見つけることができ、それがクエリであることが分かります。他にも時間のかかったクエリがあり、そしてSELECTION TO ARRAYに25秒かかっています。それ以外の処理は素早く行われています。User name/Process name (実在の顧客のデータであるため、上図ではこの部分が隠されています) を参照して、行われた処理を知ることができます。ダブルクリックするとこの処理を一つのプロセスに絞ることができます。問題の前後で実際何が行われたかを知ることで、多くの場合対応するソースコードを特定することが容易になります。

 

さらにこのツールを使用するとクライアントでバックログとネットワークログを統合し、並べて表示することができます:

 

Client debug log

 

 

これらのツールは4D Summit 2011 プレクラスの参加者に配布され、その使用方法が詳細に説明されます。ぜひこのマスタークラスにご参加ください。

RSS 0 個のコメント

コメントする

  • Web page addresses and e-mail addresses turn into links automatically.
  • You may use [view:viewname] tags to display listings of nodes.
  • Each email address will be obfuscated in a human readable fashion or (if JavaScript is enabled) replaced with a spamproof clickable link.

More information about formatting options