マイクラのサーバーが重い時の原因の切り分け｜メモリ・MOD・描画距離の順に確かめる

公開 2026年11月8日

マイクラのサーバーが重いときは、設定を変える前に「サーバーが本当に遅れているか」を測り、そのあとでメモリ、MOD（プラグイン）、描画距離の順に確かめるのが筋道になる。順番を決める理由は、1か所ずつ変えて結果を見ないと、どの変更が効いたのか分からなくなるから。この記事は、Java版の Paper を主に、統合版（Bedrock）の専用サーバーも一部扱う。

この記事は、Paper・spark・Microsoft Learn の公式資料で確かめた内容をまとめたもの。実際にサーバーを借りて試した記録ではなく、資料にもとづく整理である。確かめた日は 2026-11-07 で、バージョンが変わると既定値は変わる。サーバーの立て方は マイクラ Java版のマルチサーバーの立て方 と 統合版のサーバーの立て方 に書いた。

手順1：まず「どの重さか」を測る

「重い」には種類がある。ブロックを壊しても戻される、モブの動きがぎこちないといった症状は、サーバーの処理が遅れている疑いがある。画面のカクつきが自分のパソコンだけに出るなら、サーバーとは別の話になる。ここで扱うのは前者。

測る道具として、Paper には spark というプロファイラ（処理の重さを調べる仕組み）が組み込まれている。Paper の資料は、性能問題の原因を調べるために入っていると説明している。spark の資料にあるコマンドは次のとおり。

spark の「Finding lag spikes」のページは、1ティックが50ミリ秒を超えたところを、サーバーが追いつこうとし始める（遅れ始める）点だと説明している。1秒（1000ミリ秒）を50ミリ秒で割ると20になり、1秒あたり20ティックがこの境目にあたる計算になる（この20という数字は、このページには書かれていない）。1ティックの時間が50ミリ秒を超え続けるなら、サーバー側の処理が遅れている疑いが強い。

たまにだけ固まる場合は、同じページの手順が使える。/spark tickmonitor で長いティックを見張る（/spark tickmonitor --threshold-tick 50 とすると、50ミリ秒を超えたティックを知らせる）。チャットに出る通知と、ゲーム内でそのとき起きていたこと（誰かが大きな機械を動かした、など）を照らし合わせる。そのうえで /spark profiler --only-ticks-over <ミリ秒> で、指定した時間より長いティックだけを集めて調べる。値は50〜100の間で、遅いティックの時間より小さくするよう資料は勧めている。普通に集めると平均されて遅れが目立たなくなるため、というのが資料の理由。

手順2：メモリを確かめる

Paper の資料は、OutOfMemory のクラッシュや、GC の時間が長いといった問題がなければ、メモリの使用量が多いのは想定内だと書いている。使用量が高いこと自体は、不足の証拠にならない。見るのは次の2点。

• サーバーが OutOfMemory で落ちていないか（ログに出る）
• /spark gc や /spark health で、GC が長く、頻繁になっていないか

メモリの割り当ては、起動コマンドの -Xms（初期値）と -Xmx（最大値）で決める。書き方の例は Java版の記事 にある。足りないと分かったときの注意を、Paper の Aikar’s Flags のページから3つ。

• 共有のホストでは、使えるメモリを全部割り当てない
• -Xmx と -Xms は、利用できる量から1000〜1500MBほど減らす（メモリが尽きたり、OOM Killer にサーバーを止められたりするのを避けるため）。8GBの例では、安全のため6500MBが示されている
• 一定の量を超えると、メモリを増やしても性能は上がらない。32GBを借りても費用が無駄になりやすい、と書かれている

つまり、足りないなら増やす、足りているなら増やさない、という切り分けになる。プランのメモリ自体が小さいときは、割り当てを減らす方向ではなく、プランを上げる判断になる。必要なメモリの目安は Java版の記事 に事業者の数字をまとめた。

手順3：MOD・プラグインを切り分ける

メモリに問題がなければ、次はMOD（Paper ではプラグイン）を疑う。Paper の資料に書かれた方法は次のとおり。

1. ログのエラー（スタックトレース）にプラグインの名前があれば、多くの場合そのプラグインが原因で、まずそのプラグインの更新を確かめる
2. 見つからなければ、plugins フォルダの名前を別の名前（例：plugins-disabled）に変えて、全部を無効にして起動する。それで直れば、原因はプラグインにある
3. どれかを絞るときは、プラグインを2つの組に分ける（互いに頼り合うプラグインは同じ組に入れる）。片方の組を無効にして（ファイルの拡張子を .jar から .jar-disabled などに変える）起動し、直れば無効にした組、直らなければ動いている組に原因がある。原因のある組で同じことを繰り返す（二分探索）

また、Paper の資料は、組み込みの spark を性能問題の原因を調べるためのものとしている。/spark profiler start で始め、/spark profiler stop で止めて結果を見る。

公式の資料で確かめられたのは、Paper のプラグインの切り分けまで。Fabric や Forge のMODについて、重くなる原因の一覧や、MODごとの負荷を示した公式資料は、今回は確かめられなかった。MODを入れたサーバーでも、「全部外して軽くなるか、半分ずつ戻して絞る」という進め方は同じように使える。ただし、これは資料に書かれた手順ではなく、Paper の手順を応用した進め方である。

手順4：描画距離を下げる

メモリとMODに問題がなければ、距離の設定を見る。距離の設定は、サーバーがクライアントに送るチャンク（ワールドの区画）の範囲や、サーバーが動かす範囲を決める。Paper の server.properties の資料には、次の2つがある。

Paper の spigot.yml では、この2つを世界ごとに上書きできる。-1 か default にすると server.properties の値が使われる。

さらに細かく絞るなら、spigot.yml の entity-activation-range（プレイヤーからのブロック数で、この距離の外にいるエンティティの更新の頻度が下がる）がある。既定値は animals 32、monsters 32、raiders 64、misc 16、water 16、villagers 32、flying-monsters 32。mob-spawn-range の既定値は8（チャンク）。こうした値は、むやみに触らず、手順1の測定で原因が距離にあると分かってから、1つずつ変える。

統合版の専用サーバーでは、Microsoft Learn の server.properties の資料に、次の項目がある。

統合版の view-distance は、資料では「許可する描画距離の最大」と説明されている。Java版と数字の意味が違うので、同じ感覚で比べない。

どれだけ下げればよいかの目安は、今回確かめた資料にはない。少しずつ下げ、そのたびに /spark tps で測って比べる。view-distance を下げると遠くの景色の見え方が変わるので、一緒に遊ぶ人に伝えてから変える。

順番のまとめ

自分でできること・事業者に確かめること

自分でできること：

• spark を使って、サーバーが遅れているかを測る
• -Xmx の見直し、プラグインの切り分け、距離の設定の変更
• 変更を1つずつ行い、変えた内容と結果を記録する

事業者に確かめること：

• プランのメモリと CPU の数（事業者の公式ページで見る）
• 割り当てられるメモリと、管理画面から見える使用量の違い
• プランの変更の手順と、変更したときの料金

次にすること

1. /spark health を取り、サーバーが遅れているかと、メモリと GC の様子を見る
2. メモリが足りているなら、MOD・プラグインを外して軽くなるか試す
3. 原因が見つからなければ、view-distance などを段階的に下げて測り直す
4. 設定が決まらないときは、Java版のサーバーの立て方 でメモリとポートの基本を、統合版のサーバーの立て方 で統合版の設定を見直す