Minecraftのログでよく出る3つのラグ系メッセージは、同じ意味ではない。Can't keep up! Is the server overloaded? は、サーバーは動き続けているが処理が追いついていないという意味。A single server tick took 60.00 seconds は、内蔵の緊急停止機能がサーバーを強制終了したという意味。Exception in server tick loop は、具体的なプログラムエラーがゲームループを壊したという意味だ。3つを同じものとして扱うと、たいてい間違った場所を直すことになる。
3つのメッセージを見分ける
Minecraftはゲームワールドを1秒に20回計算する。この1回の処理をTickと呼び、最大でも50ミリ秒以内に終わる必要がある。君が感じるラグはすべて、この1つの数値からのズレだ。
| ログメッセージ | 実際に起きたこと | サーバーはまだ動いている？ |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Tickが50 msより長くかかり、サーバーが遅れを取り戻そうとしている | はい。ただし体感でかなり重い |
A single server tick took 60.00 seconds + Considering it to be crashed |
1つのTickがmax-tick-timeを超え、Watchdogがプロセスを終了した |
いいえ。強制終了済み |
Exception in server tick loop |
エラーがメインループまで到達した | いいえ。多くの場合Crash Reportあり |
Dispatched async TPS command（Paperの警告） |
私たちのTPS計測が外部からサーバーへ問い合わせている | はい。これは正常 |
最後の行はよく混乱を招く。Paperは外部から来る問い合わせをすべて警告として記録する。これは約5分ごとに行う予定どおりのパフォーマンス計測で、エラーでも、君のプレイへの干渉でもない。
Watchdogメッセージでは上を読むのが最重要
WatchdogによるKillは症状であって原因ではない。それが示すのは、何かが許可された時間より長くサーバースレッドをブロックした、ということだけだ。何がブロックしたかは別の場所に書かれている。
ケースは2つあり、取るべき対処はまったく違う。
ケース1 — Watchdogが先に来た。 Watchdog行の前には通常のゲーム動作が書かれている。この場合、Tick時間そのものが重要な情報だ。稼働中に何かがサーバーを固めたことになる。
ケース2 — Watchdogが後から来た。 Watchdog行の前にすでにStopping serverやPreparing crash reportがある。この場合、サーバーはその前にすでに死んでいたかシャットダウン中で、Watchdogは固まった終了処理を片付けただけだ。
この2つ目のケースは珍しくない。2026年8月22日のあるサポート事例では、サーバースレッドが13:20:15にクラッシュし、正常なStopping serverを開始した。そして60秒後に初めてWatchdogが発火した。そこでTick時間を原因だと判断すると、運営者は本当のエラーメッセージを見逃すことになる。本当の原因は1分ほど上にあった。だから私たちのコンソール解析では、Watchdogのヒットを意図的に最後に評価する。同じログ区間により具体的なシグネチャがあれば、「1つのTickが遅かった」ではなく、その具体的な内容を表示する。
原因へたどり着く手順
1. パネルでTPS推移を確認する
パネルで自分のサーバーを開く。**「Performance (letzte 24h)」**の下にTPS推移が表示される。サーバー稼働中は約5分ごとに計測される。グラフの形だけでも多くのことが分かる。
- 特定時刻に鋭く落ち込む → 何かのイベント。時刻をログと照合しよう。ワールド生成、バックアップ、未探索地形にいるプレイヤー、Pluginのタスクなど。
- ずっと低い値が続く → 構造的な過負荷。再起動ではなく、負荷を減らす必要がある。
- のこぎり歯のようなパターン → メモリ圧迫でよく見られる。サーバーが処理し、Garbage Collectionが中断し、それが繰り返される。
長い時間帯で低い値が続くと、パネルが自動で**「TPS dauerhaft niedrig」**という警告を出す。
2. MSPTを測る — TPSだけでは足りない
コンソールで/spark tpsを入力する。このコマンドは2つの数値を返し、重要なのは2つ目だ。
- TPS — 1秒あたりのTick数。最大20。
- MSPT — 1Tickあたりのミリ秒。50 msまでなら健全。
なぜMSPTなのか？ Bukkit、Spigot、Paperはクラッシュを避けるためにサーバープロセスを抑制する。そのため表示上はきれいな20 TPSでも、実際にはサーバーがすでに限界近くで動いていることがある。MSPTが45 msなら、Mobファーム1つで目に見えるラグに届く状態だ。TPS表示がまだ完璧に見えていても同じだ。
Paper 1.21以降ではsparkがすでに含まれているので、何もインストールする必要はない。
3. 原因をプロファイルする
どのPluginが悪いのかを勘で決めない。測定しよう。
/spark profiler start --timeout 120
この2分間で、ラグが出る状況を再現する。その後、サーバーが出力する結果リンクを開く。レポートはTick時間がどこへ使われているかを時間割合順に示す。特定のMod、Pluginタスク、Chunk読み込み、Entity処理、Garbage Collectionなどだ。
ここが、このガイドと「RAMをもっと買おう」という話の分かれ目だ。Profilerは、一般的な推奨表では答えられない問いに答える。君のサーバーでは、具体的に何が時間を食っているのか？
4. 狙って負荷を減らす
Profilerが示した内容で対処が決まる。
| Profilerが示すもの | 効く対処 |
|---|---|
| Chunk読み込み、ワールド生成 | simulation-distanceを下げる（デフォルト10、最小3）— view-distanceより効きやすい。計算時間を使うのはシミュレーションされるChunkだけだから |
| Entity処理 | Mobファームを制限する、動物を放し飼いではなく囲う、アイテムの山を片付ける |
| Redstone / Block Tick | RepeaterのループではなくObserverを使ったRedstoneクロックにする、常時稼働装置を止める |
| 単一のPluginまたはMod | 試しに無効化して再測定する。代替または新しいバージョンを探す |
| Garbage Collection | この場合は RAM増設が正しい答え。それまでは違う |
最後の点は重要だ。RAMが直せるのはメモリ問題だけ。RedstoneクロックがTick時間を食っているなら、より大きいプランにしてもサーバーは速くならない。プレイヤー数とModpackサイズに合うメモリ量は、私たちのMinecraft-RAM計算機で計算できる。
5. max-tick-time — 例外であって解決策ではない
この値はserver.propertiesにあり、Watchdogが介入するTick時間を決める。標準は60000ミリ秒、つまり60秒だ。この値を超えると、サーバーは自分自身を終了する。
ネット上の多くの手順では、ここで-1にしてWatchdogを無効化するよう勧めている。標準的な解決策としてそれをやってはいけない。 Watchdogは、本物のDeadlockに気づける唯一の内蔵機能だ。-1にすると、死んだサーバーがポート上で何時間も固まり続ける。プレイヤーは入れず、ログには理由が出ず、誰にも通知されない。君が消したのは表示であって、問題ではない。
上げる正当な理由は1つだけだ。既知の処理が正当に長くかかる場合。 典型例は大きなModpackの初回起動で、ワールド生成とMod初期化が合わさって1つのTickで1分を超えるケースだ。その場合、たとえば180000（3分）にするのは許容できる。ただし一時的に、そして初回起動に成功したら戻す前提で行う。
ログにException in server tick loopがある場合
このメッセージは3つの中で一番分かりやすい。原因を一緒に持ってくるからだ。直下または数行後にCaused by:行がある。そこに本当のエラーが書かれており、多くの場合、原因となったModまたはPluginの名前も含まれている。
手順:
Caused by:を探し、クラス名をメモする。- そこにMod名またはPlugin名が含まれていれば、原因は特定されている。
- エラーが変更後に出たなら（新しいMod、アップデート、新しいワールド）、まずその変更を戻す。
- それでも不明なら、該当セクション全体を時刻付きでサポートへ送る。
君のサーバーのコンソール解析は、これらの行を自動で検出し、認識した各メッセージを頻度込みで分かりやすく説明する。別の場所から持ってきたログ断片しかない場合は、私たちのCrash Report Analyzerに貼り付けられる。私たちのサーバーを使っていなくても利用できる。
私たちが自動で引き受けること
- 手間なしのパフォーマンス計測。 TPSは約5分ごとに記録され、24時間分がパネルに表示される。Pluginを入れる必要はない。
- 長く弱い状態への警告。 信頼できる時間幅でパフォーマンスが低いままなら、自分で気づく前に通知される。
- 説明付きログ行。 検出されたメッセージには、原因と解決策が君の言語で分かりやすく表示される。該当するガイドがあればリンクも付く。
- 症状より原因を優先するルール。 同じログ区間にWatchdog Killより意味のあるエラーメッセージがあれば、それを表示する。
トラブルシューティング: 症状、確認、解決策
| 症状 | 確認 | 可能性が高い解決策 |
|---|---|---|
| 新しい地域を探索するときだけラグる | プレイヤーが未探索地形へ入ったときに発生する？ | ワールド生成。simulation-distanceを下げる、ワールドを事前生成する |
| 決まった時刻にラグる | 時刻を予定タスクと照合する | バックアップまたは再起動スケジュールの時間をずらす |
| サーバーがエラーなしで止まり、ログが突然終わる | 末尾にA single server tick tookがある？ |
Watchdog Kill。直前の1分を読む |
| TPSは20なのにカクつく | /spark tps — MSPTを見る |
TPS Limiterが負荷を隠している。MSPTで判断する |
| Mod追加後に発生 | Modを外して再測定する | Mod競合または負荷の高いMod |
| TPS推移がのこぎり歯になる | ProfilerでGarbage Collectionを確認する | メモリ圧迫。RAMを増やす |
| ログに「Dispatched async TPS command」 | その行だけで、他は異常なし | 何もしなくていい。私たちの計測 |
FAQ
どのTPS値からプレイヤーが気づく？
18 TPSくらいまでは、ゲーム内ではほとんど分からない。15を下回ると明らかに重くなる。ただしTPSだけを信じないでほしい。TPS Limiterが健全な数値を表示していても、サーバーがすでに限界で動いていることがあるので、MSPTも確認しよう。
RAMを増やすとラグに効く？
メモリが本当にボトルネックの場合だけ効く。ProfilerがGarbage Collectionを主な負荷として示すなら、答えはYes。RedstoneクロックやMobファームを示しているなら、RAMを増やしても変わらない。まず測って、それから買おう。
Watchdogを無効化すべき？
いいえ、恒久的にはやめよう。-1は、本物のフリーズを自動検出する唯一の仕組みを奪う。大きなModpackの初回起動のように、既知の遅い処理に対してmax-tick-timeを一時的に上げるのは許容できる。その後は戻す。
なぜ「Stopping server」の後にWatchdogメッセージが出る？
サーバーはすでにシャットダウン中で、その途中で固まったからだ。その場合Watchdogは、動作中のサーバーを倒したのではなく、固まった終了処理を片付けた。原因はStopping serverより前にある。
再起動は役に立つ？
目の前の遅れには効くが、原因には効かない。再起動のたびに短時間でラグが戻るなら、それは構造的な問題だ。その場合は測定しないと先に進めない。
view-distanceとsimulation-distanceの違いは？
view-distanceはプレイヤーがどこまで見えるかを決める。simulation-distanceはワールドが実際にどこまで計算されるかを決める。どちらも標準では10 Chunkだ。計算時間を使うのはシミュレーションされるChunkだけなので、simulation-distanceを下げる方が、見た目の損失を抑えながら負荷を大きく減らせる。
それでもラグる場合
サポートへ問い合わせる前に、3つを集めよう。最後に発生した正確な時刻、spark Profilerレポートのリンク、最後に追加したModまたはPluginの情報だ。これがあれば、一般的な最適化を一周するのではなく、ログ内の該当箇所を狙って確認できる。
ゲーム全般に共通する調整項目（再起動スケジュール、プラン選び、ネットワーク）は、Gameserver Performance verbessernのガイドにある。ModやPluginをきれいにインストールし、また削除する方法は、Minecraft Mods und Plugins installierenで説明している。
TPS計測、ログ説明、警告が追加作業なしで付いてくるサーバーが欲しい？ Minecraftサーバーを借りるで合うプランを見つけられる。
出典と確認環境
max-tick-time、Tickrate、距離設定: PaperMC — server.properties。標準値60000ミリ秒、超過時の強制終了、-1による無効化、view-distanceとsimulation-distanceの標準値10を説明している。- sparkはPaperに含まれる: PaperMC — Profiling。Paper 1.21以降では別ダウンロード不要。
- TPSよりMSPTを優先: spark — TPS and MSPT。サーバーが実際には遅く動いているのに、TPS Limiterがきれいな20を表示できる理由を説明している。
- Profilerコマンド: spark — Command Usage。
/spark profiler start --timeout <sekunden>と/spark profiler stopの出典。
確認環境: 2026年8月24日。標準値やコマンドは新しいサーバーバージョンで変わる可能性がある。不安な場合は、リンク先の開発元ドキュメントを確認しよう。