Memory Profilerを使ったアプリケーションの物理メモリフットプリントの分析
メモリの問題を効率的に検出し、パフォーマンスを最適化するためには、メモリプロファイラに表示される情報とその精度が鍵となる。我々はこの分野に多大な投資をしている。先日の2つのブログで、私のチームのメンバーはMemory Profiler 1.0.0を紹介し、ゲームのメモリ関連の問題を診断し、調査するための5つの主要なワークフローを共有した。
メモリがどのように機能し、アプリケーションのメモリ・フットプリントがどのように計算されるかを説明するラベルや説明が更新されます。
メモリ・フットプリントは、開発者との会話でホットなトピックであり続けているため、ここではよくある質問に答えることにする：
- 常駐メモリとは
- アプリケーションのメモリフットプリントの計算方法
- メモリフットプリントの解析方法
Unityのメモリ割り当てについて掘り下げてみよう。エンジンがメモリを割り当てると、まず仮想アドレス空間に要求された割り当てに対応できる複数のメモリ・ページを確保する。ページはメモリ管理の最小単位である。仮想アドレス空間と物理ストレージはそれぞれページで構成され、ページサイズは使用するプラットフォームによって異なる。例えば、x86コンピュータのページサイズは4KBである。
エンジンは十分なページを確保した後、オペレーティング・システム（OS）に物理ストレージをメモリに「コミット」するよう要求する。これが、割り当てられたメモリがしばしば "コミット "と呼ばれる理由である。次に、OSはページが物理ストレージに割り当てられ、アクセスできるようになったことを登録する。アプリケーションが報告する "総コミットメモリー "は増加する。しかし、アプリケーションの物理メモリフットプリントは変わりません。
リージョンを物理ストレージにコミットしても、ほとんどのOSは怠け者で倹約家なので、特定の物理ストレージの場所を指定しないため、フットプリントは変わらない。例として、あなたがコミットされた領域で何かを書こうと決めたとしよう。この領域の下にはまだ物理メモリがないため、アクセスするとページフォールトが発生する。これに対して、OSのメモリー・マネージャーは、操作を完了するために、以前に利用可能だった物理ページを確保する。すべての操作はページ・サイズの粒度で実行されるため、領域の未アクセス・ページは空のままとなり、物理メモリは割り当てられない。同様に、アプリケーションの常駐メモリ・サイズは、操作を完了するために割り当てられたすべての物理メモリ・ページの合計サイズだけ増加します。
ページがしばらくアクセスされなかったり、物理メモリへの要求が高い場合、OSは割り当てられた領域からいくつかのページを圧縮メモリかページスワップファイルにオフロードするかもしれない。
この場合、アプリケーションの報告された割り当てメモリは変わりませんが、常駐メモリ・サイズは減少します。
すでにお気づきかもしれないが、割り当てられたメモリだけを見ていると、どの割り当てが物理メモリを消費しているかに惑わされ、問題ではないものを最適化するよう騙される可能性がある。これでは貴重な時間を無駄にするだけでなく、アプリケーションのパフォーマンスや安定性に何の変化も見られない。
全体として、アプリケーションのメモリー状態はこの図で説明できる：
要約すると、メモリー・フットプリントの計算方法はこうだ：
物理メモリフットプリント＝アプリケーション常駐メモリ＋アプリケーション圧縮メモリページ
Memory Profiler 1.1では、Summary、Unity Objects、All Of Memoryの各ビューで、Allocatedメモリサイズだけでなく、Residentメモリに関する情報も表示されます。ただし、この情報は、Memory ProfilerスナップショットがUnity 2023.1以降で作成された場合にのみ表示されます。古いスナップショットでは、更新されたUIと内訳ビューが表示されますが、常駐メモリに関する情報は表示されません。
Summaryビューは、一般的な概要と重要な指標を提供する：デバイスに常駐。メモリが制限されたプラットフォーム上でアプリケーションを実行する必要がある場合、Total Resident on Deviceは、メモリ不足の警告やメモリ不足の回避を確認するために非常に重要です。経験則として、デバイスで利用可能な物理メモリ総量の70％を超えてはならない。
詳細な分析には、Unity Objects および All of Memory ビューを使用できます。物理メモリの総使用量に最も寄与しているオブジェクトを見るには、ドロップダウンメニューからResident on DeviceまたはAllocated and Resident on Deviceを選択し、Resident sizeでソートする必要がある。
常駐メモリーの使用状況を分析するときは、覚えておいてほしい：
- マネージド・メモリは常駐型が主流となる。Mono HeapとBoehm Garbage Collectorは、定期的にオブジェクトにアクセスして常駐させる。
- グラフィックメモリ（推定）は 推定と表示されます。ほとんどのプラットフォームでは、グラフィックリソースの正確な所在に関する情報にアクセスできないため、幅、高さ、奥行き、ピクセルフォーマットなどの利用可能な情報に基づいてサイズを推定します。これはまた、グラフィック・リソースの在留資格に関する情報がないことを意味する。使い勝手を考慮し、すべてのグラフィックス・オブジェクトは、Allocatedビュー・モードでのみ表示される。
- 未追跡とは、アプリケーションによって割り当てられたとOSから報告されたすべてのメモリのことで、割り当て元に関する確かな情報を欠いている。ネイティブプラグイン、OSライブラリ、スレッドスタックなどだ。いくつかのプラットフォームでは、誰がそのメモリーを割り当てたのか、グループの内訳をさらに詳しく説明しています。
オブジェクトが使用するすべてのUnity非管理割り当てを含むNative メモリを分析する場合、Reservedメモリの項目が表示されます。これはUnity Memory Managerによって割り当てられたメモリですが、キャプチャ中にUnityオブジェクトによって使用されることはありません。ここに役立つ情報がある：
- リザーブド・メモリは常駐している可能性があり、これは最近削除されたオブジェクトがあるかもしれないことを意味する。
- Memory Profilerの設定で "Show reserved memory breakdown "チェックボックスを有効にすると、Reserved breakdownに関する追加情報にアクセスできる。デフォルトでは、これは無効になっています。Reservedブレークダウンには常に十分な実用的な情報が含まれているわけではなく、Unity Memory Managerがどのように動作するかを深く理解する必要があるからです。
- Unity Memory Managerとアロケーション戦略については、アロケータセットアップドキュメントで詳しく説明されています。
いくつかのプラットフォームでは、AndroidのAndroid Runtimeのように、サイズが大きい場合、さらにプラットフォーム固有のグループを表示します。以下はAndroid Runtimeに関するメモである：
- いくつかのバージョンでは、Android Runtimeはかなりの量のメモリを事前に割り当てたが、決して使用しない傾向がある。その場合、割り当てられたメモリーはアプリケーションのメモリー・フットプリントには追加されず、常駐部分のみを考慮する必要がある。
- Android Runtimeの常駐部分がアプリケーションのメモリフットプリントの大部分を占めている場合は、Android Studioのプロファイラを使ってJavaで行われた割り当てを分析する。
- Androidにはデフォルトでページ・ファイルやメモリ圧縮がないが、Linuxカーネルではアプリケーションがオーバーコミットし、物理的に利用可能なメモリよりも多くのメモリを確保することができる。
- キャプチャーする際は、使用しているデバイスを理解していることを確認すること。一部のベンダーは、Android Linuxカーネルにメモリ圧縮（zRAM）やベンダーカスタムのページスワップファイルツールを提供している。
Memory Profiler 1.1（現在入手可能な実験的バージョン）に期待されることの概要と、メモリ・フットプリントに関する様々なトピックの考察がお役に立てば幸いです。
私のチームと私は、より正確で的を絞った情報を提供し、潜在的なメモリ不足の状況やその可能性を警告するために、メモリ・プロファイラの改良を続ける予定です。製品ロードマップの進捗状況を確認し、ご意見をお聞かせください。
フォーラムでご意見をお聞かせください。現在進行中の Tech from the Trenchesシリーズの一環として、他のUnity開発者による新しい技術ブログをぜひご覧ください。