1 台の性能と設定

対象は Java 版の Paper (PaperMC) のサーバーです。設定の名前と既定の値は、2026 年 10 月時点の PaperMC のドキュメントと Minecraft Wiki によります。お使いのバージョンでは異なる場合があるため、変更の前に公式のドキュメントで確認してください。

CPU

ワールドの計算は主に 1 つのスレッドで動くため、コアの数よりも、1 コアあたりの性能 (クロックの高さと世代の新しさ) を優先します。コアの数の多いサーバー向けの CPU は、1 コアあたりのクロックが低いことが多く、Minecraft では不利になる場合があります。

一方で、通信、チャンクの生成と読み書き、Java のメモリの回収 (GC) は別のスレッドで動くため、コアが少なすぎても困ります。PaperMC のドキュメントは、少なくとも 4 スレッドを割り当てることを勧めています。

クラウドの仮想サーバーでは、ほかの利用者と CPU を共有する種類 (バースト型など) を避け、性能が保証される種類を選びます。CPU の性能が一時的に制限されると、ティックの時間が急に延びます。

メモリと JVM の設定

PaperMC のドキュメントは、6〜10 GB 以上のメモリを割り当てることを勧めています。ただし、ある程度を超えると、メモリを増やしても性能は上がりません。サーバーのメモリをすべて割り当てず、OS のために 1〜1.5 GB ほど残します。

起動のときの値 (-Xms) と最大の値 (-Xmx) は、同じ値にする
Paper では、G1 のガベージコレクションに合わせた起動の設定 (Aikar's flags) が推奨されている。全体は PaperMC の Script Generator で作れる
Java のバージョンは、Minecraft のバージョンに合わせる。26.1 からは Java 25 が必要

java -Xms10G -Xmx10G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
  -XX:G1HeapRegionSize=8M … -jar paper.jar --nogui

上の例は一部を省略しています。Web の記事にある起動の設定には、OS によって使えないオプションが含まれていることがあるため、公式の Script Generator で作ったものを使います。

メモリの使用量が多く見えるのは、Java の仕組みとして通常のことです。メモリ不足で落ちる場合は、OS に残すメモリが少ないか、コンテナのメモリの上限が -Xmx に近すぎることが多いです。

描画距離と演算距離

server.properties の 2 つの設定で、プレイヤーのまわりのどこまでを扱うかを決めます。どちらもチャンク (16 × 16 ブロック) の数で指定し、既定は 10、範囲は 3〜32 です。

設定	決めること	大人数のときの考え方
`view-distance`	描画距離。参加する方に送るワールドの範囲	見える範囲を保ちたい場合は大きく、負荷と通信の量を下げたい場合は小さくする
`simulation-distance`	演算距離。モブ、作物、レッドストーン回路などを計算する範囲。範囲の外は計算しない	ティックの計算の量に直接効く。人数が多いときは、先にこちらを小さくする

参加する方の描画距離の設定を大きくしても、サーバーの view-distance より遠くは送られません。見え方と通信の量の関係は、通信の帯域とクライアントの快適さで説明しています。

ワールドの事前生成

まだ誰も行っていない場所に入ると、サーバーはその場でチャンクを生成します。生成は重い処理で、大勢が新しい場所に散らばると、サーバー全体が重くなります。

企画の前に、使う範囲のチャンクを、Chunky などのプラグインで生成しておく
ワールドボーダーで、生成される範囲を限る
生成したワールドは、本番の前にバックアップしておく

Folia の README も、チャンクの処理に使うスレッドを減らせるため、ワールドの事前生成を勧めています。

モブとレッドストーン回路

モブ、ドロップしたアイテム、ホッパーなどのブロックエンティティ、大きなレッドストーン回路は、ティックの計算の量を大きく増やします。大人数の企画では、内容に合わせて、次のような決まりを事前に決めておきます。

モブの数の上限と、スポーンの範囲 (Paper の設定や、server.properties の simulation-distance)
動物を集める施設、モブのトラップ、ホッパーを大量に使う仕組みの規模
常に動き続けるレッドストーン回路 (クロック回路) の扱い
ドロップしたアイテムが残る時間

どこが重いかは、プレイヤーの行動で変わります。決まりを作る前に、次の計測で原因を確かめます。

計測にもとづいて改善する

性能の改善は、計測から始めます。サーバーが重いと感じると、原因の見当を付けて設定を変えたくなります。しかし、見当が外れていれば、効果のない変更を重ねるだけでなく、別の不具合を生み、元の原因を見えにくくします。重さの原因は、プレイヤーの行動、ワールドの状態、プラグインの組み合わせで変わるため、経験や一般論だけでは特定できません。

KEY SELECT は、Minecraft に限らず、Web のシステム、データベース、ネットワーク、クラウドのどの技術でも、憶測ではなく計測にもとづいて判断します。進め方は次のとおりです。

基準を測る: 変更の前に、TPS、MSPT、CPU、メモリなどを、同じ条件で記録する
原因を特定する: プロファイラーで、どの処理に時間がかかっているかを数字で確かめる
1 つずつ変える: 変更は 1 度に 1 つにし、何が効いたかを分かるようにする
同じ条件で測り直す: 変更の前後を同じ人数と内容で比べ、効果を数字で確かめる
記録する: 測った値、変えた内容、結果を残し、次の判断と、障害のときの調査に使う

Paper には、計測のためのプラグイン spark が組み込まれています。

# TPS と MSPT を確認する
/spark tps

# 300 秒間、メインのスレッドの処理を記録して、結果の URL を表示する
/spark profiler start --timeout 300

# 100 ミリ秒を超えたティックだけを記録して、時々起きる重さの原因を探す
/spark profiler start --only-ticks-over 100 --timeout 300

# ティックの時間の分布を確認する(1.20.3 以降)
/tick query

結果では、ワールドの計算を担う「Server thread」を見ます。どのディメンション、どのエンティティ、どのプラグインに時間がかかっているかが分かります。平均の MSPT が低くても、最大の MSPT や P99 が高い場合は、時々起きる重さがあります。

本番の前には、参加する人数に近い状態で試します。少人数での確認では、人数が増えたときの重さは分かりません。

参考にした資料

サーバーの設定の見直しは、KEY SELECT に

サーバーの機材とクラウドの選定、JVM と Paper の設定、ワールドの事前生成、企画の前の負荷の確認まで、KEY SELECT がお引き受けできます。

サーバーの設定のご相談 Minecraft サーバー運営

記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。