Minecraft Java版のサーバーで、ブロックが戻る、モブの動きが遅い、数秒だけ固まる。そんなときは、メモリを増やす前にsparkで重い時間帯を計測し、どの処理に時間がかかっているかを調べましょう。sparkは負荷の原因を探す道具で、入れるだけで軽くなるMODではありません。
最初は「TPSとMSPTを確認 → 症状が出る場面を記録 → レポートの大きい処理をたどる」の順で十分です。Paper 1.21以降はsparkが同梱されているため、追加インストールをせずに始められます。
この記事はMinecraftの非公式ガイドです。MojangまたはMicrosoftによる承認・提携はありません。
sparkで調べるのは、まずサーバー側の遅さ
この記事は、自分で管理するJava版の専用サーバーを対象にします。サーバー全体の処理が遅いのか、自分のPCの画面描画や通信が遅いのかを分けるのが入口です。権限のない参加者は、管理者に計測を依頼してください。
- 全員のモブや採掘が遅い：サーバーのTPS・MSPTを確認する
- 自分の画面だけカクつく：描画側のFPSも確認する。サーバーのレポートだけで原因を決めない
- 特定の人だけ反応が遅い：同じ時間のTPSに加えて、通信の遅延も比べる
これは調査の入口で、症状だけで原因を断定するものではありません。たとえば平均TPSが正常でも、短い停止が平均に埋もれている場合があります。
導入先を確認する：Paperは同梱、MODサーバーは対応するファイル
| サーバー環境 | 最初にすること |
|---|---|
| Paper 1.21以降 | まずゲーム内で /spark を確認。同梱されているので、通常は追加JARが不要 |
| spark未導入の対応プラグインサーバー | 対応するsparkのJARをサーバーの plugins フォルダーへ入れ、再起動 |
| Fabric・Forge・NeoForgeなど | ローダーとMinecraftのバージョンが合うJARを、サーバーの mods フォルダーへ入れ、再起動 |
入手先はspark公式ダウンロード（英語）です。最新のファイルを無条件に選ばず、使っている環境に合わせます。古いMinecraft向けの項目もありますが、公式は旧バージョンを積極的なサポート対象としていません。
サーバーを調べるときのコマンドは /spark。クライアント用の /sparkc と取り違えないでください。操作にはsparkの権限、またはサーバーのOP権限が必要です。コマンドを使うために、参加者全員へOP権限を配る必要はありません。導入先と同梱条件は公式の導入手順（英語）で確認できます。
TPSとMSPTは、二つを一緒に見る
ゲーム内で次を実行します。サーバーコンソールから入力する場合は、先頭の / を外してください。
/spark tpsTPSは1秒間に進むゲーム処理の回数、MSPTは1回の処理にかかったミリ秒です。通常の20 TPSでは、1回に使える時間は50ミリ秒。MSPTが継続して50を超えると、処理が追いつきにくくなります。
中央値だけで安心せず、最大値や95パーセンタイルも見ます。95パーセンタイルは、観測した値の95％がその値以下に収まる位置です。普段は軽くても、ときどき長いtickがあるサーバーを見落としにくくなります。
一方、最大値が一度だけ高いことと、ずっと重いことは別です。「全員で遠征したとき」「自動装置を動かした直後」など、症状が出た時刻と行動も一緒にメモしてください。
計測前に確認：通常のレポートは外部へアップロードされる
通常のprofilerレポートは、終了時にsparkのサービスへ送信され、閲覧用URLが表示されます。既定のデータ送信先は spark-usercontent.lucko.me です。自分だけが見られる管理画面として扱わず、URLを渡した相手が内容を確認できる共有資料と考えてください。
レポートには処理名やプラグイン・MODの情報が含まれます。公式のデータ例では、実行者の名前・UUID、サーバーの種類やバージョンもメタデータに含まれています。公開サーバーの構成を広めたくない場合は、先に管理者同士で共有範囲を決めましょう。根拠は公式のデータ形式（英語）と公式の設定一覧（英語）です。
- 相談先へ渡す前に、レポート内の名前・構成・バージョンを確認する
- サーバーのパスワード、管理パネルのログイン情報、APIキーを相談文やコメント欄へ書かない
- スクリーンショットの一部を隠しても、元のレポートURLを添えれば元データを見られる点に注意する
外部に送れない環境では、後述のファイル保存を選びます。「URLを誰にも送らなければアップロードされない」という仕組みではありません。
重い場面を記録する：まず現在の計測状態を見る
/spark profiler info現行sparkでは、起動時からバックグラウンド計測が有効な構成があります。公式設定の既定値も有効です。別の管理者が計測中の場合は、その記録を勝手に止めず、まず目的と時間帯を確認してください。
外部へのアップロードが問題ない場合
既に計測中で、その記録に症状が含まれているなら、/spark profiler open で計測を続けながらviewerを開けます。これは外部サービスへのデータ送信を伴います。新しく期間を区切って調べる場合は、不要な既存計測を残す必要がないことを確認してから /spark profiler cancel で取り消し、次を実行します。
/spark profiler start --timeout 600600は秒数で、10分後に終了してレポートURLが返ります。この間に、問題が起きる場所や行動を普段と同じ条件で再現します。早く終了するなら /spark profiler stop。いずれも通常はアップロードされます。10分の例はPaper公式の計測案内（英語）に沿っています。
誰もいない時間に採った軽いレポートでは、人数が増えた時の遅さを説明できません。症状が出なかった場合は、その事実をメモして、重くなる時間帯に改めて計測します。
アップロードせず、サーバー内のファイルに保存する場合
既に動いている計測をそのまま保存したい場合は、次のコマンドで終了・保存します。
/spark profiler stop --save-to-file新しい計測を始める場合は、既存記録を上のコマンドで保存するか、不要なら /spark profiler cancel で取り消してから、/spark profiler start を実行します。症状を記録した後は、同じ stop --save-to-file で終了・保存してください。
sparkの設定ディレクトリー配下に保存されます。表示された保存先を確認してください。外部送信を避けたいこの手順では、自動終了・アップロードにつながる --timeout や、viewerを開く open を使いません。保存したファイルを後からWebサービスへ送るときも、別途共有内容を確認します。
計測の状態確認、終了、取消、ファイル保存の違いは公式コマンド一覧（英語）を参照してください。cancel はその計測結果をアップロードせず取り消す操作で、既に送信したレポートを削除する命令ではありません。
数秒だけ固まるなら、遅いtickに絞って採り直す
短い停止は、長時間の平均に埋もれることがあります。まずtickの遅延を通知するモニターを使い、止まった瞬間と数値を照合します。
/spark tickmonitor --threshold-tick 50これは50ミリ秒を超えたtickを通知する設定です。通知が多すぎるときは、普段のMSPTと停止時の長さを見て、調査に使うしきい値を決めます。監視が終わったら、引数なしの /spark tickmonitor をもう一度実行して停止を確認します。
たとえば「普段は50ミリ秒未満だが、ときどき200ミリ秒以上になる」なら、100ミリ秒を超えるtickだけ採る方法があります。既存計測の扱いと外部送信を確認したうえで、次を実行します。
/spark profiler start --only-ticks-over 100 --timeout 600100は万能の推奨値ではなく、この例で遅いtickを拾うための値です。症状のtickより高い値にすると、肝心の停止を記録できません。また、このレポートは遅いtickだけを抜き出したものなので、通常計測の割合とそのまま比較しないでください。ファイル保存が必要なら --timeout 600 を付けず、記録後に stop --save-to-file で終了します。
レポートは「100％」に驚かず、実際に働いている処理をたどる
viewerでは、まず記録した時間帯に症状が含まれているか確認します。続いて通常の専用サーバーなら Server thread を展開し、割合の大きい枝をたどってください。表示される処理名はMinecraftやサーバーの種類・バージョンによって変わります。
- スレッド先頭の100％は、CPU全体の使用率ではない。そのスレッドを計測した時間を基準にした表示です
- waitForNextTick・sleep・parkのような待機を区別する。次のtickまで待つ処理の割合が大きいことは、余裕がある状態でも起こります
- tick側の枝を開く。ワールド・エンティティ・プラグインなど、どの処理へ時間が流れているかを追います
- 名前だけで削除対象を決めない。上位の行には、その先で呼ばれた処理の時間も含まれます。さらに展開し、何をしているかを確かめます
待機と処理の違いは公式のtick loop解説（英語）が参考になります。平均では待機が多くても、短い停止がないとは限りません。その場合は前節の遅いtickだけの計測へ戻ります。
処理名が読みづらいときは、viewerのマッピング設定が合っているかを確認します。表示される環境では Sources View でプラグイン・MODごとに見る方法もあります。Sourcesがない場合も、通常のツリーを展開して調べられます。
プラグイン名が上位に出たことは、調査先を絞る手掛かりです。不具合の確定診断ではありません。重い処理につながる操作や設定を一つずつ変え、同じ人数・場所・計測条件で採り直すと、変更の効果を比べやすくなります。
読み取れた結果を、次の確認につなげる
| 観測したこと | 次にすること |
|---|---|
| 重い場面が記録されていない | 同じ症状が出る人数・行動・時刻で採り直す。レポートが軽いだけで解決扱いにしない |
| エンティティなど特定処理が大きい | 何を動かしていたかと照合し、装置停止など戻せる変更で比較する。いきなり全モブを削除しない |
| 特定MOD・プラグインの呼び出しが目立つ | 対応バージョン・既知の問題を確認。外す試験はバックアップと複製環境を用意して行う |
| メモリの表示と契約容量が合わない | 管理パネルや実際の割り当てと照合。コンテナーではsparkのCPU・メモリ値が正しく報告されない場合がある |
最後の注意はspark公式のメトリクス説明（英語）にあります。メモリ割り当てを変更する必要があると判断した場合は、Minecraftサーバーのメモリ割り当て変更手順も確認してください。sparkの割合だけから、必要なメモリ量を一律に決めることはできません。
相談するときは、URLと「重かった瞬間」をセットにする
レポートの中身を確認し、共有してよい相手に絞ったうえで、次の情報を添えると状況が伝わります。
- Minecraftのバージョン、Paper・Fabricなどのサーバー種類、sparkのバージョン
- 症状、発生時刻、参加人数、そのときの行動
- 通常計測か、only-ticks-overを使った計測か。使ったしきい値と計測時間
- 症状が実際に起きたレポートURLと、気になった処理名
- 直前に変えた設定・MODと、元に戻した結果
最初の目標は「重いMODを一つ決めつける」ことではなく、症状が出る条件を記録し、次に確かめる処理を絞ることです。計測前後の条件をそろえれば、設定を変えるたびに改善したのかを判断できます。
画像：© spark contributors。spark公式ドキュメントの画像は spark-docs（英語） の CC BY-SA 4.0（英語） に基づき掲載。本文の画像は内容を変更せず使用。カバーは公式viewer画像をトリミング・暗色加工し文字を追加したもので、カバーの翻案部分も同ライセンスです。Minecraftの名称・ゲーム画面に関する権利はMojang／Microsoftに帰属します。
コメント