「遅い」トランザクションのトラブルシューティング方法とは？Issue 予想以上に時間がかかっている UI トランザクションがある場合、次の手順に従い、プラットフォームのどの部分から速度が低下しているかを特定します。 ユーザーが時間のかかるトランザクションをトリガーした場合、トランザクションクォータのルールによって 5 分後 (デフォルト) にトランザクションがキャンセルされます。「トランザクションがキャンセルされました」などの警告メッセージと「最大実行時間を超えました」という理由が表示されることがあります。このトランザクションは、次の手順に従って調査する必要があります。 調査では次に、ACL、ビジネスルール、データベース、クライアント側など、プラットフォームの「遅い」領域に焦点が当てられます。個々のコンポーネントのすべてのタイミングは、[フィルターナビゲーター] > [システムログ] に記録されます。 注意： 遅いトランザクションの再現やその後のノードログファイルのレビューなど、同じノードでこれらの手順に従う必要があります。 また、応答時間が 100 ミリ秒未満のトランザクションのみがログに表示されます。すべてのデータベースクエリを表示するには、[フィルターナビゲーター] -> [SQL のデバッグ (詳細)] で追加のデバッグを有効にする必要があります。 この KB では、この調査のための方法をいくつか説明します。 1A) ノードログファイルブラウザ (ステップ数は多いですが、ログ内も分析できる柔軟なアプローチです)。 1B) localhost_log ファイルをローカルワークステーションにダウンロードし、grep などのツールを使用してターミナルウィンドウやテキストエディターでログをさらに調べます。 2) UI のデバッグモジュール (特定のセッション/トランザクションのみを再現する場合は非常に迅速かつ簡単です。 これにより、インデックス提案エンジンも使用できるようになるため、この方法を試してみてください。) ReleaseすべてのリリースResolutionオプション 1A：ノードログファイルブラウザ 1.遅いトランザクションを再現します2.[フィルターナビゲーター] > [システムログ] > [トランザクション] (全ユーザー)3.リストの列をカスタマイズします。これらの列は、次のものを追加すると便利です。 閲覧時間ビジネスルール時間クライアントネットワーク時間クライアント応答時間クライアントスクリプト時間ネットワーク時間セマフォ待機時間セッションセッション待機時間セッション ID合計待機時間ページの合計ロード時間合計待機時間トランザクション数トランザクション処理時間UI ポリシー時間 4.リスト条件フィルターを created_by = <affected_user> に変更し、created の記述でソートします (これによってノイズが除去され、影響を受けるユーザーのみにフォーカスできます)5.リストの先頭近くにあるトランザクションログで遅いトランザクションを特定します (URL 列にはトランザクションタイプが表示されます)6.問題のトランザクションのセッション ID (セッション列) およびトランザクション数をコピーします7.[フィルターナビゲーター] > [ノードログファイルブラウザ]i) 問題のトランザクションが実行された時間を含むように [開始時間] フィールドと [終了時間] フィールドを変更します ii) セッション ID = (ステップ 6 のセッション ID を貼り付けます) iii) 最大行数 = 10000 iv) メッセージ = (ステップ 6 のトランザクション数を貼り付けます) 8.[送信] をクリックします。これにより、ターゲットトランザクションが表示されます。9.影響を受けるトランザクションログ出力から txid 値をコピーします (例：txid=81c8704bdbc7) セッション ID だけでなく、txid を使用して検索すると、出力にユーザートランザクションに関する詳細が表示されます。 10.[メッセージ] フィールドのトランザクション数を txid 値に置き換える以外は、ログファイルのパラメーターを同じままにします。[送信] をクリックします。 これにより、関連するトランザクションをさらに詳しく確認できます 上記の画面の例では、次のことがわかります。- トランザクションが mytable_list.do であった- データベースクエリ (SELECT) に 13.604 秒かかった。 (時間：0:00:13.604)- EXCESSIVE ***END のログエントリが、ほとんどの時間を占めているプラットフォームの部分を示している。ここでは合計時間が 13.737、SQL 時間が 13.611 であり、トランザクションにかかる時間の大部分が SQL (データベース層の時間) であることを意味します。 クエリ自体を見れば、問題がすぐにわかります。クエリには WHERE 句がありません。つまり、プラットフォームはテーブルからすべてのレコードをプルする必要がありますが、これではスケーリングできず、データベースインデックスも使用できないため、適切な方法ではありません。したがって、フィルター条件を修正して、より小さな結果セットを取得することを検討する必要があります。 次のスクリーンショットは同じリストビュートランザクションを示していますが、今回はフィルター条件 mycolumn='ABCD' を使用していますフィルター条件を使用しても、クエリは 15 秒と遅いままです。つまり、条件を実際に効果的にするには、mycolumn 列にインデックスが必要です。 * UI を介して MyTable(MyColumn) にインデックスを追加しました。選択するインデックスの決定についてサポートが必要な場合は、オプション 2 アプローチを試し、インデックス提案エンジンを使用します。 11.インデックスの追加後にトランザクションをもう一度見ると、ログに SQL クエリが表示されなくなります。これは、100 ミリ秒よりも速く実行され、ログに記録されなくなったためです。SQL 時間が 73ms と非常に高速になりました オプション 1B：ノードログファイルブラウザ 1.遅いトランザクションを再現します2.[フィルターナビゲーター] > [ノードログファイルのダウンロード]3.localhost で始まる「名前」のみを表示するように条件リストを修正します4.DESC 順の名前でソートします5.リストの一番上にあるファイルは、今日の localhost ログファイルです 6.レコードを開きます7.[ログのダウンロード] をクリックします 次に、選択したテキストエディターを使用してログについて検索/質問します (セッション ID (セッション列) とトランザクション数を使用して検索し、関連するトランザクションを確認します。 txid 値がある場合はこれを検索することもできます))。 ファイルをターミナル/アイテムにロードし、grep、less などのツールを使用してファイルを問い合わせたり検索したりすることもできます オプション 2：セッションデバッグ (推奨) 1.[フィルターナビゲーター] > [システム診断] > [セッションデバッグ] > [すべて有効化 (Enable All)] に移動すると、新しいウィンドウでデバッグツールが開きます 2.トランザクションを再現します 3.セッションログウィンドウで出力を確認します セッションログにはいくつかの便利な機能があり、ログをダウンロードし、ログをクリアできます。ノイズを除去して出力画面をクリアしたい場合はフィルターを修正することもできます ログ出力で検索する重要な単語は、調査が必要な遅いクエリであるため、EXCESSIVE です。 4.以下の画面 (8.459 秒) のようなコストのかかる SQL クエリがある場合は、インデックス提案のインデックス機能を試すことができます。 5.トランザクションを再現したメインの UI ウィンドウで、「Query」ヘッダーの下のデバッグ出力まで下にスクロールします。次に、コストの高いクエリであるレコードを開くと、低速クエリモジュールでレコードが開きます 6.インデックス提案エンジンの KB KB0782916 に従います 次のステップ： トランザクション時間のほとんどを占める場所が焦点になるはずです。もし、ほとんどの時間を ACL の処理に費やしている場合、その領域に焦点を当てる必要があることは明らかです。UI アクションの時間が長い場合は、UI アクションを調査する必要があります。SQL 時間が最も長い場合は、データベースクエリなどを確認する必要があります。 SQL 時間がトランザクション時間の大部分を占めている場合は、次の質問に答えてください。 クエリに条件フィルター (WHERE 句) はありますか？ ある場合、条件フィルターは効率的ですか？この KB の追加情報セクションで「効率的なクエリのパフォーマンスのベストプラクティス」を参照してください。 データの結果セットは、小さく限定されたデータのサブセットでしょうか (たとえば、active=1 や日付範囲を使用していますか)。そうでない場合は、active=1 を追加するか、日付範囲を使用して、クエリする結果セットの数を減らすことを検討してください。 クエリはインデックスヒントまたはインデックスを活用できますか？WHERE 句の後にある列と論理オペランドによっては、インデックスが役立つ場合があります。オプション 2 のパスを辿った場合は、インデックス提案エンジン KB0782916 を簡単に試すことができます 新しいインデックスはすべて、最近クローンしたインスタンスで必ずテストしてから本番環境に適用してください。 Related Links効率的なクエリのためのパフォーマンスのベストプラクティス - 上位 10 のプラクティス https://community.servicenow.com/community?id=community_article&sys_id=0c3c6661dbd0dbc01dcaf3231f961947 最適なインスタンスパフォーマンスのための推奨事項 https://community.servicenow.com/community?id=community_article&sys_id=0686dc99dbde241011762183ca9619e6 セッション待機/セッション同期とは何か？ https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0755706 セッションログに関する詳細情報 https://docs.servicenow.com/bundle/rome-application-development/page/script/debugging/reference/parts-script-debugger-interface.html インデックスの追加 https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/table-administration/task/t_CreateCustomIndex.html インデックス提案エンジンを使用してインデックスを作成する方法 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0782916 クライアントトランザクションタイミング https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/time/reference/transaction-logs-2.html https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/time/reference/client-transaction-timing-2.html サービスポータルの 6 つの一般的なパフォーマンスの落とし穴とその回避方法 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0634588 パフォーマンスランディングページ https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0829067