Frigateが現在の共有メモリサイズを64 MBしかないと報告する場合は、Docker Composeのサービス定義でコンテナのshm_sizeを増やしてください。shm_sizeを環境変数として追加しないでください。Docker Composeでは、これはコンテナの/dev/shmを制御するサービスレベルのランタイム設定として扱われます。
原文のユーザーは、ZimaBoard 2で少なくとも306 MBを推奨されました。正確な値はワークロードによって異なるため、数字をそのまま盲目的にコピーするのではなく、設定方法を参考にしてください。カメラの台数、解像度、デコードするフレーム数はいずれも、Frigateに必要な共有メモリ量に影響します。
Frigateがデフォルトで64 MBと認識する理由
Dockerコンテナは通常、比較的小さな共有メモリファイルシステムで起動します。Frigateはデコード前の動画フレームに/dev/shmを使用するため、ホスト自体に十分な空きRAMがあっても、カメラの処理でデフォルト値を超えることがあります。
したがって、この警告はシステム全体のメモリ量ではなく、コンテナに割り当てられた共有メモリに関するものです。物理RAMを増設しても、コンテナの/dev/shmが自動的に拡大するわけではありません。
shm_sizeは環境変数ではない
フォーラムでのトラブルシューティングの一案では、環境変数のセクションにshm_sizeを追加しようとしていました。しかし、別の参加者が指摘したとおり、これはDockerの共有メモリマウントを設定する方法ではありません。
Docker Composeでは、shm_sizeをサービスの直下に直接定義します。image、restartポリシー、volumes、devicesなどの設定と同じ階層です。Dockerの現在のComposeリファレンスによると、このフィールドはサービスコンテナの/dev/shmのサイズを設定します。
Docker Compose shm_sizeリファレンスが正式な構文の情報源です。
FrigateのサービスYAMLを編集する
スレッドでは、バイト単位でおよそ1 GBに相当するサービスレベルの値が使われていました。現在のComposeパーサーやFrigateの例では、人間が読みやすいサイズ表記もサポートされています。簡略化した構成は次のようになります。
services:
frigate:
image: ...
shm_size: "512mb"
...このフィールドは、サービスにある他のランタイム設定と同じインデントレベルに置いてください。使用しているZimaOSのビルドやエディターによって人間が読みやすい単位が拒否される場合は、コミュニティのスレッドで使われたバイト単位の形式が互換性のための代替手段になります。重要なのは、この設定をenvironment:ではなくComposeサービスに記述することです。
実際のカメラワークロードに合った値を選ぶ
Frigateの現在のドキュメントでは、共有メモリの需要は画像のサイズとバッファーされるフレーム数によって決まると説明されています。現在のサンプルComposeファイルでは、Dockerのデフォルト値より大きな割り当てが使用され、必要量の見積もり方法も案内されています。
理由なく極端に大きな値を設定しないでください。実際のワークロードで警告が消えるだけの値まで増やし、ランタイム設定が適用されるようにコンテナを再起動または再作成してから、実行中のコンテナ内で有効なサイズを確認してください。
現在のFrigateインストールガイダンスを、2026年のスレッドにある固定値より優先してください。
ZimaOSの編集手順はバージョンによって異なる
元の投稿が作成された時点で、ユーザーはZimaOS 1.6.0ベータ版を使用していました。IceWhaleの返信では、1.5.4におけるホスト側の共有メモリの動作が、ユーザーが確認していた内容と異なることも指摘されており、ホストとコンテナの設定が混同される原因になっていました。
現在のZimaOS 1.7.xではネイティブのYAML編集機能が利用でき、1.7.1ではYAML保存の互換性が特に改善されています。可能であれば現在のアプリエディターを使用してください。ただし、Dockerにおける重要な違いは変わりません。ホストが報告する共有メモリ量に関係なく、Frigateコンテナ自体に独自のshm_size値が必要です。
