マインクラフトサーバーパフォーマンス最適化完全ガイド
2025年10月最新版 – プロダクション環境対応
最終更新: 2025年10月29日 | 対応バージョン: Minecraft 1.21.x(Java 21 LTS)
2025年時点の要点(運用者向け)
- Java 21 LTSが安定運用の第一選択。G1GCを基本に、ワークロードによりZGCも選択肢。
- Paper/Purpur系は最適化項目が豊富。Timingsは継続利用可能で、Sparkがプロファイリング用途として広く採用。
- Fabric/NeoForgeのモッディング環境は成熟(サーバー向け最適化MODの選択肢が増加)。
- 料金・プラン・最適値は変動しやすいため、数値は目安にとどめて運用環境で段階検証を推奨。
1. パフォーマンス最適化の基礎知識
TPS(Ticks Per Second)の理解
TPSは1秒あたりのサーバー処理ティック数。理想値は20。20を安定維持すると、モブ挙動・レッドストーン・成長・物理が設計どおりに動作します。
メモリ使用量とGCの基本
メモリ不足はGCスパイクやスワップを招き、TPS低下の主因になります。下表は初期割り当ての目安です(プラグイン・MOD・プレイヤー数に応じ現場調整)。
| サーバータイプ | 推奨RAM | プレイヤー数 | 備考 |
|---|---|---|---|
| バニラ/軽量Paper | 4–6GB | 〜20 | 軽量プラグイン程度 |
| MOD(Fabric/NeoForge) | 8–12GB | 〜30 | MOD数・重量に依存 |
| 大規模/多プラグイン | 16GB+ | 50+ | 分割構成・プロキシ検討 |
※OS/監視/バックアップ分のRAMも確保しましょう。
2025年主要サーバーソフトウェア概観
| ソフトウェア | 特徴 | パフォーマンス | 拡張 | 推奨用途 |
|---|---|---|---|---|
| PaperMC | Spigot互換・最適化豊富・運用実績多数 | ★★★★★ | Bukkit/Spigot/Paper API | 多くのプロダクション |
| Purpur | Paper拡張・追加チューニング項目 | ★★★★☆ | Paper互換+独自 | 細かく詰めたい運用 |
| Fabric Server | 軽量MOD基盤・最新性 | ★★★★☆ | Fabric MOD | 軽量MODサーバー |
| NeoForge Server | Forge系後継・2025年は安定運用事例増 | ★★★★☆ | NeoForge MOD | 次世代MODサーバー |
※いずれも最新ビルドで挙動が変わるため、更新ノートと互換性一覧を必ず確認。
2. ハードウェア・インフラ最適化
2025年推奨サーバー構成(目安)
CPU
- シングルスレッド性能重視(クロック 3.0GHz+ 目安)
- 例: Intel 13世代 i5 以上 / AMD Ryzen 7000 番台以上
- Paper/Purpurは内部並列化が進むが、単スレ性能は依然重要
メモリ
- DDR4-3200 以上(可能ならDDR5)
- 本体+OS+監視/バックアップ分で余剰を確保
- ECCは安定運用で有利、デュアルチャネル推奨
ストレージ
- NVMe SSDを推奨(SATAは非推奨)
- ワールド/ログ/バックアップの分離を検討
- RAID1/スナップショットで可用性を担保
VPS/クラウド選定の考え方
| サービス | 料金傾向 | スペック傾向 | 所感 |
|---|---|---|---|
| ConoHa for GAME | 中〜 | 2〜8GB/2〜8vCPU | 国内レイテンシ/テンプレ/時間課金 |
| XServer VPS | 中〜 | 2〜8GB/多vCPU | 安定・日本語サポート |
| AWS/Azure等 | 高 | 可変 | 企業要件/監査/マルチAZ等 |
料金は頻繁に変動します。 本表は傾向のみ。具体額は各公式で最新を確認してください。
Java 21 LTS 推奨起動プロファイル(安全構成)
まずはG1GCの安定プロファイルから。ZGCはワークロードにより有効ですが、ヒープ・OS・カーネル条件に左右されるため段階導入を推奨。
A. G1GC(汎用/安定)
# 8GBヒープ例(OS/監視分を残すこと)
java -Xms7G -Xmx7G \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 \
-XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC \
-XX:+AlwaysPreTouch \
-XX:G1HeapRegionSize=8m \
-jar paper-1.21.x.jar nogui
B. ZGC(短停止志向/検証導入)
# ZGCはカーネル/メモリ条件の影響大。検証環境でまず比較測定
java -Xms7G -Xmx7G \
-XX:+UseZGC \
-XX:+ZGenerational \
-XX:+UnlockExperimentalVMOptions \
-XX:+AlwaysPreTouch \
-jar paper-1.21.x.jar nogui
※過去の“万能フラグ”を鵜呑みにせず、自環境で計測→少しずつ調整するのが最善です。
3. サーバーソフトウェア最適化設定(Paper/Purpur基準)
server.properties / paper-global.yml の要点
server.properties(抜粋・安全値)
# server.properties(Vanilla/Paper共通の代表項目)
view-distance=10
simulation-distance=8
sync-chunk-writes=true
max-tick-time=60000
enable-status=true
enable-query=false
online-mode=true
motd=§6§lOptimized Server §r§7- 1.21.x
※「max-packet-size」「use-native-transport」等、存在しない/実装が異なるキーは設定しないでください。
paper-global.yml(代表項目/名称はビルドで変動)
# paper-global.yml(例:スレッド数はコア数と観測値で)
chunk-system:
io-threads: 8 # 物理コアに応じて 4〜8 程度から検証
worker-threads: 8
timings:
enabled: true # Timingsは依然有用
verbose: false
packet-limiter:
limits:
all:
interval: 7.0
max-packet-rate: 500.0
※ファイル形式・キー名はビルドで微差あり。コメントをよく読むこと。
spigot.yml / bukkit.yml の調整(無理のない範囲)
# spigot.yml(world-settings.default 抜粋)
world-settings:
default:
entity-activation-range:
animals: 16
monsters: 24
raiders: 32
misc: 8
water: 12
villagers: 16
flying-monsters: 32
entity-tracking-range:
players: 48
animals: 48
monsters: 48
misc: 32
other: 64
max-entity-collisions: 2
merge-radius:
item: 4.0
exp: 6.0
hopper-transfer: 8
hopper-check: 1
hopper-amount: 1
# bukkit.yml(無理のないスパン調整)
spawn-limits:
monsters: 50
animals: 10
water-animals: 7
water-ambient: 10
ambient: 1
chunk-gc:
period-in-ticks: 600
load-threshold: 300
ticks-per:
animal-spawns: 400
monster-spawns: 1
water-spawns: 1
water-ambient-spawns: 1
ambient-spawns: 1
autosave: 6000
※キー名の誤記「bukkiy.yml」を修正し「bukkit.yml」へ。値はサーバー用途に合わせて段階調整。
4. プラグイン・MOD最適化
Spark(プロファイラ)の実用ポイント
2025年時点で、Timingsは引き続き有用で、SparkはCPU/メモリ・イベント/タスクの詳細分析に広く使われています(“公式採用”という表現ではなく、実運用での標準ツールとして定着)。
# Spark 基本コマンド
/spark profiler start
/spark profiler stop
/spark profiler upload
# サンプリング例
/spark profiler start --timeout 300 --interval 4
# メモリ
/spark heap summary
/spark heap dump
使い分けの指針
- Timings: 軽量な常用計測
- Spark: 詳細なボトルネック分析(重い処理を掴む)
- 結果をもとに設定→計測→調整の反復が最短ルート
注意: “万能プラグイン”は存在しません。LagAssist/MobLimiter系は環境と方針に合わせて導入を検討し、入れすぎないことが最大の最適化です。
Fabric/NeoForge 最適化MODの定番
軽量MOD環境の代表例(構成は互換性を必ず確認)。
- Lithium:ゲームロジック最適化
- Sodium(クライアント):描画高速化
- Starlight:ライト計算の大幅最適化(代替: Phosphor)
- FerriteCore:メモリ効率改善
NeoForge環境でも最適化系MODの選択肢が増加。配布元の記載に従い、版とロード順を厳守。
推奨プラグイン(Paper/Purpur)
ProtocolLib:パケットまわりの基盤。多くの最適化プラグインの前提に。
ViewDistanceTweaks:プレイヤー数等に応じた動的描画距離調整。
Chunky/ChunkMaster:事前チャンク生成で探索ラグを軽減。
FarmControl/MobFarmManager:過密農場やモブ滞留を抑制。
導入順序: 「Sparkで可視化 → 必要箇所に限定導入 → 再計測」。入れ替え時はバックアップを必ず取得。
5. 監視・分析システム構築
Grafana 連携とメトリクス設計
Prometheus ExporterやSparkのデータをGrafanaで可視化。TPS/メモリ/チャンク/エンティティ/ディスクIO/帯域を“赤・黄・青”で閾値管理。
ベースライン運用: 週次で同条件のプロファイルを取得し、過去と比較。異常検知の“基準”を持つと復旧が早くなります。
Discord 通知(Webhook)簡易実装(非同期版)
# discord_webhook_monitor.py(aiohttp + discord.py不要の純Webhook例)
import asyncio
import aiohttp
import datetime
WEBHOOK_URL = "YOUR_DISCORD_WEBHOOK"
async def send_alert(title: str, desc: str, color: int = 0xFF9900):
payload = {
"embeds": [{
"title": title,
"description": desc,
"color": color,
"timestamp": datetime.datetime.utcnow().isoformat()
}]
}
async with aiohttp.ClientSession() as session:
async with session.post(WEBHOOK_URL, json=payload, timeout=10) as resp:
await resp.text()
async def main():
# 例: TPSが18未満なら通知
tps = 17.8
if tps < 18:
await send_alert("TPS低下警告", f"現在のTPS: {tps}")
if __name__ == "__main__":
asyncio.run(main())
※discord.pyのWebhook送信と混用しないシンプルな実装例。実運用は例外再試行やバッチ化を追加。
6. エンティティ・チャンク最適化
エンティティ最適化戦略
重くなりやすい要素
- 地面に溜まるアイテム/経験値オーブ
- 大量の動物/村人/トロッコ/ボート
- 巨大・複雑なレッドストーン装置(高周波クロック)
対処
- 自動回収・定期クリア(プラグイン/コマンド)
- Mob数上限/繁殖制限の導入
- クロック周波数の低減・スイッチ式化
- 農場/拠点の分散配置
# 定期メンテ例(慎重に適用)
# 古いアイテムを削除(Ageは実データに合わせて)
execute as @e[type=item,nbt={Age:6000s}] run kill @s
# 付近の経験値オーブを削除
kill @e[type=experience_orb,distance=..80]
チャンク管理最適化
| 設定項目 | 推奨開始値 | 効果 |
|---|---|---|
| view-distance | 8–10 | 描画負荷/帯域の抑制 |
| simulation-distance | 6–8 | 処理負荷の抑制 |
| autosave(ticks) | 6000 | 保存負荷分散 |
| max-auto-save-chunks | 24 付近 | 保存時のスパイク低減 |
1.21.x で増えた要素への向き合い方
試練系構造物
- スポナー/ギミック部の負荷把握
- 探索・戦闘の同時実行を避け、混雑時間帯を分散
新モブ
- パーティクル・飛翔体の負荷に注意
- スポーン頻度設定の見直し(MOD/プラグイン)
自動化ブロック
- 大量設置時のホッパー・I/O最適化
- 回路の共通化・クロック削減
7. バックアップ・データベース最適化
rclone での自動バックアップ(クラウド連携)
停止/フラッシュ→圧縮→アップロード→整合性チェック→再開の順で安全に。Discord通知を組み合わせると運用が楽になります。
#!/bin/bash
# minecraft-backup.sh(運用例:必要に応じてsudo/screen部分を調整)
WORLD_PATH="/opt/minecraft/world"
PLUGINS_PATH="/opt/minecraft/plugins"
BACKUP_DIR="/tmp/mc-backup-$"
RCLONE_REMOTE="gdrive:minecraft-backups"
WEBHOOK="YOUR_DISCORD_WEBHOOK"
set -e
mkdir -p "$BACKUP_DIR"
# 通知関数
notify() { curl -H "Content-Type: application/json" -X POST -d "{\"content\":\"$1\"}" "$WEBHOOK" >/dev/null 2>&1 || true; }
notify "バックアップ開始"
screen -S minecraft -p 0 -X stuff "save-off^M"
screen -S minecraft -p 0 -X stuff "save-all flush^M"
sleep 10
tar --exclude='session.lock' -czf "$BACKUP_DIR/world.tar.gz" -C "$WORLD_PATH" .
tar -czf "$BACKUP_DIR/plugins.tar.gz" -C "$PLUGINS_PATH" .
cp server.properties spigot.yml paper-global.yml bukkit.yml "$BACKUP_DIR/" || true
rclone copy "$BACKUP_DIR/" "$RCLONE_REMOTE/" --progress
rclone check "$BACKUP_DIR/" "$RCLONE_REMOTE/" || { notify "バックアップ整合性NG"; exit 1; }
screen -S minecraft -p 0 -X stuff "save-on^M"
rm -rf "$BACKUP_DIR"
notify "バックアップ完了"
クラウド候補
- Google Drive / OneDrive / Dropbox
- Amazon S3 / Backblaze B2
- NAS(S3互換)との併用
ベストプラクティス
- 3-2-1(3コピー/2媒体/1遠隔)
- 差分/世代管理・暗号化・定期復元テスト
- 作業前に必ずバックアップ
MySQL/MariaDB の基本チューニング(プラグイン用)
# /etc/my.cnf(MariaDB 10.6+ 例:現場で段階調整が前提)
[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1
max_connections = 200
thread_cache_size = 64
table_open_cache = 2000
table_definition_cache = 1000
tmp_table_size = 128M
max_heap_table_size = 128M
slow_query_log = 1
long_query_time = 2
# 旧式のQuery Cacheは無効/検討(ワークロード次第)
LuckPerms/CoreProtect等を使う場合、インデックスや古いデータの整理も効果的。
8. ネットワーク・セキュリティ最適化
ネットワーク基本設定(安全な範囲)
# server.properties(ネットワーク周りの代表項目)
network-compression-threshold=256
player-idle-timeout=0
# 以下はサーバー/OS側(iptables等)で対処
# - 同時接続のスロットリング/Rate Limiting
# - 帯域制御/優先度
Linuxカーネルのネットワークチューニング(rmem/wmem等)はOS全体へ影響するため、変更前に計測・記録し、段階適用が原則。
DDoS対策・セキュリティ
- ホスト/プロバイダのDDoS緩和機能を活用
- Fail2Ban等でブルートフォース対策
- プロキシ/プロトコル偽装対策(Velocity+BungeeGuard等)
- 監査ログ・権限設計(最小権限原則)
# fail2ban jail.local(ログパスは環境に合わせる)
[minecraft-brute]
enabled = true
filter = minecraft-brute
logpath = /opt/minecraft/logs/latest.log
maxretry = 3
bantime = 3600
findtime = 600
action = iptables-multiport[name=minecraft, port="25565", protocol=tcp]
9. トラブルシューティング
一般的なパフォーマンス問題と対処
🚨 TPS低下(15未満)
原因特定
- Timings/Sparkで重い処理を特定
- エンティティ数/チャンク読み込みの偏り
- プラグイン/ MOD の負荷を個別比較
即時対処
- view/simulation-distanceの一時縮小
- 滞留アイテム/経験値のクリア
- 問題プラグインの一時停止
メモリリーク/GCスパイク
検出
# ヒープダンプ例(Java付属ツール)
jcmd GC.heap_info
jmap -dump:format=b,file=heap.hprof
対処
- リーク疑いプラグインの更新・隔離
- ZGCの検証導入(計測必須)
- 計画的な再起動スケジュール
🔧 プラグイン競合
重複機能/古いAPI/ロード順で不具合が起こりがち。
# 例:ログからエラーを抽出
grep -i "error\|exception" logs/latest.log | tail -n 200
# 順次無効化テスト(再起動前提)
mv plugins/対象.jar plugins/_disabled/
10. 2025年の運用トレンド
AI・自動化の活用
AIによる最適化提案/予防保守は一般化。導入時は“自動変更の監査ログ”と“ロールバック”を用意し、暴走を防ぐこと。
コンテナ運用(Docker/Compose/K8s)
# docker-compose.yml(最小構成例:値は環境で調整)
version: '3.8'
services:
minecraft:
image: eclipse-temurin:21-jre
container_name: minecraft-server
restart: unless-stopped
ports: ["25565:25565"]
volumes:
- ./server:/opt/minecraft
environment:
- JAVA_OPTS=-Xmx8G -Xms8G -XX:+UseG1GC
working_dir: /opt/minecraft
command: sh -c "java ${JAVA_OPTS} -jar paper-1.21.x.jar nogui"
※K8sのHPA/PodDisruptionBudgetで計画メンテ無停止、PVCスナップショットで高速復旧などが有効。
↑ 安定
TPS維持
監視→漸進調整で安定化
↓ スパイク
GC停止時間
G1→ZGC検証で短縮余地
↑ 効率
運用自動化
通知/バックアップの自動化が定着
まとめ:プロフェッショナルな運用へ
サーバー最適化は「計測→調整→検証」の反復が最短ルート。最新技術を鵜呑みにせず、
あなたの環境でのデータを基準に、小さく確実に積み上げましょう。
成功のポイント
- 継続的監視: Timings/Spark+Grafana
- 自動化: バックアップと通知の定着
- 段階適用: 1回1変更で差分検証
- セキュリティ: DDoS/権限/監査ログ
- 可観測性: ログ・メトリクス・トレース
避けるべき落とし穴
- 過度な“魔法のフラグ”信仰
- プラグイン過多/重複
- バックアップ・復元テストの欠落
- 闇雲な同時変更
- 監視なしの本番投入
2025年運用ロードマップ(例)
Phase 1
Paper/Purpur+Java 21
Phase 2
監視基盤(Spark/Grafana)
Phase 3
自動化(通知/バックアップ)
Phase 4
K8s/プロキシ分割
重要な注意事項
本記事の設定値はあくまで開始点です。各サーバーの目的・人数・地形・MOD/プラグインによって最適値は変わります。
変更は段階的に行い、計測結果に基づき調整してください。変更前には必ずバックアップを取得しましょう。

