【spark】マイクラサーバーが重い原因をコマンドで特定する方法

• TPSは表示できるようになったが、体感で重いままで、どのプラグインが犯人か絞り込めない
• 人数が多くて、プラグインを1つずつ止めて再起動して確認する切り分けが現実的にできない
• Docker・Pterodactyl環境で運営していて、sparkがそもそも動くのか不安

TPSが下がっている画面を見ながら、どのプラグインを疑えばいいのか分からず、結局全部を疑ってしまう人は多いはずです。

mcsrv24.comでは、TPSの確認だけで終わらせず、原因を数値で特定するところまでを手順として整理しています。

TPSやMSPTは、サーバー全体の処理が遅れているかどうかを示す指標であり、原因を1つのプラグインや処理まで絞り込むための指標ではありません。

この記事では、次の内容を順番に説明します。

• sparkのprofilerで重い処理を計測する手順
• 一瞬のラグスパイクだけを捕まえる方法
• サーバー全体の状態をレポートで確認する方法
• Docker・Pterodactyl環境で気をつけること

読み終えるころには、TPSの数値だけでなく、どのプラグインや処理が重いのかをコマンドで特定できます。

プラグインを1つずつ止めて再起動する手間をかけずに、原因を絞り込めるようになります。

sparkとは？Paper同梱の負荷診断プラグイン

sparkは、マイクラサーバーの重い処理をコマンドだけで特定できる負荷診断プラグインです。

Paper 1.21以降のサーバーには標準で同梱されており、追加のインストール作業なしにコマンドを打つだけで使えます。

sparkには次の3つの機能があります。

• profiler: サーバー内の処理を細かく計測し、どのプラグインやMODが重いかを数値で示す
• tickmonitor: 処理が重くなった瞬間のtickを自動で検知し、通知する
• health: TPSやCPU、メモリなどサーバー全体の状態を1つのレポートにまとめる

以前はTimingsというツールで同じような計測を行っていましたが、Timingsは現在非推奨で、Paperではデフォルトで無効になっています。

これからサーバーの負荷を調べるなら、Timingsではなくsparkを使います。

TPSだけでは重い原因まで分からない理由

TPSだけを見ても、重い原因がどのプラグインや処理にあるのかまでは分かりません。

TPSは、1秒あたりに処理できたtickの回数の平均で、サーバー全体がどれだけ遅れているかを示す指標です。

一方でMSPTは、1回のtickの処理にかかった時間そのものを表す数値です。

TPSが下がっている、あるいはMSPTが50msを超えていることまでは、この2つの指標で確認できます。

ただし、TPSやMSPTの数値だけでは、重くしている原因がどのプラグインなのか、どの処理なのかまでは分かりません。

すでにTPSを確認していて、数値が正常値を下回っていることまで分かっているなら、次はsparkのprofilerで原因を絞り込む段階に進みます。

計測を開始して結果を読むまでの基本の流れ

sparkのprofilerは、次の流れで使います。

1. /spark profiler startで計測を開始する
2. 重くなるタイミングを含めて数分から十分程度待つ
3. /spark profiler stopで計測を終了する
4. 生成されたレポートのURLを開く

各コマンドとオプションは次の通りです。

計測を止め忘れる不安がある場合は、startのタイミングで--timeoutを付けます。

指定した秒数が経過すると、stopを打たなくても自動で計測が終了し、レポートが生成されます。

/spark profiler start --timeout 600

上記は、10分後に自動で計測を止める例です。

計測を打ちっぱなしにする心配がなくなるので、まずは--timeoutを付けて実行します。

一瞬のラグスパイクだけを捕まえる方法

一瞬だけ発生するラグスパイクは、通常の計測時間では捕まえにくい問題です。

sparkでは、次の2つの方法でラグスパイクだけを狙って記録できます。

• 重いtickが起きた瞬間だけ通知する
• 一定時間以上かかった処理だけを記録する

この2つは似た用途に見えますが、使うコマンドもオプションも別物です。

重いtickが起きた瞬間だけ通知する

/spark tickmonitorは、他のサブコマンドを付けずに単独で実行します。

実行するたびにON/OFFが切り替わる、トグル式のコマンドです。

/spark tickmonitor

主なオプションは次の通りです。

• --threshold <percent>: 平均より指定した割合以上遅いtickを検知する
• --threshold-tick <ms>: 指定した処理時間（ミリ秒）を超えたtickを検知する
• --without-gc: ガベージコレクションによる遅延を検知対象から除外する

通知はコンソールに表示されるだけで、処理の中身までは記録しません。

中身を確認したい場合は、次のprofilerの--only-ticks-overを使います。

一定時間以上かかった処理だけを記録する

重いtickだけを狙って処理の内訳を記録したい場合は、profilerの--only-ticks-overを使います。

/spark profiler start --only-ticks-over 100

目安は50〜100ms程度で、通常のtick処理時間である50msを上回る値を指定します。

tickmonitorが重いtickの発生をリアルタイムで知らせる役割なのに対し、こちらは重いtickの中身だけを狙って記録する役割です。

サーバー全体の健康状態をレポートで確認する

/spark healthを実行すると、サーバー全体の状態をまとめたレポートがその場に表示されます。

/spark health

レポートには多くの項目が並びますが、初心者が読み取るのはTPS、CPU使用率、メモリ使用率の3点で十分です。

これ以外の項目は、原因を特定したあとに詳しく調べれば足ります。

チームやDiscordで結果を共有したい場合は、--uploadを付けて実行します。

/spark health --upload

アップロードすると、レポートがビューア上のURLとして発行され、リンクを送るだけで他の人にも同じ画面を見せられます。

メモリの詳細も一緒に確認したい場合は、--memoryを付けます。

/spark health --memory

DockerやPterodactylでsparkを使うときに知っておくこと

Docker環境やPterodactylパネルでは、sparkの一部機能が制限を受けます。

主な症状は次の2つです。

上記の対処ができない環境でも、sparkが使えなくなるわけではありません。

診断結果から次にやることを決める

profilerの結果を読んだあとにやることは、原因が絞れたかどうかで変わります。

次のどちらに当てはまるかで、進む方向を決めます。

• ワールド生成が重いと分かった場合
• sparkだけでは原因が絞れない場合

どちらの場合も、profilerの結果に出てきた処理名を手がかりに次の一手を選びます。

ワールド生成が重いと分かった場合

profilerの結果で、チャンク生成やワールド関連の処理が上位に並んでいる場合、原因はプラグインではなく地形生成そのものです。

この場合はプラグインを疑うより、探索前にワールドを生成しておく対策のほうが効果的です。

Chunkyでワールドを事前生成する方法を使うと、プレイヤーが探索する前にチャンク生成を済ませておけます。

sparkだけでは原因が絞れない場合

profilerの結果を見ても、特定のプラグインや処理に負荷が集中しておらず、原因を1つに絞れないこともあります。

この場合は、プラグイン以外の要因が絡んでいます。

原因をプラグインに限定せず、マイクラサーバーが重い原因を一通りチェックする記事で、メモリやMob、回線まで含めて洗い出せます。

よくある質問

まとめ：sparkでラグの原因を数値で特定する

TPSやMSPTだけでは、重くしている原因がどのプラグインや処理なのかまでは分かりません。

sparkのprofilerを使うと、処理ごとの負荷を数値で確認でき、プラグインを1つずつ止めて再起動する切り分けをせずに原因を絞り込めます。

一瞬のラグスパイクにはtickmonitorとprofilerの--only-ticks-overを使い分け、サーバー全体の状態はhealthで把握します。

Docker・Pterodactyl環境で一部機能が制限されても、sparkはJavaサンプラーへ自動的に切り替わり、計測自体は続けられるので安心です。

原因がワールド生成に絞れたならChunkyでの事前生成、プラグイン以外の要因まで疑うならマイクラサーバーが重い原因を一通りチェックする記事へ進みます。

spa この記事を書いた人

サーバーの構築と運用を繰り返して4年。その経験をもとに記事60本以上を執筆。

プロフィール詳細 →