Chapter 9.8: パフォーマンスチューニング

ホーム | << 前へ: パーシステンス | 次へ: アクセス制御 >>

概要: DayZにおけるサーバーパフォーマンスは3つの要因に集約されます: アイテム数、ダイナミックイベント、MOD/プレイヤー負荷。この章では、重要な設定、問題の診断方法、実際に効果のあるハードウェアについて解説します -- すべてFPSドロップ、ラグ、デシンクに関する400件以上のDiscordレポートからの実際のコミュニティデータに基づいています。

サーバーパフォーマンスに影響する要因
globals.xmlのチューニング
パフォーマンスのためのエコノミーチューニング
cfgeconomycore.xmlのログ
serverDZ.cfgのパフォーマンス設定
MODのパフォーマンス影響
ハードウェア推奨事項
サーバーヘルスの監視
よくあるパフォーマンスの間違い

サーバーパフォーマンスに影響する要因

コミュニティデータ（FPS/パフォーマンス/ラグ/デシンクに関する400件以上のDiscord投稿）から、パフォーマンスに最も大きく影響する3つの要因は以下の通りです:

アイテム数 -- types.xml の高い nominal 値は、Central Economyがサイクルごとにより多くのオブジェクトを追跡・処理することを意味します。これは一貫してサーバーサイドラグの最大の原因です。
イベントスポーン -- events.xml でアクティブなダイナミックイベント（車両、動物、ヘリクラッシュ）が多すぎると、スポーン/クリーンアップサイクルとエンティティスロットを消費します。
プレイヤー数 + MOD数 -- 接続された各プレイヤーはエンティティの更新を生成し、各MODはエンジンが毎ティックコンパイルおよび実行する必要があるスクリプトクラスを追加します。

サーバーゲームループは固定30 FPSティックレートで動作します。サーバーが30 FPSを維持できない場合、プレイヤーはデシンクを経験します -- ラバーバンディング、アイテムピックアップの遅延、ヒット登録の失敗。15サーバーFPS以下では、ゲームはプレイ不能になります。

globals.xmlのチューニング

パフォーマンスに直接影響するパラメータのバニラデフォルト値です:

xml

<var name="ZombieMaxCount" type="0" value="1000"/>
<var name="AnimalMaxCount" type="0" value="200"/>
<var name="ZoneSpawnDist" type="0" value="300"/>
<var name="SpawnInitial" type="0" value="1200"/>
<var name="CleanupLifetimeDefault" type="0" value="45"/>

各値の制御内容

パラメータ	デフォルト	パフォーマンスへの影響
`ZombieMaxCount`	1000	サーバー上の感染者の総数上限です。各ゾンビはAIパスファインディングを実行します。500-700に下げると、人口の多いサーバーでサーバーFPSが顕著に改善されます。
`AnimalMaxCount`	200	動物の上限です。動物はゾンビよりシンプルなAIを持ちますが、ティック時間を消費します。FPSの問題がある場合は100に下げてください。
`ZoneSpawnDist`	300	プレイヤー周辺でゾンビゾーンがアクティブになる距離（メートル）です。200に下げると、同時にアクティブなゾーンが減ります。
`SpawnInitial`	1200	初回起動時にCEがスポーンするアイテム数です。値が高いほど初期ロードが長くなります。定常状態のパフォーマンスには影響しません。
`CleanupLifetimeDefault`	45	特定のライフタイムがないアイテムのデフォルトクリーンアップ時間（秒）です。値が低いほどクリーンアップサイクルが速くなりますが、CE処理がより頻繁になります。

推奨パフォーマンスプロファイル（40人以上のプレイヤーで苦戦しているサーバー向け）:

xml

<var name="ZombieMaxCount" type="0" value="700"/>
<var name="AnimalMaxCount" type="0" value="100"/>
<var name="ZoneSpawnDist" type="0" value="200"/>

パフォーマンスのためのエコノミーチューニング

Central Economyは、すべてのアイテムタイプを nominal/min ターゲットと照合する連続ループを実行します。より多くのアイテムタイプでより高いnominalは、サイクルごとの作業量が増えることを意味します。

Nominal値の削減

types.xml で nominal > 0 のすべてのアイテムはCEによって追跡されます。平均nominal 20で2000のアイテムタイプがある場合、CEは40,000のオブジェクトを管理しています。この数を削減するためにnominalを全体的に下げてください:

一般的な民間アイテム: 15-40から10-25に下げる
武器: 低く保つ（バニラではすでに2-10）
衣服のバリアント: 不要なカラーバリアントの無効化を検討する（nominal=0）

ダイナミックイベントの削減

events.xml では、各アクティブイベントがエンティティグループをスポーンおよび監視します。車両および動物イベントの nominal を下げるか、不要なイベントに <active>0</active> を設定してください。

アイドルモードの使用

プレイヤーが接続されていない場合、CEを完全に一時停止できます:

xml

<var name="IdleModeCountdown" type="0" value="60"/>
<var name="IdleModeStartup" type="0" value="1"/>

IdleModeCountdown=60 は、最後のプレイヤーが切断してから60秒後にサーバーがアイドルモードに入ることを意味します。IdleModeStartup=1 は、サーバーがアイドルモードで起動し、最初のプレイヤーが接続した時にのみCEをアクティブにすることを意味します。これにより、サーバーが空の状態でスポーンサイクルを回すのを防ぎます。

リスポーンレートのチューニング

xml

<var name="RespawnLimit" type="0" value="20"/>
<var name="RespawnTypes" type="0" value="12"/>
<var name="RespawnAttempt" type="0" value="2"/>

これらはサイクルごとにCEが処理するアイテム数とアイテムタイプ数を制御します。値を下げるとティックごとのCE負荷が減りますが、ルートリスポーンが遅くなります。上記のバニラデフォルトはすでに控えめです。

cfgeconomycore.xmlのログ

CE診断ログを一時的に有効にして、サイクル時間を測定しボトルネックを特定します。cfgeconomycore.xml で:

xml

<default name="log_ce_loop" value="false"/>
<default name="log_ce_dynamicevent" value="false"/>
<default name="log_ce_vehicle" value="false"/>
<default name="log_ce_lootspawn" value="false"/>
<default name="log_ce_lootcleanup" value="false"/>
<default name="log_ce_statistics" value="false"/>

パフォーマンスを診断するには、log_ce_statistics を "true" に設定します。これによりCEサイクルのタイミングがサーバーRPTログに出力されます。各CEサイクルにかかる時間を示す行を探してください -- サイクルが1000msを超えている場合、エコノミーが過負荷です。

log_ce_lootspawn と log_ce_lootcleanup を "true" に設定すると、どのアイテムタイプが最も頻繁にスポーンおよびクリーンアップされているかが分かります。これらがnominal削減の候補です。

診断後はログをオフにしてください。 ログ書き込み自体がI/Oを消費し、永続的に有効にするとパフォーマンスが悪化する可能性があります。

serverDZ.cfgのパフォーマンス設定

メインサーバー設定ファイルには限られたパフォーマンス関連オプションがあります:

設定	効果
`maxPlayers`	サーバーが苦戦している場合はこの値を下げてください。各プレイヤーはネットワークトラフィックとエンティティ更新を生成します。60人から40人に変更すると5-10サーバーFPSを回復できます。
`instanceId`	`storage_1/` のパスを決定します。パフォーマンス設定ではありませんが、ストレージが遅いディスクにある場合、パーシステンスI/Oに影響します。

変更できないこと: サーバーティックレートは30 FPSで固定です。これを増減する設定はありません。サーバーが30 FPSを維持できない場合、単に遅く動作します。

MODのパフォーマンス影響

各MODは、エンジンが起動時にコンパイルし毎ティック実行するスクリプトクラスを追加します。影響はMODの品質によって大きく異なります:

コンテンツのみのMOD（武器、衣服、建物）はアイテムタイプを追加しますが、スクリプトのオーバーヘッドは最小限です。コストはティック処理ではなくCE追跡にあります。
スクリプトが重いMOD（OnUpdate() や OnTick() ループを持つもの）は毎サーバーフレームでコードを実行します。これらのMODの最適化されていないループは、MOD関連ラグの最も一般的な原因です。
トレーダー/エコノミーMOD（大きなインベントリを維持するもの）はエンジンが追跡する必要のある永続的なオブジェクトを追加します。

ガイドライン

MODを段階的に追加してください。10個を一度に追加するのではなく、各追加後にサーバーFPSをテストしてください。
新しいMODを追加した後、管理者ツールまたはRPTログ出力でサーバーFPSを監視してください。
MODが問題を引き起こしている場合、そのソースでフレームごとの高負荷な処理を確認してください。

コミュニティの見解: 「アイテム（types）とイベントスポーンが最も負荷が高い -- 何千ものtypes.xmlエントリを追加するMODは、複雑なスクリプトを追加するMODよりも影響が大きい。」

ハードウェア推奨事項

DayZサーバーのゲームロジックは シングルスレッド です。マルチコアCPUはOSのオーバーヘッドとネットワークI/Oに役立ちますが、メインゲームループは1コアで動作します。

コンポーネント	推奨	理由
CPU	入手可能な最高のシングルスレッド性能。AMD 5600X以上。	ゲームループはシングルスレッドです。コア数よりもクロック速度とIPCが重要です。
RAM	最小8 GB、MODが多いサーバーでは12-16 GB	MODと大きなマップはメモリを消費します。不足するとスタッターが発生します。
ストレージ	SSD必須	`storage_1/` のパーシステンスI/Oは常時発生します。HDDは保存サイクル中にヒッチングを引き起こします。
ネットワーク	100 Mbps以上、低レイテンシー	デシンク防止にはピング安定性が帯域幅よりも重要です。

コミュニティのヒント: 「OVHは良いコストパフォーマンスを提供します -- 約60ドルUSDで、60スロットのMOD入りサーバーを処理できる専用5600Xマシンが手に入ります。」

人口の多いサーバーでは共有/VPSホスティングを避けてください。共有ハードウェアのノイジーネイバー問題は、あなたの側からは診断不可能な予測できないFPSドロップを引き起こします。

サーバーヘルスの監視

サーバーFPS

RPTログでサーバーFPSを含む行を確認します。健全なサーバーは一貫して30 FPSを維持します。警告しきい値:

サーバーFPS	状態
25-30	正常。激しい戦闘や再起動中の軽微な変動は想定内です。
15-25	低下。プレイヤーはアイテムインタラクションと戦闘でデシンクに気づきます。
15未満	危険。ラバーバンディング、アクション失敗、ヒット登録の破損。

CEサイクル警告

log_ce_statistics を有効にして、CEサイクル時間を監視します。正常は500ms未満です。サイクルが定期的に1000msを超える場合、エコノミーが重すぎます。

ストレージの肥大化

storage_1/ のサイズを監視します。無制限の肥大化はパーシステンスの膨張を示します -- 設置されたオブジェクト、テント、スタッシュが蓄積しすぎています。定期的なサーバーワイプや globals.xml の FlagRefreshMaxDuration を下げることでこれを制御できます。

プレイヤーレポート

プレイヤーからのデシンクレポートは、最も信頼性の高いリアルタイム指標です。複数のプレイヤーが同時にラバーバンディングを報告した場合、サーバーFPSが15を下回っています。

よくあるパフォーマンスの間違い

Nominal値が高すぎる

「ルートが多い方が楽しい」からとすべてのアイテムに nominal=50 を設定すると、数万の追跡オブジェクトが作成されます。CEはゲームを実行する代わりにアイテム管理にサイクル全体を費やします。バニラのnominalから始めて、選択的に増やしてください。

車両イベントが多すぎる

車両は物理シミュレーション、アタッチメント追跡、パーシステンスを伴う高コストなエンティティです。バニラでは合計約50台の車両をスポーンさせます。150台以上の車両を実行するサーバーは重大なFPS低下が見られます。

テストなしで30以上のMODを実行する

各MODは単体では問題ありません。30以上のMODの複合効果 -- 何千もの追加types、フレームごとの何十ものスクリプト、増加したメモリプレッシャー -- はサーバーFPSを50%以上低下させる可能性があります。3-5個のバッチでMODを追加し、各バッチ後にテストしてください。

サーバーを再起動しない

一部のMODには時間とともに蓄積するメモリリークがあります。4-6時間ごとの自動再起動をスケジュールしてください。ほとんどのサーバーホスティングパネルがこれをサポートしています。よく作られたMODでも、エンジン自体のメモリフラグメンテーションが長時間のセッション中に増加するため、定期的な再起動が有益です。

ストレージの膨張を無視する

storage_1/ フォルダが数ギガバイトまで成長すると、すべてのパーシステンスサイクルが遅くなります。特に劣化制限なしの建築を許可している場合は、定期的にワイプまたはトリムしてください。

ログを有効なままにする

CE診断ログ、スクリプトデバッグログ、管理者ツールのログはすべて毎ティックディスクに書き込みます。診断のために有効にしてから、オフにしてください。忙しいサーバーでの永続的な詳細ログは、それだけで1-2 FPSのコストがかかります。

ホーム | << 前へ: パーシステンス | 次へ: アクセス制御 >>

Chapter 9.8: パフォーマンスチューニング ​

目次 ​

サーバーパフォーマンスに影響する要因 ​

globals.xmlのチューニング ​

各値の制御内容 ​

パフォーマンスのためのエコノミーチューニング ​

Nominal値の削減 ​

ダイナミックイベントの削減 ​

アイドルモードの使用 ​

リスポーンレートのチューニング ​

cfgeconomycore.xmlのログ ​

serverDZ.cfgのパフォーマンス設定 ​

MODのパフォーマンス影響 ​

ガイドライン ​

ハードウェア推奨事項 ​

サーバーヘルスの監視 ​

サーバーFPS ​

CEサイクル警告 ​

ストレージの肥大化 ​

プレイヤーレポート ​

よくあるパフォーマンスの間違い ​

Nominal値が高すぎる ​

車両イベントが多すぎる ​

テストなしで30以上のMODを実行する ​

サーバーを再起動しない ​

ストレージの膨張を無視する ​

ログを有効なままにする ​