Service Desk のパフォーマンス問題を特定する方法および問題の解決に役立つデータの種類について

Document created by Kosei_Oshita Employee on Jun 30, 2015
Version 1Show Document
  • View in full screen mode
文書番号JTEC000504
製品名Service Desk Manager
バージョン全バージョン
OSWindows

 


 

◆ 説明

 

ここでは、各サイトが(場合によっては CA サポートと協力して) Service Desk のパフォーマンスボトルネックを特定するのに役立つ情報とデータを紹介します。

 

 

◆ 解決方法


Service Desk のパフォーマンスボトルネックを特定する方法

 

Service Desk のパフォーマンス上のボトルネックを特定することは、多くの顧客にとって重要なことです。
本書では、ユーザからパフォーマンスに関する苦情を受けた場合に、 Service Desk のどの部分を調査すべきかを特定するためのデータの収集方法について詳しく説明します。
本書は、必要な手順のまとまりごとに複数のセクションに分かれています。
「パフォーマンス」に関する何らかの問題に取り組む際は、全体として次のプロセスフローに従って対処します。

 

  • 問題の定義
  • CA サポートまたはアーキテクトのレビューを受けるためのサイト固有環境データの収集
  • 「パフォーマンス問題切り分けツール」の使用
  • チューニングに関する一般推奨事項の検討

 

サポートに問題をレポートする場合、必ず最初に問題を定義してください。

 

 

問題の定義


CA サポートに提供する情報をできるだけ多く集めます。
以下の質問は、すべてが必ずしも個々の問題に関係するとは限りませんが、情報の収集に役立つ質問の例として紹介します。

 

  • ユーザに発生している、ユーザの予想と異なる現象とは、どのような現象か。
  • 問題が最初に見られたのはいつか。
  • その環境では過去にどのような変化があったか。
  • ユーザの言う「遅い」とは具体的にどういう意味か(これを定義することは非常に重要です)。
  • 製品のどの部分で問題が見られるか。また、どの部分で問題が見られないか。
  • 何人のユーザが影響を受けているか。また、影響を受けているのはどのようなユーザか。
  • 影響を受けていないのはどのようなユーザか。
  • 影響を受けているグループと受けていないグループがそれぞれどのサーバに接続しているか。
  • 問題が生じているユーザの所在場所(遠隔地にある特定のオフィスなど)はどこか。
  • 問題が生じていないユーザの所在場所はどこか。
  • どのアクセスレベルのユーザが影響を受けているか。
  • Service Desk が、 ESX サーバまたはその他の仮想環境で稼働しているどうか。
  • その環境はどのような仕様と構成になっているか。
  • CPU の数は何個か。
  • メモリの量はどれくらいか。
  • ESX サーバまたはホストマシン上でほかに何が稼働しているか (そのほかに VMware 上にインストールされているもの)。

 

「Service Desk が遅い」と述べるだけのレポートでは、 CA サポートは問題の解決を十分に支援できません。

 

 

サイト固有環境データの収集


手順 1 : Service Desk サーバ環境の詳細情報の収集 (Service Desk サポート診断用ツールのインストール)


CA サポートでは、以下のテクニカルドキュメント TEC469212 として、サポート診断用ツールを公開しています。
https://support.ca.com/irj/portal/anonymous/kbtech?searchID=TEC469212&docid=469212&bypass=yes&fromscreen=kbresults

( 日本語:Diagnostic Tool(診断ツール)についてhttp://www.casupport.jp/resources/tng/tec/usrd/036010036.htm )

このツールは、 CA サポートがパフォーマンス問題の解決を支援するために必要となる、環境その他のデータを自動的に収集するものです。

このユーティリティは、プライマリサーバ上とセカンダリサーバ上で実行する必要があります。

このほかに、「EEM」 (EIAM) のバージョン、 CA Workflow の使用について、および Service Desk Web サービス API を使用しているかどうか(使用している場合はどのように使用しているか)についても、 CA サポートに伝えてください。

また、 Service Desk に CA またはサードパーティのどのアプリケーションが統合されているかについても伝えてください。

 

 

手順 2 :データベースサーバ環境の詳細情報の収集


  1. データベースの場所(ローカルかリモートか)。

  2. DBMS のバージョンと、オペレーティングシステムのバージョンおよびパッチレベル。

Microsoft SQL サーバの場合

次の 2 つのクエリを実行して、結果を送信するよう顧客に依頼します。

select @@version

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel')


Oracle の場合
select * from v$version where banner like 'Oracle%';


Ingres の場合
$II_SYSTEM/files/config.dat および version.rel ファイルを収集します。

 

 

アプリケーションサーバにインストールされているデータベースクライアントのバージョンを確認します。
また、オペレーティングシステムやその他のデータベースなどの環境データに関する情報も、 CA サポートにとって有益です。

 

 

手順 3 :ネットワークトポロジおよび Service Desk に統合されているほかの製品 (UAPM 、NSM 、DSM など)のトポロジ情報

 

大半のサイトでは、この情報は、 PDF または Microsoft Visio ダイアグラムの形式で簡単に入手できます。


パフォーマンス問題切り分けツール


サーバ上でのリソース使用状況
サーバ上で大量の CPU/メモリまたはディスク I/O を消費しているプロセスがあるかどうかを確認します。


Service Desk ユーティリティ(一定間隔ログ記録スクリプト)
バッチファイル (Windows サーバの場合)、またはシェルスクリプト (UNIX/Linux の場合)を実行することをお勧めします。


Windows での一定間隔ログ記録のためのバッチファイル
以下の例では、 Windows 2000 Resource Kit に含まれている 「sleep」 コマンドの代わりに 「ping」 を使用しています。
Windows の 「sleep」 コマンドを使用しても問題ありません。
一定の間隔を置く方法は複数あります。たとえば、 1.1.1.1 が無効な IP アドレスであることを確認したうえで、以下のコマンドを実行します。

 

ping 1.1.1.1 -n 1 -w 540000 > nul
(約 10 分ごとに繰り返されます。)

 

pslist 、 pdm_vdbinfo 、 pdm_status 、 pdm_webstat 、 pdm_listconn 、 slstat 、 pdm_status 、および db_report の出力を取得するには、以下の手順に従います。

 

下記のようなバッチファイル pslist.bat を作成します。
この特定のバッチファイルは、日付をディレクトリ名とするディレクトリを作成し、実行するたびにファイルをその中に移動します。

@echo off
for /f "tokens=2-4* delims=/ " %%a in ('DATE /T') do set THEDATE=%%c%%b%%a
for /F "tokens=2-4 delims=/- " %%A in ('DATE/T') do IF EXIST %THEDATE% GOTO START
for /F "tokens=2-4 delims=/- " %%A in ('DATE/T') do md %THEDATE%
:START
echo %DATE% %TIME% >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
pslist.exe -xm >> perf.out
echo =+=+=+=+=+=+=+=+=+=+=+=+=+ >> perf.out
echo %DATE% %TIME% >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
pdm_listconn -s -c >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
pdm_webstat >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
slstat >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
pdm_status >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
echo ********DB Stuff******** >> perf.out
db_report >> perf.out
echo -=-=-=-=-=-=-=-=-=-=-=-= >> perf.out
pdm_vdbinfo >> perf.out
echo =+=+=+=+=+=+=+=+=+=+=+=+=+ >> perf.out
For /F "tokens=2-4 delims=:" %%a in ('Command /C Echo.^| Time ^| Find "current"') Do Set THETIME=%%a%%b%%c
Set THETIME=%THETIME:~1%
ren perf.out "%THETIME%_PERF.OUT"
move "%THETIME%_PERF.OUT" .\%THEDATE%
ping 1.1.1.1 -n 1 -w 540000 > nul
goto START:


一定間隔ログ記録のための UNIX/Linux シェルスクリプト

 

この出力から、 UNIX でのメモリ /CPU 使用率の情報を収集します。
gather_ca_logs.sh という名前のスクリプトを作成します。
スクリプトのアクセス権が 「execute」(実行可能)になっていることを確認したうえで、以下のコマンドを実行します。

chmod 755 gather_ca_logs.sh

 

収集される情報の例を下記に示します。

このスクリプトにより、 gather_ca_logs.out というファイルが $NX_ROOT/log ディレクトリ内に作成されます。このスクリプトを停止するには、 Ctrl + C キーを押します。

#!/bin/sh
mkdir -p $NX_ROOT/log/interval_logging
commands_to_run()
{
printf "******************\n" >> $NX_ROOT/log/interval_log.out
date >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
ps -ef >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
vmstat >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
pdm_vdbinfo >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
db_report >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
pdm_status >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
slstat >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
pdm_webstat >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
pdm_listconn >> $NX_ROOT/log/interval_log.out
printf "******************\n" >> $NX_ROOT/log/interval_log.out
sleep 900
}
if [ -f $NX_ROOT/log/interval_log.out ]
then
rm $NX_ROOT/log/interval_log.out
mv interval_log.out $NX_ROOT/log/interval_logging/interval_log.out.`date +"%Y%m%d%H%M%S"`
fi
while [ 1 != 0 ]
do
commands_to_run
done



チューニングに関する一般推奨事項

 

このセクションでは、発生する可能性のある問題を特定する方法、および、 CA Service Desk のパフォーマンスを向上させるためにできることについて説明します。
この内容は、 Service Desk に関するグリーンブック 「Incident and Problem Management」 とサポートの経験を基にまとめたものです。

注意すべき兆候

Service Desk でパフォーマンスの問題が発生している可能性があることを示す兆候を以下に示します。

注意すべき兆候のうち特によく見られるものとして、以下のものが挙げられます。

 

  • stdlog ファイル内に、実行に時間がかかっているクエリメッセージがある。
    stdlogs ファイル内で次のようなメッセージを探します。「The following query took #### milliseconds... 」
  • pdm_vdbinfo の出力内に、データベースエージェントの待ち行列がある。
    pdm_vdbinfo の出力内で 「Queued Requests(#)」 という記述を探します。
  • Web エンジン 1 つあたりの接続ユーザ数が多い。
    150 から 200 を超えている場合です。「pdm_webstat」 コマンドを使用すると、 Web エンジンあたりの同時接続ユーザ数が表示されます。
  • ユーザから苦情を受けている(最悪のケース)。

 

4 つ目の兆候を除いて、すべてのデータは Service Desk の stdlogs または一定間隔ログ記録の出力に記録されます。

上記の主要パフォーマンス指標やリソースの消費状況を定期的にモニタリングすること、および日常的なメンテナンスが確実に実施されるようにすることが、小さな問題を深刻化する前に特定するのに役立ちます。

問題があるのではないかと思われる場合、またはユーザからパフォーマンスが遅いという苦情を受けた場合は、 CA サポートに問題をレポートし、一定間隔ログ記録および Service Desk 診断用ツールの出力と、問題についての情報を送信してください。

また、 Service Desk のパフォーマンスが遅くなった日時を伝えると、 CA サポートが上記のデータからより多くの情報を引き出すのに役立つ可能性があります。

 

ベストプラクティス文書の参照

グリーンブック「Incident and Problem Management」 第 17 章「詳細な調整」

 


このドキュメントは米国サポートサイトに掲載されているナレッジベース: TEC473185 を翻訳し、加筆したものです。

TITLE : How may we identify performance issues in Service Desk and what type of data is helpful to Support to resolve these issues?

Attachments

    Outcomes