Als Frigate meldt dat de huidige grootte van het gedeelde geheugen slechts 64 MB is, verhoog je shm_size van de container in de Docker Compose-servicedefinitie. Voeg shm_size niet toe als omgevingsvariabele; Docker Compose behandelt dit als een runtime-instelling op serviceniveau die de grootte van /dev/shm van de container bepaalt.
De gebruiker uit de bron kreeg op een ZimaBoard 2 het advies om minimaal 306 MB te gebruiken. De exacte waarde is afhankelijk van de werklast, dus neem het mechanisme over en kopieer niet blind één getal. Het aantal camera's, de resolutie en het aantal gedecodeerde frames hebben allemaal invloed op de benodigde hoeveelheid gedeeld geheugen van Frigate.
Waarom Frigate standaard 64 MB ziet
Docker-containers starten vaak met een relatief klein bestandssysteem voor gedeeld geheugen. Frigate gebruikt /dev/shm voor onbewerkte, gedecodeerde videoframes, waardoor camerawerklasten de standaardwaarde kunnen overschrijden, zelfs als de host zelf nog voldoende RAM beschikbaar heeft.
De waarschuwing gaat daarom over de toewijzing van gedeeld geheugen aan de container, niet simpelweg over het totale systeemgeheugen. Meer fysiek RAM toevoegen vergroot /dev/shm van de container niet automatisch als je de containerinstelling niet wijzigt.
shm_size is geen omgevingsvariabele
In een deel van de probleemoplossing op het forum probeerde iemand shm_size toe te voegen in het gedeelte met omgevingsvariabelen. Een andere deelnemer wees er terecht op dat dit de gedeelde-geheugenmount van Docker niet configureert.
Docker Compose definieert shm_size rechtstreeks onder de service, naast instellingen zoals de image, het herstartbeleid, volumes en apparaten. De huidige Compose-referentie van Docker vermeldt dat dit veld de grootte van /dev/shm van de servicecontainer instelt.
Referentie voor shm_size in Docker Compose is de gezaghebbende bron voor de syntaxis.
Bewerk de YAML van de Frigate-service
In de thread werd een waarde op serviceniveau gebruikt die ongeveer overeenkwam met 1 GB in bytes. De huidige Compose-parsers en Frigate-voorbeelden ondersteunen ook leesbare grootheden. Een vereenvoudigde structuur ziet er als volgt uit:
services:
frigate:
image: ...
shm_size: "512mb"
...Houd het veld op hetzelfde inspringingsniveau als de andere runtime-instellingen van de service. Als een bepaalde ZimaOS-build of editor een leesbare eenheid weigert, is de vorm in bytes uit de communitythread een compatibele terugvaloptie; het belangrijkste is dat de instelling bij de Compose-service hoort en niet onder environment:.
Kies een waarde voor je daadwerkelijke camerawerklast
De huidige documentatie van Frigate legt uit dat de behoefte aan gedeeld geheugen afhankelijk is van de beeldafmetingen en het aantal gebufferde frames. Het huidige voorbeeldbestand voor Compose gebruikt een grotere toewijzing dan de standaardwaarde van Docker en bevat richtlijnen voor het schatten van de vereisten.
Stel geen willekeurig hoge waarde in zonder reden. Verhoog de waarde voldoende om de waarschuwing tijdens de werkelijke werklast te laten verdwijnen, start de container opnieuw of maak hem opnieuw aan zodat de runtime-instelling wordt toegepast, en controleer vervolgens de effectieve grootte vanuit de actieve container.
Huidige installatie-instructies voor Frigate hebben voorrang op een vaste waarde uit de thread van 2026.
De bewerkingsworkflow van ZimaOS is versieafhankelijk
Het oorspronkelijke bericht werd geplaatst toen de gebruiker ZimaOS 1.6.0 beta gebruikte. Een antwoord van IceWhale vermeldde ook dat het gedrag van gedeeld geheugen aan de hostzijde in 1.5.4 verschilde van wat de gebruiker zag, waardoor verwarring ontstond tussen de instellingen van de host en de container.
De huidige ZimaOS 1.7.x biedt ingebouwde YAML-bewerking en 1.7.1 verbeterde specifiek de compatibiliteit bij het opslaan van YAML. Gebruik waar mogelijk de huidige app-editor, maar houd het onderscheid van Docker in gedachten: de Frigate-container heeft nog steeds een eigen waarde voor shm_size nodig, ongeacht hoeveel gedeeld geheugen de host rapporteert.
