Frigate에서 현재 공유 메모리 크기가 64MB에 불과하다고 보고하는 경우, Docker Compose 서비스 정의에서 컨테이너의 shm_size를 늘리세요. shm_size를 환경 변수로 추가하지 마세요. Docker Compose에서는 이를 컨테이너의 /dev/shm을 제어하는 서비스 수준의 런타임 설정으로 처리합니다.
사용자가 ZimaBoard 2에서 최소 306MB를 권장하는 내용을 확인했습니다. 정확한 값은 작업 부하에 따라 달라지므로, 특정 숫자를 무작정 복사하지 말고 설정 방법을 적용하세요. 카메라 수, 해상도, 디코딩되는 프레임 수에 따라 Frigate에 필요한 공유 메모리 크기가 달라집니다.
Frigate가 기본적으로 64MB를 확인하는 이유
Docker 컨테이너는 일반적으로 비교적 작은 공유 메모리 파일 시스템으로 시작합니다. Frigate는 디코딩된 원시 비디오 프레임에 /dev/shm을 사용하므로, 호스트에 사용 가능한 RAM이 충분하더라도 카메라 작업에서 기본값을 초과할 수 있습니다.
따라서 이 경고는 단순히 전체 시스템 메모리에 관한 것이 아니라 컨테이너에 할당된 공유 메모리에 관한 것입니다. 물리적 RAM을 추가해도 컨테이너의 /dev/shm 크기가 자동으로 늘어나지는 않습니다.
shm_size는 환경 변수가 아닙니다
포럼 문제 해결 과정의 한 단계에서는 환경 변수 섹션에 shm_size를 추가하려고 했습니다. 다른 참여자는 이것이 Docker의 공유 메모리 마운트를 구성하지 않는다고 정확히 지적했습니다.
Docker Compose에서는 shm_size를 이미지, 재시작 정책, 볼륨, 장치와 같은 설정과 나란히 서비스 아래에 직접 정의합니다. 현재 Docker Compose 참조 문서에 따르면 이 필드는 서비스 컨테이너의 /dev/shm 크기를 구성합니다.
Docker Compose shm_size 참조 문서가 공식 구문 출처입니다.
Frigate 서비스 YAML 편집
해당 스레드에서는 바이트 기준으로 약 1GB에 해당하는 서비스 수준 값을 사용했습니다. 현재 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 값이 필요합니다.
