TPS低下に悩んでいませんか?
サーバーを運営していると、「なんか最近ラグいな」とか「TPSが落ちている気がする」と感じることは珍しくありません。
ただ、その原因が何なのかは意外と分かりにくいものです。プラグインなのか、エンティティなのか、それとも別の要因なのか。はっきりしないまま調整しても、思ったように改善しないことも多いはずです。
そこで今回は、パフォーマンス分析ツール「Spark」を使って、TPS低下の原因をしっかり特定する方法を解説します。初めて使う方でも流れが分かるように、導入から見方まで順番に説明していきます。
Sparkとは?TPS改善に欠かせないツール
Sparkは、Minecraftサーバーの内部処理を可視化できるプロファイラーです。サーバーの中でどの処理に負荷がかかっているのかを、数値やグラフとして確認できます。
体感で「重い」と感じるだけでは分からない部分も、Sparkを使えばはっきりと見えてきます。どの処理がどれくらいの時間を使っているのかが分かるので、TPS低下の原因を正確に絞り込めるのが大きな強みです。
主な特徴
- リアルタイムでパフォーマンスを計測
- CPU使用率や処理時間を可視化
- プラグインや処理ごとの負荷を分析可能
- Webブラウザで見やすいレポート表示
Sparkの導入方法
導入はそれほど難しくありません。プラグインまたはMODとして簡単に導入できます。Sparkをダウンロードして、サーバーのpluginsまたはmodsフォルダに入れたあと、サーバーを再起動するだけです。再起動後に「/spark」と入力してコマンドが反応すれば、問題なく導入できています。
手順
- Sparkの公式サイトからファイルをダウンロード
- サーバーの「plugins」または「mods」フォルダに配置
- サーバーを再起動
- /spark コマンドが使えることを確認
これで準備は完了です。
再起動後に /spark コマンドが使えるようになっていれば、正しく導入されています。
基本的な使い方
まずはプロファイラー機能を使って、サーバーの状態を記録してみましょう。
プロファイリングの開始と停止
/spark profiler start
この状態でしばらくサーバーを動かし、普段どおりの負荷をかけます。そのあと、次のコマンドで記録を停止します。
/spark profiler stop
実行するとURLが表示されるので、それをブラウザで開くと分析結果を見ることができます。
また、リアルタイムで状況を確認したい場合は、次のコマンドが便利です。
時間の経過とともに変化する負荷を、その場で確認できます。
/spark profiler open
プロファイラーの見方!まずはここを見る
分析画面を開いたら、最初はすべてを理解しようとしなくて大丈夫です。まず注目したいのはTPSとMSPTです。
TPSは1秒あたりのTick数で、20が理想の状態です。これが下がっていると、サーバーに遅延が発生しています。
MSPTは1Tickあたりの処理時間を表していて、50ミリ秒以下に収まっていれば正常です。
この2つを見るだけでも、「今サーバーが重い状態なのかどうか」は判断できます。
次にグラフを見て、TPSが落ちているタイミングを確認します。そのタイミングでCPU使用率やエンティティ数がどうなっているかを見ると、原因の方向性が少し見えてきます。
1. トグルスイッチ
左から、
- 「ウィジェットの表示/非表示」の切り替え(2.青の部分)
- 「詳細メタデータの表示/非表示」の切り替え(2.青の部分、3オレンジの部分)
- 「グラフの表示/非表示」の切り替え(4.緑の部分)
- 「設定メニューの表示/非表示」の切り替え
- 「ビュー切り替え」all/flat/mods
- 「フレームビュー切り替え」
おすすめは画像の通り、 左から、ON ON ON OFF ALL です!この記事では、この設定を前提に説明します。
2.ウィジェット&メタデータ
各数値には意味があります。
- TPS:Time Per Second ティック毎秒のことです。20が最大で、遅延が生じると19以下の数値になります。
- MSPT:Milli Second Per Tick ミリ秒毎Tickのことです。1ティックは1/20秒なので、MSPT50以下が正常値です。
- CPU(process):MinecraftサーバープロセスのCPU使用率です。
- CPU(system):サーバー機全体のCPU使用率です。
- Memory(physical):サーバー機全体の物理メモリの使用率です。使用量/全体量、それと使用率です。
- Memory(swap):サーバー機全体のスワップメモリ使用率です。使用量/全体量、それと使用率です。
- Disk:ディスク使用率です。使用量/全体量、それと使用率です。
- Ping:通信レイテンシーです。低ければ低いほど良い。
- GC(G1 Young, during):Javaガベージコレクションの回数(ヒープのYoung世代のGC)
- GC(G1 Concurrent GC, during):Javaガベージコレクションの回数(ヒープの混合GC)
- GC(G1 Old, during):Javaガベージコレクションの回数(ヒープのOld世代のGC)
- GC(G1 Young, all):Javaガベージコレクションの回数
- GC(G1 Concurrent GC, all):Javaガベージコレクションの回数
- GC(G1 Old, all):Javaガベージコレクションの回数。これが発生するのは、異常。
4. グラフ
グラフ領域です。下のボタンで、グラフ化する数値を選択できます。
TPSとMSPTやエンティティ数の相関を確認できるため、とても便利です。
5.プロファイルビュー
ここでは、サーバーで実行されている各処理が全体のCPU計算でどれくらいの時間、実行されているか確認できます。
つまり、何が重いか判断することが出来ます。
Sparkで最も重要なのが、プロファイルビューです。ここでは、サーバー内で動いている処理が、どれくらいの割合でCPU時間を使っているのかが表示されます。
見方はシンプルで、上から順に割合の大きいものを追っていくだけです。
まず、一番上に注目します。
Server thread 100.0%
ここに記載されている割合(%)はサーバー処理のうち何%を占めているかが表現されています。
サーバースレッドはすべての処理の原点にいるため100%と表示されています。
クリックして深掘りすることができます。
何が重いの調査する方法
サーバースレッドから辿り、割合%の大きい行を展開していきましょう。
net.minecraft.server.MinecraftServer.runServer()99.50%
net.minecraft.server.MinecraftServer.tickServer()55.55%
net.minecraft.server.MinecraftServer.waitUntilNextTick()43.94%
このような表示が見つかるはずです。
runServer()99.50%なので、ほぼすべての処理はここの下で行われていることがわかります。
さらに内訳を見ると、tickServer()55.55%とwaitUntilNextTick()43.94%がほぼ全てを占めています。
では、tickServer()55.55%は何をしているのでしょうか?深掘りして行きましょう。
さらに展開してみると、ServerLevel.tick()53.26%が大部分を占めていることがわかります。
マインクラフトサーバーは1秒間に20回の同期処理を行います。例えばエンティティの行動であったり、ホッパーの移動処理であったりと、様々な処理がこの1ティックの中で実行されます。TPSが20なこともこれが理由です。
さらに深掘りして行きましょう。
内訳の中で、多くの割合を占めているのは、この2つです。
net.minecraft.server.level.ServerChunkCache.tick()26.52%
net.minecraft.world.level.entity.EntityTickList.forEach()21.50%
ServerChunkCache.tick()とは、サーバーがチャンクを読み込んだりアンロードしたり、スポナーを操作したりする処理です。
この場合、サーバの処理の26%近くは、チャンクの管理に使われていることがわかります。
一方、EntityTickList.forEach()とは、エンティティ処理のループです。つまり、ワールドにいる様々なエンティティを動かすために各エンティティのtick()処理を実行しています。こちらはさらに深ぼっていくと、どのエンティティ?というところまで特定可能です。
今回の結果では、Villager(村人)の処理が最も多く 5.62%、続いてZombie(ゾンビ)が3.30%でした。
ここまでくると、かなり明確になったかと思います!
このように、プロファイラーは具体的にどのような処理でシステムに負荷をかけているか一目瞭然にします。
原因が分かったあとの考え方
ここまで分かれば、あとは対処はそれほど難しくありません。大切なのは、「何が重いのか」に合わせて対策を変えることです。
エンティティが原因であれば数を減らす必要がありますし、チャンク処理が重いのであれば読み込み範囲を見直す必要があります。プラグインが原因であれば、その設定や構成を見直すことになります。
やみくもに設定を変えるのではなく、原因に対してピンポイントで手を打てるのがSparkの良いところです。
まとめ
TPS低下は、なんとなくの感覚で対処してもなかなか改善しません。だからこそ、まずは「何が原因なのか」を正しく知ることが重要です。
Sparkを使えば、サーバーの内部で起きていることを具体的に把握できます。最初は少し難しく感じるかもしれませんが、一度流れを理解すれば、かなり強力なツールになります。
サーバーのパフォーマンスに悩んでいる方は、ぜひ一度Sparkを使って分析してみてください。きっと改善のヒントが見つかるはずです。