その重さ、課金しても直らないかもしれません

MODサーバーが重くなると「スペックを上げれば直るはず」と考えがちですが、 原因がクライアント側や通信にある場合、サーバーをいくら増強しても1ミリも改善しません。 逆にサーバー処理落ちが原因なら、クライアントの軽量化MODは無意味です。

お金と時間を無駄にしないために、この記事では 計測して原因を特定してから、無料でできる順に対処する流れで解説します。 スペック増強は最後の手段。ただし必要なケースの判断基準も正直に示します。

STEP1: どこが重いのかを切り分ける

症状を見れば、どこが重いかはほぼ絞り込めます。

症状 誰に起きるか 疑う場所
モブがワープする・作物や装置が遅い・時間の進みがおかしい 全員に同時に起きる サーバー処理(TPS低下)
壊したブロックが戻る・攻撃が当たらない・視点移動は滑らか 特定の人だけ、または回線が遠い人 通信ラグ(ping)
画面のコマ落ち(FPS低下)。シングルプレイでも重い 自分だけ クライアント描画
  • TPS = サーバーが1秒間に処理する回数。上限20で、下回ると世界全体がスローになります
  • MSPT = 1回の処理にかかったミリ秒。50ms以下なら健全(50ms×20回=1秒)

クライアント描画が原因なら、サーバー側の対処は不要です。 軽量化MOD(Sodium系。Forge 1.20.1ならEmbeddium等)の導入、描画距離の短縮、 影MODの設定緩和など各自のPC側で対処してください。 以降はサーバー処理(TPS低下)の解決に絞ります。

STEP2: sparkで計測する

sparkは無料のパフォーマンス計測MODです。 CurseForgeまたはModrinthからForge版(Fabric版もあり)を入手し、 サーバーの mods フォルダに入れて再起動するだけで使えます。

まず現状把握。OP権限でコンソールかチャットから実行します。

/spark tps

直近のTPSとMSPTが表示されます。TPSが常時20付近・MSPTが50ms以下なら、 サーバー処理は健全です(重さの原因は通信かクライアント側)。

TPSが落ちているなら、プロファイラで「何が時間を食っているか」を計測します。

/spark profiler start --timeout 300

5分間計測して自動停止し、結果ページのURLがチャットに出ます (手動なら /spark profiler stop。コマンド仕様の出典: spark公式ドキュメント)。

STEP3: 結果の見方 — 犯人は名指しで出る

結果ページでは、サーバーの処理内容が時間割合(%)のツリーで表示されます。 上から展開していき、割合の大きい枝の名前を見てください。

  • Entity 系が太い → モブ・アイテムの処理過多。特定MODのエンティティ名が出ていればそのMODが原因
  • BlockEntity / TileEntity 系が太い → ホッパー・機械類の設置しすぎ
  • 特定MODのパッケージ名(例: com.example.somemod.*)が太い → そのMODが直接の犯人
  • ServerChunkProvider 等のチャンク生成系が太い → 探索・地形生成MODの負荷

あわせて /spark health を実行すると、TPS・メモリ使用量・GC(メモリ掃除処理)の頻度が 一覧で出ます。GCが数秒おきに走っている場合はメモリ不足のサインです。

STEP4: 対処する(効果とコストの順)

1. 使っていないMODを抜く(無料・効果大)

プロファイラ上位に出たMODと、「入れたけど誰も使っていないMOD」を削減します。 ワールドをバックアップしてから数個ずつ抜き、/spark tps で再計測。 地形生成系・常時スキャン系(サーバー側マップMOD等)は特に負荷が大きい定番です。

2. エンティティを減らす(無料・効果大)

TPS低下の古典的な原因はエンティティの過密です。

  • 放置ファーム・トラップのモブ溜め込みを処理する(溜めすぎない設計に変更)
  • 床に散乱したドロップアイテムを回収・削除する
  • ホッパーの長い連結を減らす(コンテナ系MODや水流輸送で代替)
  • 村人の過密繁殖・額縁やアーマースタンドの大量設置を見直す

3. メモリ割当を見直す(無料・条件次第)

/spark health でGC連発・使用量の張り付きが見えたらメモリ不足です。 割当の目安と設定方法はMODサーバーのメモリ目安へ。 逆に余りすぎている場合も、割当を適正化するとGCの1回あたりの停止が短くなります。

4. Aikar’s flagsを設定する(無料・GCスパイク対策)

Aikar’s flagsは、GCによる定期的なカクつきを抑えるJava起動引数のセットで、 コミュニティの実質標準です(出典: PaperMC公式ドキュメント)。 Forgeなら user_jvm_args.txt に以下を貼り付けます(-Xms/-Xmxは自分の割当に変更)。

-Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch
-XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40
-XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20
-XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4
-XX:InitiatingHeapOccupancyPercent=15
-XX:G1MixedGCLiveThresholdPercent=90
-XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32
-XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1

万能薬ではなく「GC起因のスパイク」に効く設定です。 プロファイラでMOD処理が重い場合の根本解決にはなりません。

STEP5: 再計測 — それでも重いならスペック不足です

対処のたびに /spark tps で再計測し、効果を数字で確認してください。 そのうえで、次の条件に当てはまるならサーバー側の性能限界と判断できます。

  • 不要MOD削減・エンティティ対策の後も、少人数でMSPTが常時50msを超える
  • プロファイラの上位が特定MODではなく、処理全体が満遍なく重い
  • メモリを増やしたくても、物理メモリにもう余裕がない
  • CPU使用率で1コアだけが常に張り付いている(Minecraftは1コアの性能への依存が強いため、コア数より1コアの速さが効きます)

ここまで来たら、選択肢は2つです。

  1. MOD構成を身の丈に合わせて削る — 費用ゼロ。遊び方を変えられるならこれで十分
  2. サーバーの性能を上げる — 今のMOD構成のまま遊びたい場合の正攻法。自宅PCなら上位VPSへ、VPSなら上位プランへ

「どのくらいのスペックが必要か」は MODサーバーのメモリ目安と Pixelmonサーバーに必要なスペックを、 移行先の選び方はマイクラ向けVPS比較を参考にしてください。

対処後の /spark tps でTPSが20に張り付き、 ワープしていたモブが滑らかに歩き出せば解決です。 その快適さを24時間維持する構成づくりは、上の関連記事からどうぞ。

次に読む: