インスタンスの状態を確認するURL（stats.do / threads.do）
ServiceNow を使っていて、画面が急に重くなることがあります。ボタンを押しても反応がない、一覧がいつまでも表示されない、といった状況です。珍しい話ではありません。
こういうとき、多くの人はブラウザの再読み込みか、しばらく待つことで様子を見ます。ですが ServiceNow には、インスタンスの内部状態をその場で確認できる診断用の画面が、最初から用意されています。ノードの構成やメモリを見る stats.do、実行中の処理を見る threads.do、自分の処理だけを止める cancel_my_transaction.do などです。
この記事では、これらの診断URLを PDI（Personal Developer Instance / Zurich / OOTB）で実際に開き、画面に何が出るか、どう読むかを確認します。いずれも incident_list.do などと同じく .do で終わる URL で、直接アドレスバーに入力して開くものです。基本的な URL の使い方は URLでのナビゲーション例（ServiceNow Docs） にまとまっています。
想定読者は、ServiceNow の操作には慣れているが、画面が重いと感じたときに再読み込み以外の対処を知らない人です。
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich リリースの OOTB（初期設定）で確認しています。実環境では権限やカスタマイズにより結果が変わります。
この記事で分かること
stats.do の画面に並ぶ項目（メモリ、同時実行数、応答時間）の読み方
threads.do に出るスレッドダンプの見方と、使いどころ
自分が実行した処理だけを止める方法
キャッシュを操作する画面と、その影響範囲
DB接続の状態と、いま実行中のSQLを確認する方法
本番環境で開いてよい URL といけない URL の区別
「重い」には何種類かある
「ServiceNow が重い」と言われても、実際に遅い場所は場面ごとに違います。どこが遅いのかによって見る画面も変わるため、まず切り分けます。
自分だけが遅いのか、全員が遅いのかが最初の分岐です。自分だけなら、自分が流した処理を止めれば済みます。全員なら、ノードやデータベース側を見ることになります。
診断URLの全体像
この記事で扱う URL をまとめました。いずれも実機で開けることを確認し、応答のサイズも実測しています。
これらは「いま何が起きているか」をその場で見るための画面です。一方、System Logs（ServiceNow Docs） に載っているシステムログ（syslog）は、後から履歴をたどるための記録です。執筆時点のPDIでは65万件を超えていました。ログから重い処理の原因をさかのぼるには時間がかかります。今すぐ止めたい処理があるときは、これから紹介する画面を開くほうが早く済みます。
stats.do・xmlstats.do は docs.servicenow.com のバンドル文書には見当たりません。ただし古くから知られた診断用エンドポイントで、stats.do・xmlstats.doの解説（ServiceNow Community） にも使い方がまとまっています。同記事は2016年の投稿ですが、2026年3月時点の追記で「この方法は非推奨になった」と注記があり、後継として Instance Observer という画面が案内されています。この記事では Instance Observer 自体の検証はしていません。
stats.do でノードとメモリの状態を確認する
https://<YourInstance>/stats.do
開くと「Statistics for」から始まるテキストのページが返り、先頭には接続しているノードの名前が入ります。続けて Build name・Build date・Build tag・Instance State・Load-balancer status・Database latency といった項目が並びます。実機では Build name が Zurich、Instance State が ONLINE でした。複数ノードで構成された環境で、特定のノードだけ挙動が違うと感じたときの切り分けに使えます。
Servlet Memory の読み方
「Servlet Memory」のブロックには Max memory・Allocated・In use・Free percentage の4行が並びます。Max memory は割り当て可能な上限、Allocated は実際に確保済みの量です。In use はそのうち使用中の量を示します。実機では Max memory 1820.0、Allocated 1514.0、In use 813.0、Free percentage 46.0 という値でした。Free percentage が下がり続けている場合は、メモリ不足の兆候として見ておく価値があります。
Servlet Statistics と Semaphore Sets の読み方
「Servlet Statistics」には Started（起動時刻）や Transactions（処理件数）といった項目が並びます。続けて Errors handled、Logged in sessions、Session timeout なども並びます。実機では Transactions 25679、Errors handled 9884、Logged in sessions 3（12 active）という値を確認しました。
その下の「Semaphore Sets」は、同時に実行できるトランザクション数を制御する仕組みの状態を表す欄です。Available semaphores は同時実行の枠数、Queue depth は現在待たされているリクエスト数を示します。Queue depth limit は待ち行列の上限です。実機の Default セットでは、Available semaphores が16、Queue depth が0でした。Maximum transaction concurrency は16、Maximum concurrency achieved は6という値でした。Queue depth が高止まりしていれば、枠が足りずリクエストが渋滞している合図になります。ページ下部には、直近1分・5分・15分・60分・1日の応答時間パーセンタイルが並ぶ形式です。平常時の値を控えておくと、遅いと感じたときの比較材料になります。
xmlstats.do で同じ内容をXMLで取り出す
https://<YourInstance>/xmlstats.do同じ内容を XML で取得できます。実機で丸ごと取得したところ約2.0MBありました。応答の先頭には includes という属性があり、そこにこのインスタンスで取得できるセクション名がすべて列挙されています。丸ごと取ると重いので、?include= でセクションを絞って使います。
https://<YourInstance>/xmlstats.do?include=memory実機で ?include=memory を試したところ、応答は約1.2KBまで縮み、メモリに関する数値だけが返りました。セクションを絞るだけで、応答サイズが2桁以上小さくなることを確認しています。?include= で指定できる値のうち、system・servlet・diagnostic_events・scheduler・semaphores は前述のCommunity記事にも説明があります。
threads.do で実行中の処理を確認する
https://<YourInstance>/threads.do
threads.do が返すのは、状態を示す一覧表ではありません。中身はスレッドダンプです。ヘッダーに続いて、その瞬間にJVM内で動いていたスレッドが1本ずつ並び、各スレッドの下にスタックトレース（そのスレッドが今どのクラス・メソッドを実行中かの呼び出し履歴）が積まれています。1行目にスレッドグループ名・スレッド名・優先度が入り、その下の行から at ... で始まるスタックの各段が続く形式です。
実機のキャプチャでは http-nio2-16513-exec-47 のようなスレッドが確認できました。これは Tomcat の NIO2 コネクタが割り当てるHTTPリクエスト処理用のスレッド名で、ブラウザから飛んできたリクエストを処理しているスレッドです。ほかに glide.scheduler.worker （スケジュールジョブを取り出して実行するワーカー）、Fast Lock Sweeper （ロックの掃除役）といった名前も見えました。
使い方は単純です。画面が返ってこないときは threads.do を開き、自分の操作に近い名前のスレッド（HTTPリクエストを処理している http-nio2-...-exec-NN など）を探します。そのスタックの上から数行を読むと、どのテーブルへのクエリで止まっているか、どのスクリプトの中で止まっているかが分かります。stats.do がインスタンス全体の構成を見る画面なのに対し、threads.do はその瞬間に動いている処理そのものを見る画面という違いです。
自分の処理だけを止める（cancel_my_transaction.do）
https://<YourInstance>/cancel_my_transaction.do
この URL は、自分のセッションで実行中の処理を中断するためのものです。実機で開いたところ「All transactions have completed, nothing to cancel」という応答でした。これは、開いた時点で自分のセッションに止めるべき処理が残っていなかったことを示しています。逆にいえば、重い処理を自分で流している最中にこの URL を開けば、その処理を中断する操作画面になります。
他人には影響しません。ブラウザのタブを閉じてもサーバ側の処理は止まらないため、処理を止めたいときはタブを閉じるのではなく、この URL を開きます。
キャッシュを確認する（cache.do）
https://<YourInstance>/cache.do
開くと右上に Clear Cache と Clear All Browser Caches のリンクが並びます。その下には「Servlet Memory」の数値が2回、「After Cache Flush」という見出しを挟んで表示されます。実機では Allocated が1452.0から1473.0へ、Free percentage が35.0から41.0へと変化していました。ページを開くこと自体に、キャッシュフラッシュ前後のメモリ比較という動作が伴っていると考えられます。
辞書やリスト定義を変更したのに画面へ反映されない、というときにこの画面を使います。ただし、キャッシュの操作はクラスタ全体に影響します。本番環境で無造作に開くと、全ユーザーがキャッシュ再構築による遅延を受ける可能性があります。検証環境で使うものと考えておきます。
DB基盤を確認する（system_diagnostic_database_page.do）
https://<YourInstance>/system_diagnostic_database_page.do
開くと「Information」と「Connections」の2つの表が返ります。Information には Type・Version・Driver・JDBC が並びます。実機では Type が mysql、Version が 5.8.20-MariaDB-log、Driver が MariaDB connector/J でした。このPDIは、MariaDB系のデータベースエンジンで動いていると分かります。
Connections には、コネクションプールの1本ごとの状態が並びます。空いていれば free、使用中なら in use と表示され、使用中の行には実行中のSQL文がテーブル名・カラム名つきでそのまま出ます。実機では system_diagnostic_database_page.do 自身が発行したクエリや、キャッシュフラッシュのタイムスタンプを問い合わせるクエリが確認できました。特定のクエリだけが長時間 in use のままなら、そのクエリが詰まっている疑いが持てます。性能まわりの相談を受けたとき、DBエンジンの種類とバージョンを確認する場所としても使えます。
アップグレード履歴を確認する（sys_upgrade_history_list.do）
https://<YourInstance>/sys_upgrade_history_list.do
開くと「System Upgrades」という一覧が返ります。From・To・Upgrade started・Upgrade finished などの列が並ぶ形式です。Changes skipped・Changes applied・Changes processed も表示され、プラグインやアプリ単位でいつ何が適用されたかを追えます。実機では執筆時点で94件の履歴が記録されていました。直近では sn_build_agent や sn_glider といったコンポーネントの更新が確認できます。アプリのアップグレード履歴の確認（ServiceNow Docs） にも、アップグレード履歴を追う操作がまとまっています。アップグレード直後から挙動が変わったと感じたときに、まずこの一覧で何が適用されたか確かめる使い方です。
調べる順番
症状によって見る画面が変わるため、次の順で当たると迷いません。
全員が遅いか、自分だけかを見極める ── 周囲に確認するか、別アカウントで同じ操作を試します
全員が遅ければ stats.do ── ノードの状態とメモリ、Semaphore Sets の Queue depth を確認します
自分だけなら threads.do ── 自分の操作に近いスレッドのスタックを読みます
自分の処理を止めたいなら cancel_my_transaction.do ── タブを閉じずにこちらを開きます
設定変更が反映されないなら cache.do ── ただし検証環境で使います
DB側を疑うなら system_diagnostic_database_page.do ── 実行中のSQLを確認します
直近の変更が疑わしいなら sys_upgrade_history_list.do ── 適用履歴をさかのぼります
他の手段との比較
診断URLを直接開く以外にも、画面から同じ情報にたどり着く経路があります。
遅いトランザクションの調べ方（ServiceNow Community） では、System Logs > Transactions（All user） の一覧が使えます。ここでトランザクションごとの所要時間を確認できます。System Diagnostics > Session Debug で処理を詳細表示する方法も、同じ記事にある内容です。トランザクションの応答時間そのものは Transaction log response times（ServiceNow Docs） にまとまっています。Transaction Logs（ServiceNow Docs リファレンス） にも同様の説明があります。
これらはメニューから辿れる分、URLを直接叩くより手間がかかりますが、条件を絞った検索や、過去分の一覧表示に向いています。threads.do や stats.do は「いま」の瞬間を素早く覗きたいときに向いており、System Logs 側は後から条件を変えて調べ直したいときに向いていると考えられます。
本番で叩いてよいもの・いけないもの
URL ごとに、本番環境で開いてよいかどうかをまとめます。
これらの画面は管理者権限を前提としています。権限が足りない場合、ログイン画面に戻されるか、権限エラーになります。URL を人に共有しても、開いた相手の権限を超えて情報が見えるわけではありません。
よくある質問
管理者以外でも開けますか
いいえ。ここで紹介した診断URLはいずれも管理者権限を前提としています。権限が不足していると、ログイン画面へ戻されるか権限エラーの応答になります。
stats.do と threads.do は、どちらを先に見ればいいですか
全員が遅いと感じているなら stats.do から、自分の操作だけが返ってこないなら threads.do から見ます。前者はノード全体の構成、後者はいま動いている処理そのものを映すという違いがあるためです。
cancel_my_transaction.do で「All transactions have completed, nothing to cancel」と出るのはなぜですか
実機で確認した限り、これは開いた時点で自分のセッションに中断すべき処理が残っていない場合の応答です。重い処理を実際に走らせている最中に開けば、その処理を止める操作画面が表示されると考えられます。
xmlstats.do の ?include= に指定できる値は、どこで分かりますか
パラメータを付けずに xmlstats.do を開くと、返ってきたXMLの先頭にある includes 属性に、このインスタンスで取得できるセクション名がすべて列挙されています。そこから興味のある値を選んで ?include= に指定します。
threads.do や stats.do に出る数値は、毎回同じですか
いいえ。どちらもアクセスした瞬間の状態を映すスナップショットです。この記事に載せた数値は執筆時点のもので、次に開いたときには変わります。
用語
Servlet statistics … stats.do が返す、ノードの構成やメモリ状況をまとめたテキスト画面
Semaphore Sets … 同時に実行できるトランザクション数を制御する仕組み。Available semaphores や Queue depth として値が出る
スレッドダンプ … ある瞬間に実行中の全スレッドの呼び出しスタックを書き出したもの。threads.do の中身はこれにあたる
ノード … クラスタを構成するアプリケーションサーバの1台
キャッシュフラッシュ … サーバ側の記憶領域に持つ設定・データのコピーを破棄し、作り直す操作
Connections（DB診断ページ） … system_diagnostic_database_page.do に出る、データベースとの接続1本ごとの使用状況一覧
検証範囲外のこと
xmlstats.do の ?include= に指定できる値は、応答の includes 属性に列挙されている分だけ確認しました。個々の値がすべて公式にサポートされているかまでは確認していません
cancel_my_transaction.do は、中断すべき処理がない状態の応答のみ確認しました。自分の重い処理が実際に走っている最中にどう表示されるかは、今回は確認していません
threads.do・stats.do・xmlstats.do の数値は、アクセスした瞬間のスナップショットです。この記事の値は執筆時点のもので変動します
system_diagnostic_database_page.do の Driver 欄がどのような表記になれば、より新しいデータベース基盤への移行を示すのかは、今回は確認していません
Instance Observer の画面そのものは、今回は検証していません
管理者以外のロールでこれらの URL を開いたときの挙動は、今回は確認していません
まとめ
画面が重いと感じたら、まず全員が遅いのか自分だけなのかを見極めます。全員が遅ければ stats.do、自分だけの操作が返ってこないなら threads.do です。原因の見当がついたら、cancel_my_transaction.do や cache.do、system_diagnostic_database_page.do で裏を取ります。調べる順番は前述のとおりで、再読み込みして待つよりも早く手がかりに近づけます。
URL に条件を付けて調べる小ワザや、Session Debug を使ったビジネスルールの追い方は、それぞれ別の記事で扱っています。無料の検証環境（PDI）をまだお持ちでない場合は、先に developer.servicenow.com のデベロッパーサイトで登録してから、この記事のURLを試してみてください。
