2026.10.04広告・PRを含む記事です
【spark】マイクラサーバーが重い原因をコマンドで特定する方法
- TPSが低下してラグいけれど、どのプラグインが原因なのか絞り込めない
- 参加者が多くて、プラグインを1つずつ止めて再起動する調査ができない
- DockerやPterodactyl環境でも問題なく負荷診断ができるのか不安
サーバーがラグいとき、何となくプラグインを停止して再起動を繰り返しても解決には時間がかかります。
Paperサーバーなどに標準搭載されている診断ツールsparkを使えば、サーバーを稼働させたまま、どのプラグインやエンティティが処理時間を圧迫しているかをコマンド1つで特定できます。
この記事では、sparkを使った重い処理の計測手順から、突発的なラグスパイクの特定方法まで分かりやすくまとめました。
読み終えるころには、勘に頼らず数値で原因を突き止められるようになり、無駄な再起動をせずにサーバーの軽さを取り戻せます。
サーバーが重いけれど、どのプラグインが原因なのか見当がつかないな。
sparkならサーバーを再起動せず、プレイヤーがログインした状態のまま本番の負荷を計測できるよ。
sparkとは？Paper同梱の負荷診断プラグイン
sparkは、マイクラサーバーの重い処理をコマンドだけで特定できる負荷診断プラグインです。
Paper 1.21以降のサーバーには標準で同梱されており、追加のインストール作業なしにコマンドを打つだけで使えます。
sparkには次の3つの機能があります。
| 機能名 | コマンド例 | 用途と特徴 |
|---|---|---|
profiler | /spark profiler start | サーバー内の処理を細かく計測し、どのプラグインやMODが重いかを数値で示します。 |
tickmonitor | /spark tickmonitor | 処理が重くなった瞬間のtickを自動で検知し、コンソールへ通知します。 |
health | /spark health | TPSやCPU、メモリなどサーバー全体の状態を1つのレポートにまとめます。 |
以前はTimingsという診断ツールが使われていましたが、現在は非推奨となりPaperでは既定で無効化されています。これから負荷を調査する場合はsparkを使用します。
Modrinthのspark配布ページ（/mod/spark）で配布されているのは、FabricやForge、NeoForge、Quilt向けのMod版です。
Paperサーバーではsparkが同梱されているため、このMod版を別途探す必要はありません。
Spigot系サーバーでプラグイン版を導入する場合は、HangarなどPaper・Spigot向けの配布経路からダウンロードします。
TPSだけでは重い原因まで分からない理由
サーバーの遅延を把握する際、TPSの確認だけでは不十分です。
マイクラの世界は、1秒間に20コマ進むパラパラ漫画のような仕組み（tick）で動いています。1秒間に20コマ進んだ状態がTPS 20で、正常なサーバーの基準です。
1コマの処理にかかった時間がMSPTです。1秒（1000ミリ秒）を20コマで割ると、1コマあたり50ミリ秒以内に処理が終わればTPS 20を保てます。
大量のMobや重いプラグインによって1コマに80ミリ秒以上かかると、TPSが低下してラグが発生します。
| 指標 | 何がわかるか | 正常値の目安 |
|---|---|---|
| TPS | 1秒あたりに処理できたtickの回数の平均 | 20 |
| MSPT | 1回のtickの処理にかかった時間 | 50ms以下 |
TPSやMSPTは「全体として遅延が発生しているか」を測るメーターです。実際にどのメソッドやタスクが時間を食っているのかを割り出すには、処理内訳を細かくサンプリングするsparkのprofilerが必要です。
計測を開始して結果を読むまでの基本の流れ
sparkのprofilerは、次の流れで使います。
/spark profiler startで計測を開始する- 重くなるタイミングを含めて数分から十分程度待つ
/spark profiler stopで計測を終了する- 生成されたレポートのURLを開く
使うコマンドは多くありません。
| コマンド | 内容 |
|---|---|
/spark profiler start | 計測を開始する |
/spark profiler stop | 計測を終了してレポートを生成する |
/spark profiler cancel | 計測を中断してレポートを作らずに破棄する |
/spark profiler info | 現在計測中かどうかを確認する |
/spark profiler open | 計測を停止せずに稼働中のプロファイラー結果を表示する |
--timeout <秒> | 指定した秒数が経過すると自動で計測を停止する |
--thread * | 全スレッドを対象に計測する |
--alloc | CPU使用率の代わりにメモリ割り当てを計測する |
計測を自動で止めたい場合は、開始時に--timeoutオプションを付けます。指定した秒数が経過すると自動で計測が終了し、レポートが生成されます。
/spark profiler start --timeout 600例えば--timeout 600と指定すると、10分後に自動停止するため止め忘れの心配がありません。
一瞬のラグスパイクだけを捕まえる方法
一瞬だけ発生するラグスパイクは、通常の計測時間では捕まえにくい問題です。
sparkでは、次の2つの方法でラグスパイクだけを狙って記録できます。
- 重いtickが起きた瞬間だけ通知する
- 一定時間以上かかった処理だけを記録する
この2つは似た用途に見えますが、使うコマンドもオプションも別物です。
ラグ検知と処理記録の違い
tickmonitorの--threshold-tickを使うと、重いtickをリアルタイムで検知して通知します。
profiler startの--only-ticks-overは、重いtickだけを狙って処理の中身を記録するためのオプションです。
コマンド自体が違うため、片方に付けたつもりのオプションがもう片方に反映されることはありません。
重いtickが起きた瞬間だけ通知する
/spark tickmonitorは、他のサブコマンドを付けずに単独で実行します。
実行するたびに有効と無効が切り替わる、トグル式のコマンドです。
/spark tickmonitorしきい値の指定にはオプションを使います。
| オプション | 引数 | 動作内容 |
|---|---|---|
--threshold | <percent> | 平均より指定した割合以上遅いtickを検知します。 |
--threshold-tick | <ms> | 指定した処理時間（ミリ秒）を超えたtickを検知します。 |
--without-gc | なし | ガベージコレクションによる一時的な遅延を検知対象から除外します。 |
通知はコンソールに表示されるだけで、処理の内訳までは記録されません。
異常が発生した瞬間の処理内容まで詳しく調べたい場合は、後述するprofilerの--only-ticks-overと組み合わせて活用します。
一定時間以上かかった処理だけを記録する
スパイク発生時の詳細ログを残したいときは、--only-ticks-overオプションを付けてprofilerを開始します。
/spark profiler start --only-ticks-over 100指定した処理時間（ミリ秒）を超えた重いtickのみが抽出して記録されます。通常のtick基準である50msを上回る、50〜100ms程度を指定するのが目安です。
サーバー全体の健康状態をレポートで確認する
/spark healthを実行すると、サーバー全体の状態をまとめたレポートがその場に表示されます。
/spark healthレポートには多くの項目が並びますが、初心者が読み取るのはTPS、CPU使用率、メモリ使用率の3点で十分です。
これ以外の項目は、原因を特定したあとに詳しく調べれば足ります。
チームやDiscordで結果を共有したい場合は、静的なレポートをWeb上にアップロードする/spark health uploadが便利です。
/spark health upload発行されたURLのリンクを送るだけで、他の人にも同じ画面を共有できます。
JVMのメモリ使用状況をさらに詳しく調べたい場合は、/spark health show --memoryを指定してください。
/spark health show --memoryDockerやPterodactylでsparkを使うときに知っておくこと
Docker環境やPterodactylパネルでは、sparkの一部機能が制限を受けます。
主な症状は次の2つです。
| 症状 | 原因 | 対処 |
|---|---|---|
| profiler起動時にlibstdc++関連のエラーが出る | ネイティブライブラリの不足 | Alpineベースのイメージならapk add libstdc++、Debian・Ubuntuベースならapt install libstdc++6を実行する |
| perf-eventsが使えないという表示が出る | perf-eventsを使うための権限（SYS_ADMIN）が付与されていない | Docker起動時に--cap-add SYS_ADMINを付ける必要があるが、多くのPterodactyl利用者はホスト側の権限のため自分では設定できない |
この対処ができない環境でも、sparkが使えなくなるわけではありません。
perf-events権限不足時の自動フォールバック
perf-eventsの権限が足りない環境では、sparkが自動的にJavaサンプラーへ切り替わり、計測を続けます。
Javaサンプラーは精度がやや落ちるものの、profiler・tickmonitor・healthはそのまま動作します。
Pterodactylでホスト側の権限を自分で変更できない場合は、無理に設定を探さず、この精度差を前提に使って問題ありません。
診断結果から次にやることを決める
profilerの結果を読んだあとにやることは、原因が絞れたかどうかで変わります。
次のどれに当てはまるかが、進む方向の分かれ目です。
- ワールド生成が重いと分かった場合
- メモリやCPUの使用率が上限に張り付いている場合
- sparkだけでは原因が絞れない場合
いずれの場合も、profilerの結果に出てきた処理名を手がかりに次の一手を選びます。
ワールド生成が重いと分かった場合
profilerの結果で、チャンク生成やワールド関連の処理が上位に並んでいる場合、原因はプラグインではなく地形生成そのものです。
この場合はプラグインを疑うより、探索前にワールドを生成しておく対策のほうが確実です。
Chunkyでワールドを事前生成する方法を使うと、プレイヤーが探索する前にチャンク生成を済ませておけます。
メモリやCPUの使用率が上限に張り付いている場合
/spark healthのメモリ使用率が常に高止まりしている場合、特定の処理ではなく容量そのものが足りていません。
先にメモリ割り当ての目安を見て、搭載メモリに対する割り当てが妥当かどうかを確かめてください。
割り当てを増やす余地がないときは、人数別のスペック目安と実際の参加人数を見比べてみてください。
レンタルサーバーを利用しているなら、管理画面からプランを変更してメモリを増やせます。自宅PCのメモリが限界に達している場合は、ConoHa for GAMEのようなメモリ容量を柔軟に選べる環境への移行も検討してみてください。
sparkだけでは原因が絞れない場合
profilerの結果を見ても、特定のプラグインや処理に負荷が集中しておらず、原因を1つに絞れないことも珍しくありません。
この場合は、プラグイン以外の要因が絡んでいます。
原因をプラグインに限定せず、マイクラサーバーが重い原因を一通りチェックする記事で、メモリやMob、回線まで含めて洗い出せます。
よくある質問
Q診断結果を公開URLにせず、サーバー内へ保存できますか？
`/spark profiler stop --save-to-file`を使うと、結果をsparkの設定フォルダ内へファイルとして保存できます。プレイヤー名などを外部へ共有したくない場合は、公開URLを発行せず管理者だけで確認します。
Q一般プレイヤーもspark profilerを実行できますか？
通常は実行できません。sparkやspark.profilerなどの権限が必要です。負荷測定の結果には運営情報が含まれるため、コンソールか信頼できる管理者だけで実行します。
まとめ：sparkでラグの原因を数値で特定する
サーバーの動作が不安定になったときは、闇雲に設定を変えるのではなく、sparkの診断結果をもとに対処するのが一番の近道です。
プラグインを片っ端から止めて再起動する前に、sparkで計測して原因の当たりを付けるのが確実だよ。
- profilerで処理ごとの負荷を数値で確認し、原因プラグインを絞り込む
- 一瞬のラグスパイクはtickmonitorと
--only-ticks-overを使い分ける - サーバー全体の状態はhealthで把握する
- DockerやPterodactyl環境でも自動フォールバックで計測可能
原因がワールド生成に絞れたならChunkyでの事前生成、メモリやCPUが上限なら割り当てとスペックの見直し、プラグイン以外の要因まで疑うなら重い原因の総合チェックへ進んでみてください。
自分で原因を切り分けきれない場合は、構築の相談をすることもできます。
