データベースレイヤーのパフォーマンス監視ツール
ThingWorx とともに展開可能なエンタープライズレベルのデータベースエンジンの多くには、優れた監視ツールおよび問題検出ツールが備わっています。DBA チームと連携して、アプリケーション側の監視に加えてデータベースの監視および分析を行います。
PostgreSQL および Microsoft SQL データベースで推奨される問題検出クエリーのいくつかを次に示します。これらのデータベースは ThingWorx モデルデータに最もよく使用されているエンタープライズデータベースです。
Postgres
PostgreSQL サーバー上でリソースのボトルネックを特定するために次の判定基準を監視します。
• 空きディスク容量
• CPU 使用率
• I/O 使用率
長時間実行しているクエリーを特定して最適化しなければなりません。そのようなクエリーによってほかのクエリーがブロックされ、リソースが再び解放されるまでの待ち時間が長くなる可能性があります。これによって ThingWorx でデータベースロックを待機してスレッドが長時間実行し続けることがあります。データベースロックによって、個々の文が行またはテーブルの現在の状態をロックできるようになります。ロックが多すぎるとアプリケーションのパフォーマンスが影響を受けます。
PSM を使用して、長時間実行しているクエリーや頻繁に実行されるクエリーを検出できます。
MSSQL
Microsoft SQL データベースでは、本番環境でデータベースの統計を夜間に収集することをお勧めします。さらに、データベースが SSD で動作していない場合は特に、インデックスの断片化率が高くないか確認し、必要に応じて再構築します。ThingWorx データベース内に待ち時間が長いオペレーションやデッドロックオペレーションがないか MSSQL 拡張イベントログを定期的に確認する必要があります。パフォーマンスが低い時間に、次のクエリーによってリソースを待機しているトランザクションを特定できます。
SELECT t.*,r.*, SUBSTRING(t.text, statement_start_offset/2 + 1,
(CASE WHEN statement_end_offset = -1
THEN LEN(CONVERT(nvarchar(max), t.text)) * 2
ELSE statement_end_offset
END - statement_start_offset) / 2)
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
文がサスペンドされているか長時間実行している場合、wait_type および wait_resource 列で待ち時間の理由を調べます。
ロックが原因で文が待機しているかどうかを判断するには、セッション ID を指定して以下を実行します。
select * from sys.dm_tran_locks where session_id = 158