Windows Server 2016 のRDS環境で termsvcs（Remote Desktop Services）が突然高CPUになり、セッションが重くなる――。ユーザー数が増えていないのに起きるこの症状は、OSやRDSの不具合ではなく、基盤（特にEC2のCPUクレジット/スロットリング）が原因のことがあります。本記事では切り分け手順と再発防止まで具体的に解説します。
今回の事象：termsvcsが20〜25%程度スパイクし、RDSが重い
まずは状況を整理します。似た環境の方が自分の状況と照らし合わせやすいように、要点を表にまとめます。
| 項目 | 内容（例） | 読み取れるヒント |
|---|---|---|
| OS | Windows Server 2016 | RDSはsvchost配下（termsvcs）で動作し、CPUスパイクは「原因」ではなく「結果」であることも多い |
| 構成 | RDS/旧ターミナルサービスを有効化したサーバー4台 | 特定の1台だけか、同時期に複数台で起きるかで、OS要因/基盤要因の当たりを付けやすい |
| ユーザー数 | 8〜9人程度（以前は14〜15人でも問題なし） | 「負荷が増えた」より、「性能の出方が変わった（制限/スロットリング）」を疑う |
| 症状 | termsvcs が 20〜25% 程度のCPUスパイク、体感として重い | RDSの入力遅延はCPUだけでなく、基盤のCPUクレジット枯渇・I/O待ち・ネットワーク遅延でも起きる |
| 発生時期 | ここ1週間ほど | サーバー側の設定変更がなくても、Windows Update/Defender更新/バックアップ/スキャンなどの「背景タスク」が引き金になる |
結論：EC2のCPUバースト（CPUクレジット）枯渇／スロットリングが原因だった
今回のケースでは、OSやRDSの不具合ではなく、サーバー（VM）が載っているAmazon EC2側でCPUクレジットが枯渇し、スロットリング（実効性能の制限）が発生していました。別のVM/インスタンスへ移行したところ症状が解消したため、根本原因は基盤側にあると判断できます。
この「OS内のプロセス（termsvcs）が悪いように見えるが、実際は基盤の性能制限が原因」というパターンは、特にバースト可能インスタンス（T系など）で発生しやすいです。
なぜCPUクレジット枯渇で「termsvcsが重い」に見えるのか
RDSは、ログオン/ログオフ、セッション生成、グラフィック描画の転送、入力イベント、暗号化、リダイレクト（プリンタ/クリップボード/ドライブ）など、ユーザー操作に直結する処理を幅広く扱います。基盤側でCPUが絞られると、これらの処理が詰まり、結果としてセッションが遅い＝termsvcsが忙しいという見え方になりやすいのがポイントです。
| 現象 | OS側の見え方 | 基盤側で起きていること（例） |
|---|---|---|
| 入力が遅い、画面が固まる | termsvcs / svchost が上位に出ることがある | CPUクレジットが枯渇し、ベースライン性能に制限される（バースト不可） |
| 同じ人数でも急に重くなった | CPU使用率は「そこまで高くない」こともある | 背景タスクが増えてクレジット消費が加速、ある閾値を越えると体感が一気に悪化 |
| 時間帯で波がある | 朝/昼に重い、夜間は軽い など | 利用が少ない時間帯にクレジットが回復し、日中の負荷で再び枯渇 |
切り分けの最短ルート：まず「基盤の制限」を疑うチェックリスト
termsvcsの解析に踏み込む前に、基盤のボトルネックを潰すと、調査コストが大きく下がります。特にEC2の場合、次の順番で確認するのが効率的です。
| 手順 | 見るもの | 判断の目安 | 次アクション |
|---|---|---|---|
| 1 | EC2インスタンスタイプがバースト可能か | T系（例：t2/t3/t3a/t4g など）の場合は要注意 | CloudWatchでCPUクレジット関連を確認 |
| 2 | CloudWatch：CPUクレジット残高（CPUCreditBalance） | 残高が0近辺で張り付く／重い時間帯と一致 | インスタンス移行、Unlimited、タイプ変更を検討 |
| 3 | CloudWatch：CPU使用率の推移 | 高止まりではないのに体感が悪い場合、制限を疑う | OS側で待ち（I/O/ネット）も並行確認 |
| 4 | OS側：ディスク待ち、ネットワーク遅延、メモリ圧迫 | ディスクキュー長が高い、ページング増、NW再送が多い | ボトルネック箇所に応じて対策 |
CloudWatchでの確認ポイント（EC2側）
CPUクレジット枯渇の疑いがある場合、CloudWatchのグラフを見るだけで「ほぼ当たり」が付くことが多いです。代表的な見方をまとめます。
| 見る指標 | 何が分かるか | 典型的なNGパターン | 補足 |
|---|---|---|---|
| CPUCreditBalance | バースト用のCPUクレジット残高 | 0付近で横ばい（回復が追い付かない） | T系で最重要。重い時間帯と「残高ゼロ」が一致するか見る |
| CPUCreditUsage | CPUクレジットの消費量 | 特定の時間帯に消費が跳ねる | Windows Update、Defender、バックアップ、スキャンなどが引き金になりやすい |
| CPUUtilization | CPU使用率 | 高くないのに遅い／短いスパイクが頻発 | 「CPUが高い＝原因」と決め付けない。クレジット枯渇で“出せるCPU”が減っている可能性 |
実運用では、重くなった時間帯に合わせて1時間〜数時間のスパンでグラフを拡大し、CPUCreditBalanceが底を打っていないかを確認します。もし底を打っているなら、OS内のチューニングより先に、基盤の見直しが近道です。
「Unlimited」を使うべきか？判断のコツ
T系インスタンスには、CPUクレジットを使い切っても追加課金でバーストを継続できる「Unlimited」設定が用意されています（設定可否は世代により異なります）。ただし、RDSのようにユーザー体験が重要な用途で、クレジット依存のまま運用するのはリスクもあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Unlimitedを有効化 | 「たまにだけ」高負荷になり、普段は軽い | 高負荷が常態化するとコストが読みにくい。根本の容量不足が隠れることも |
| 非バースト系へ変更（m/c系など） | 業務時間帯に常に快適さが必要、負荷が安定している | 月額は上がりやすいが、体感性能と予測性が上がる |
| T系のサイズアップ | 今の構成の延長でまず改善したい | 根本が「クレジット運用」なので、使い方によっては再発する |
Windows Server 2016側での確認ポイント（RDS/termsvcs）
基盤を疑うとしても、OS側の観測点を押さえておくと原因の切り分けが確実になります。ここでは「termsvcsを疑うときの基本手順」を、なるべく迷わない形で整理します。
termsvcsはsvchost配下：PIDを特定して“どのサービスか”を見える化する
タスクマネージャーで「termsvcs」や「サービス ホスト（Remote Desktop Services）」が目立つ場合、実体はsvchost.exeの1プロセスです。まずはPID（プロセスID）を特定し、どのサービスが同居しているか確認します。
| やりたいこと | 手段 | ポイント |
|---|---|---|
| TermService（RDS本体）のPID確認 | サービス管理（services.msc）で「Remote Desktop Services」を確認 | サービス名は環境により表示が異なるが、内部的にはTermServiceが中心 |
| svchostにぶら下がるサービス一覧を見る | tasklist /svc /fi "imagename eq svchost.exe" | CPUが高いsvchostのPIDを探し、同居サービスを確認する |
| サービス名からPIDを引く | sc queryex TermService | PIDが分かれば、ダンプ取得や詳細解析がやりやすい |
パフォーマンスモニターで「CPU」以外の待ちを確認する
RDSの体感遅延は、CPUだけでなく、ストレージI/O待ちやメモリ不足、ネットワーク遅延でも発生します。CPUクレジット枯渇が原因でも、OS側の観測では「待ち」が増える形で現れることがあります。
| カテゴリ | カウンター例 | 見どころ |
|---|---|---|
| CPU | Processor(_Total)\% Processor Time | スパイクの時間帯を特定。短周期で振れるなら、何がトリガーかを追う |
| ディスク | PhysicalDisk(_Total)\Avg. Disk Queue Length | キューが伸びるとログオンやプロファイル読み込みが遅くなる |
| メモリ | Memory\Available MBytes / Pages/sec | ページング増は体感遅延に直結。ユーザー数が減っているのに悪化するなら基盤制限の可能性 |
| ネットワーク | Network Interface\Bytes Total/sec | 回線が細い、パケットロスがあるとRDSは顕著に遅く感じる |
イベントログ（RDS関連）で「大量の再接続」「認証ループ」を拾う
クライアント側の不具合やネットワーク不安定で、再接続が頻発するとRDS側の処理が増え、termsvcsが目立つことがあります。以下のログは“原因究明の糸口”になりやすいので、重い時間帯にエラー/警告が集中していないか確認します。
- Windowsログ：システム（サービス停止/再起動、ディスク、NIC関連）
- アプリケーションとサービスログ：
- Microsoft-Windows-TerminalServices-LocalSessionManager
- Microsoft-Windows-TerminalServices-RemoteConnectionManager
- Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
対処：別インスタンスへ移行すると改善するなら、原因はほぼ基盤
今回のケースでは、別のVM/インスタンスへ移行したところ問題が解消しました。この結果は非常に強力で、以下のように解釈できます。
| 観測結果 | 解釈 | 次にやるべきこと |
|---|---|---|
| 同じOS/同じ設定のまま、別インスタンスで快適 | OSやRDSではなく、元インスタンスの性能特性（CPUクレジット、ホストの混雑、I/O特性）が原因 | インスタンスタイプの見直し、Unlimited、サイズアップ、ストレージ性能の見直し |
| 移行後もしばらくして同症状が再発 | 「負荷そのもの」が増えている可能性（Update/スキャン/アプリ更新など） | 重い時間帯のタスク/更新状況の特定、アプリ側のログも合わせて追う |
それでも原因が不明なときの“次の一手”
CPUクレジットが問題でない、または非バースト系でも発生する場合は、RDS特有の要因やクライアント要因も含めて切り分けます。ここからは「よく効く順」に並べています。
クライアント（Thin Client/ゼロクライアント）側の更新・設定確認
古いクライアントOS/ファームウェアが原因で、RDPの再接続ループや描画負荷を引き起こすことがあります。特に複数端末が同じ機種・同じバージョンの場合、端末側の一括更新で改善するケースもあります。
| 確認ポイント | よくある症状 | 対処の方向性 |
|---|---|---|
| クライアントのOS/ファームの世代が古い | 一部端末だけ頻繁に切断、再接続が多い | 最新ファームに更新、RDP設定（UDP/画質/リダイレクト）見直し |
| RDPの描画設定が高すぎる | 動画/ブラウザで特に重い | 色深度・ビジュアル効果・ハードウェアアクセラレーションの方針を決める |
最近のWindows Update/サードパーティ導入を「事実ベース」で洗い出す
「構成変更はしていない」つもりでも、Windows Update、Defender定義、.NET更新、アプリの自動アップデート、バックアップソフトの更新などは自然に入ります。発生時期が“ここ1週間”のように明確なら、まずは事実を並べて、重い時間帯と突き合わせるのが近道です。
- 更新履歴（Windows Update）と、重くなり始めた日付の一致
- Defender/ウイルス対策ソフトの定義更新やスキャンスケジュール
- バックアップ、ログ収集、監視エージェントの更新・ポリシー変更
- RDSに関係する機能追加（プリンタリダイレクト、PDFソフト、ドライバ導入）
クリーンブートで常駐要因を切り分ける
サードパーティの常駐が疑わしいときは、クリーンブートで「Microsoft以外のサービス・スタートアップ」を停止し、再現性を見るのが定石です。業務影響があるため、実施はメンテナンス時間に限定し、戻し手順もセットで用意します。
termsvcs（svchost）のダンプ取得→詳細解析へ
どうしてもOS内の要因を追う必要がある場合は、スパイク時のプロセスダンプを取得して解析します。termsvcsはsvchost配下で動作するため、対象PIDを間違えないことが重要です。
| 方法 | メリット | 注意点 |
|---|---|---|
| タスクマネージャーで「ダンプファイルの作成」 | 追加ツール不要で実行できる | ダンプは大きくなる。ディスク空きと取得タイミングに注意 |
| Sysinternals ProcDump（例：procdump -ma） | 条件付き（CPUが一定以上で取得など）で自動化できる | ツール配布ポリシーやセキュリティ要件に注意 |
ダンプ解析はWinDbgなどが必要になるため、運用チーム内で完結しない場合は、ここまでの“観測結果”を揃えてから支援を依頼すると話が早いです（発生時刻、CloudWatchグラフ、PerfMonログ、イベントログ抜粋など）。
再発防止：RDSをEC2で運用するなら「監視」と「余裕」の作り方が重要
今回のような問題は、根本的には「必要なときに必要なCPUが出ない」ことが引き金です。再発防止の観点では、単にスペックを上げるだけでなく、事前に兆候を検知する仕組みが効きます。
CloudWatchアラームの例（考え方）
- CPUCreditBalance が一定値未満になったら通知（T系の場合）
- CPUUtilization が高止まりしたら通知（非バースト系でも有効）
- 重い時間帯の前にバッチが走っていないか、スケジュールも監視対象にする
容量計画の目安：ユーザー数だけで決めない
RDSはユーザー数が同じでも、利用アプリ（ブラウザ/Office/基幹アプリ/印刷/スキャン）や、ログオン頻度、プロファイル方式（ローミング/FSLogix等）、バックグラウンドタスクの有無で負荷が大きく変わります。特にT系では「普段軽いから大丈夫」が通用しにくく、負荷の山でクレジットが尽きた瞬間に体感が崩れるのが落とし穴です。
| よくある落とし穴 | 起きること | 対策 |
|---|---|---|
| 更新やスキャンを日中に実施 | 業務時間帯にCPUクレジット消費が加速して枯渇 | スケジュールを夜間へ、または非バースト系へ移行 |
| ログオン集中（朝礼前など） | プロファイル展開・GPO適用で短時間に高負荷 | ログオンスパイクを吸収できる設計（余裕のあるCPU/高速ストレージ） |
| 体感が悪化してから気づく | 原因特定に時間がかかる | CloudWatchとPerfMonで「重い前兆」を可視化し、アラートで先回り |
よくある質問（同じ悩みを持つ人がつまずくポイント）
termsvcsが高CPUなら、まずRDSの再起動で直しますか？
一時的に軽くなることはありますが、CPUクレジット枯渇が原因の場合、根本は解決しません。しばらくすると再発しやすく、むしろ原因特定が遅れます。まずはEC2側の指標（クレジット残高など）と発生時刻の一致を確認するのが近道です。
ユーザー数が減っているのに重いのはなぜ？
「ユーザー負荷」以外の要因（基盤の制限、バックグラウンドタスク、ストレージI/O低下、ネットワーク品質の悪化）が強く影響している可能性があります。特にT系では、少人数でも“クレジットが尽きる”と体感が一気に悪化します。
非バースト系に変えたら必ず解決しますか？
CPUクレジット枯渇が原因であれば改善が見込めます。一方で、原因がディスクI/Oやアプリの不具合、クライアント側の再接続ループなどの場合は別の対処が必要です。本記事のチェックリスト順に「基盤→OS→クライアント」の順で潰すと迷いにくいです。
まとめ：RDSのtermsvcs高CPUは「OSのせい」と決め付けない
Windows Server 2016 のRDS環境で termsvcs（Remote Desktop Services）が急に高CPUに見えるとき、まず疑うべきは基盤の性能制限です。特にEC2のバースト可能インスタンスでは、CPUクレジット枯渇がきっかけで体感が急落し、「termsvcsが重い」という現象として表面化します。CloudWatchでクレジット残高と発生時刻を突き合わせ、必要ならインスタンス移行・タイプ変更・Unlimitedなどで根本対策を行いましょう。
コメント