パフォーマンスの問題に関する調査では、以下の情報が必要となります。
1. 発生した問題、ServerProtectの使用環境に対する基本的な情報
(1) 問題は今も続いていますか。また、発生頻度はどのくらいありますか。
(2) 問題は再現できますか。
(3) 問題が再現できる場合は、その手順をお伝えください。
(4) 問題はServerProtectをインストールした全コンピュータの何台中何台で起きていますか。
(5) 問題は特定のプラットフォームで起きていますか。
(6) この問題が起こる前、コンピュータは正常に動いていましたか。
(7) 問題が起こる前、システムまたはネットワークに変更を加えましたか。
(8) ServerProtectのSecurityPatchや弊社から個別に提供したHotfix（修正モジュール）を適用した経緯があれば、SecurityPatch名やHotfix名を教えてください。
(9) リアルタイム検索を無効にすることで現象回避できますか。
(10) 特定のディレクトリ（あるいはファイル）へアクセスする時にのみ現象が発生する際は、その該当ディレクトリ（あるいはファイル）をリアルタイム検索の検索除外設定へ追加することで、現象回避できますか。
(11) コンピュータがハングアップしている場合、他のコンピュータから該当コンピュータへpingを実行できますか。また、他のコンピュータからSSHなどを使用して、リモートからコンソールへログオンできますか。
2. OSの基本情報
(1) OSのバージョン情報
Red Hat Enterprise Linux の場合：
# cat /etc/redhat-release
SuSE Linux Enterprise Server / Novell Linux Desktop の場合：
# cat /etc/SuSE-release
(2) bootディレクトリの情報
# ls –al /boot
(3) カーネルのrpmパッケージ情報
# rpm –qi kernel
(カーネルパッケージが複数インストールされている場合、uname –a の結果を元に現在起動中のカーネルのrpmパッケージ情報を取得します。)
# rpm –qi kernel-2.6.9-5.EL (例)
(4) インストールディレクトリの権限
# ls –l /
# ls –l /opt
(5) コンピュータ上に存在しているカーネルフックモジュール(KHM)の情報
# cd /opt/TrendMicro/SProtectLinux/SPLX.module
# ls -al | grep splxmod
(6) カーネルフックモジュールのチェックサム
# md5sum /opt/TrendMicro/SProtectLinux/SPLX.module/*
(7) KHMがロード状況の情報
# lsmod | grep splxmod
(8) splxサービスの現在の状態
# /etc/init.d/splx status
(9) SPLXのビルド情報
# rpm -qa | grep splx
(10) KHMのバージョン
# modinfo /opt/TrendMicro/SProtectLinux/SPLX.module/splxmod.ko
(11) KHMの作成元について
弊社サポートセンターにご依頼いただき弊社より提供したKHMでしょうか、それともお客様独自にコンパイルされたKHMでしょうか。
以上の情報を”GeneralInfo.txt”と言うファイル名のテキストファイルへまとめて出力してください。
(12) CDT(Case Diagnostic Tool)データの取得
# /opt/TrendMicro/SProtectLinux/SPLX.util/DiagnosticTool
Collecting product info...
Collecting system info...
Collect info success!
上記コマンド実行後、/var/log/TrendMicro/CDT_Data/ 配下にある下記のファイルを取得してください。
YYYYMMDD-hhmmss.tgz
(YYYYMMDD-hhmmss は、データを取得した日時[年月日-時分秒])
※ tgzファイルの中身は、ファイル名と同じ名前のディレクトリ内に保存されています。
3. システムのログファイル
初期設定では、/var/log/messages に記録されます。
ログローテートされたファイル(/var/log/messages.*)も含めて採取してください。
4. sysstatのログファイル
sysstatがインストールされている場合、/var/log/saディレクトリ配下にsar*と言う名前のログが出力されます(*は日付)。現象発生当日のsar*ファイルを取得してください。
5. topコマンドの出力ログ
# top b > `date +%Y%m%d`top.txt
上記コマンド実行後、高負荷の現象を再現させ、[Ctrl]+[C]で中断した後で出力された ./YYMMDDtop.txtを採取してください。
6. 高負荷になっているプロセスのcoreダンプ
高負荷になっているプロセスのIDが特定できている場合、下記の手順で強制的にcoreダンプを出力させてください。
(1) coreファイルが出力されるように設定します。
# ulimit -c unlimited
※ 上記コマンドは、このコマンドを実行したコンソール上でのみ有効となります。
上記コマンド実行後にulimit -aコマンドで”core file size”が”unlimited”になっている事をご確認ください。
(2) coreファイルの出力ディレクトリを指定します。
(2-1) 以下のコマンドを入力し、</proc/sys/kernel/core_pattern>ファイルを
</root>配下へバックアップします。
# cat /proc/sys/kernel/core_pattern > /root/core_pattern
(2-2) 以下のコマンドを入力し、coreの出力先を</opt/TrendMicro/SProtectLinux>
ディレクトリへ上書き変更します。
# echo '/opt/TrendMicro/SProtectLinux/core' > /proc/sys/kernel/core_pattern
(2-3) 以下のコマンドを実行し、</opt/TrendMicro/SProtectLinux>配下に
変更されたことを確認します。
# cat /proc/sys/kernel/core_pattern
(3) 高負荷になっているプロセスを強制終了させ、coreダンプを出力させます。
# kill -6 <pid>
(4) 手順(2-3)で指定したディレクトリにcoreファイルが出力されていることを確認します。
ファイル名は core.<PID> です。
例）PIDが1234の場合は core.1234
(5) 以下のコマンドを実行し、coreファイルを生成したプロセスを確認します。
#file core.<PID>
(6) SPLXのプロセスが生成したcoreダンプあることを確認できましたら、それを取得してください。
※coreダンプを取得した後は、元の状態へ設定を戻してください。
(7) 以下のコマンドを入力し、</root/core_pattern>へバックアップされた情報を
< /proc/sys/kernel/core_pattern>へ戻します。
# cat /root/core_pattern > /proc/sys/kernel/core_pattern
7. ServerProtectのデバッグログ
(1) viなどのテキストエディタで、/etc/syslog.confへ下記のエントリを追記します。
local3.debug /var/log/vsapiapp.log (vsapiapp デバッグログ用)
(2) syslogdデーモンを再起動します。
# systemctl restart syslog
(3) SPLXサービスを停止します。
# systemctl stop splx
(4) viなどのテキストエディタで、/opt/TrendMicro/SProtectLinux/tmsplx.xmlファイルの以下の部分を編集します。
P Name="UserDebugLevel" Value="5" (vsapiappデバッグログ用。初期設定では”1”)
(5) SPLXサービスを起動します。
#systemctl start splx
(6) 問題を再現させます。
(7) 以下のファイルにデバッグログは出力されますので、これらを取得します。
/var/log/vsapiapp.log
(8) 手順(4)で書き換えたtmsplx.xmlファイルおよび、手順(1)で書き換えた/etc/syslog.confファイルを元の値に戻します。
(9) SPLXおよびsyslogdサービスを再起動し、デバッグモードを終了します。
# systemctl restart splx
# systemctl restart syslog
8. 事象発生時のタイムライン
取得したログファイルを比較しながら調査を進めるため、
システム時計をもとに、ログの取得時刻や作業の実行時刻の記録も
開始してください。
出来るだけ詳細な情報（月、日、時、分単位）での記録をお願いします。
記載例）
20**/**/** 実施
10:05 xxxサーバにてシステム時計の時刻を確認
10:15 xxxサーバにて製品デバッグログの取得を開始
10:17 並行して、xxxサーバにて同時に製品デバッグログの取得を開始
10:20 現象が再現されることを確認
10:25 xxxサーバ/xxxサーバにて各データの取得