Blog · blog
最高のパフォーマンスMOD Minecraft サーバー
サーバー側のラグは、クライアント側のFPSとは別の問題です。PaperやPurpur、調整されたJVMフラグ、事前生成されたチャンク、そして適切な視野距離を設定することで、ほとんどのラグを解消できます.
サーバーのラグはクライアントのラグとは別物
クライアント側のガイドでは、FPS（フレーム/秒）について説明します。これは、あなたのGPUがフレームを描画する速度のことです。サーバーのパフォーマンスは全く別の指標で、TPS（ティック/秒）です。サーバーが1秒間にゲームループ全体を実行できる回数を示します。TPSが20を下回ると、どんなに高性能なPCを持つプレイヤーであっても、ゴムバンドのように戻ったり、攻撃が遅れたり、Mobが実際の位置から遅れて表示されるなど、接続されているすべてのプレイヤーがそれを感じます。この問題の解決は、接続のサーバー側に完全に依存します。
この区別が重要である理由は、この2つの問題が常に混同されるからです。ローカルで300 FPSを出せるプレイヤーでも、TPSが12のサーバーではラグを感じます。クライアント側の変更では、それは変わりません。特に、BedWarsやSkyWarsのアリーナが常にリセットされるような、活発なミニゲームロビーを運営している場合は、以下の改善策に時間を使うことが実際に効果を発揮します。
負荷に耐えられるサーバーソフトウェアを選ぼう
バニラMinecraftのサーバーソフトウェアや最適化されていないSpigotの設定では、ほとんどの処理を単一のスレッドで行います。PaperやPurpurのような派生版は、そのパイプラインの大部分を非同期処理とマルチスレッドで再構築し、バニラには存在しなかった多くのデフォルトの最適化を搭載しています。プラグインや設定に手を付ける前に、これほど大きな効果を得られるものは他にありません.
紙
標準的な現代の選択肢です。非同期チャンク読み込み、エンティティ追跡の最適化、そしてほとんどの管理者が完全に活用しないであろう paper.yml の豊富なチューニングオプション.
紫
紙フォークに、追加のパフォーマンスノブとゲームプレイのトグルが重ねられています。Paperのエコシステムから離れることなく、より多くのコントロールが欲しい場合に価値があります.
バニラとストックのスピゴット
機能はするものの、小規模で人口の少ないサーバー以外では、本来のパフォーマンスを引き出せていない.
JVMのフラグを調整せよ、単にサーバー設定だけではない
MinecraftサーバーはJava仮想マシン内で動作しており、JVMのデフォルトのガベージコレクション設定は、Minecraft特有のメモリパターンに合わせて調整されたものではありません。Aikarのフラグは、そのパターンに合わせてガベージコレクタを具体的に設定する、広く利用され、公開されているJVM起動フラグのセットであり、実際のプレイヤー負荷下でのGC関連のフリーズの頻度と長さを大幅に短縮します.
プレイヤーが世界を見る前に、事前に世界を生成する
サーバーがプレイヤーが未開拓のテリトリーを探索する際に、リアルタイムで新しいチャンクを生成することが、突然のTPS低下の最も一般的な原因の一つです。この生成作業は、サーバーが同じティックで試みている他のすべての作業と競合します。Chunkyのようなツールは、チャンクを事前に、制御されたスロットリングされた処理で生成するため、後から探索するプレイヤーは、そのスパイクを一切引き起こすことがありません。
ミニゲームネットワークの場合、通常静的で小さなアリーナマップ自体ではあまり重要ではありません。むしろ、プレイヤーが自由に歩き回れるオープンなハブやロビーワールドにおいて重要になります。
ビューディスタンスとシミュレーションディスタンスを調整する
これらの2つの設定は、サーバーが各プレイヤーの周囲にロードしシミュレートする必要がある世界の量を制御し、プレイヤー数やハードウェアに対して単に高すぎるデフォルトのまま放置されることが多い設定項目です。
| 設定 | 制御するもの | よくある間違い |
|---|---|---|
| ビューディスタンス | 各クライアントに送信されるチャンクの数 | プレイヤー数に対して高すぎるデフォルトのまま |
| シミュレーションディスタンス | モブ、ブロック、レッドストーンが実際にシミュレートされる距離 | ビューディスタンスと同じに設定するが、必要ない |
シミュレーション距離は、通常最初に削減すべきものです。プレイヤーは、チャンクのレンダリングほど遠くまでモブやレッドストーンのシミュレーションを行う必要はなく、これを下げることで、ゲームの感覚への影響は小さく抑えながら、実際のティック時間を大幅に改善できます。
推測する前にプロファイリング
原因を推測して時間を無駄にするのは避けましょう。sparkのようなプロファイラは、サーバーのティック時間がどこに費やされているかを正確に捉え、特定のプラグイン、ワールド生成、エンティティ処理、あるいは全く別の原因なのかを特定します。設定をランダムに調整して、効果を期待するよりもずっと効率的です.
ペーパーかパープルをインストールしてください
まず、バニラ版または標準のSpigotから移行してください。これにより、以下のすべての最適化が解除されます.
アイカーのフラグをあなたのスタートアップスクリプトに適用してください
ドキュメント化されたフラグセットをサーバーの起動コマンドにコピーし、再起動してください。これは一度限りの変更ですが、継続的な効果があります.
Chunky で世界を事前に構築しましょう
プレイヤーが後でライブチャンク生成をトリガーしないように、交通量が少ない時間帯に実行してください.
視野距離とシミュレーション距離を意図的に設定してください
実際のプレイヤー数とハードウェアに合わせて設定し、プラットフォームのデフォルト設定のままにしないでください.
実負荷下でのスパークプロファイル
ピーク時にレポートを記録し、それが実際に示しているものに対応するのではなく、推測するのをやめましょう.
サーバー側のパフォーマンスだけでは物語は終わりません
TPSを安定させることは、体験の半分に過ぎません。各プレイヤーは依然として自身のマシン上でその安定したサーバーをレンダリングしており、堅牢なサーバーは、レンダリング、メモリ、または互換性のないシェーダーパックでクライアントが窒息しているプレイヤーには何も貢献しません。BedWarsやSkyWarsネットワークを運営しており、上記の作業をすでに完了させている場合、プレイヤーにとってスムーズな体験のもう半分は、彼らの側で何が起こるかです。Terminusはまさにそのギャップを埋めるために構築されており、サーバー側の作業に合わせて調整されたクライアントパフォーマンスを実現します。
FAQ
いいえ。クライアント側のMODは、プレイヤー自身のマシンでの動作を変化させます。サーバーのラグはサーバーのティックループに存在し、ソフトウェア、フラグ、プラグイン、ワールド設定といったサーバー側の変更のみが影響を及ぼします.
サーバーソフトウェア。バニラ版や最適化されていないSpigotからPaperやPurpurに移行することで、多くのチューニングビルドが依存する非同期処理とマルチスレッド処理が可能になります.
ええ、特にMinecraftのガベージコレクターですが、バニラデフォルトでは実際の負荷下でうまく処理できないことが多いです。サーバーのサイズが小さければ根本的な解決にはなりませんが、十分なハードウェアであれば、GCに関連するフリーズをかなり軽減できます.
サーバーのTPSを/tpsのようなコマンドやsparkのようなプラグインを使って確認してください。TPSが20付近で安定しているのに、それでもカクつきを感じる場合は、問題はサーバーではなく、ご自身のクライアントか接続にある可能性が高いです.
Terminus を手に入れろ
Tuned client performance to match the server work you already did.