Verhoog de geheugenlimiet van de CODE-container zonder te gokken.

Om een ​​Collabora Online CODE-container meer geheugen te geven, verhoogt u de Docker-limiet in de configuratie waarmee de container wordt aangemaakt. Maak vervolgens de container opnieuw aan en controleer de effectieve limiet met docker inspectof docker stats. Het verhogen van een applicatie-instelling verhoogt de Docker-containerlimiet niet. De host of de virtuele machine van Docker Desktop moet voldoende geheugen beschikbaar hebben om de hogere limiet te kunnen hanteren.

Hypothetisch voorbeeld dat in dit document wordt gebruikt: Riley beheert een Docker Compose-implementatie op één host. Stel dat docker statser een limiet van 2 GiB wordt weergegeven en het gebruik bijna die limiet bereikt terwijl er meerdere documenten openstaan. Riley overweegt een limiet van 4 GiB. Deze getallen zijn slechts voorbeelden en geen aanbeveling voor de grootte van Collabora, geen prestatieclaim en geen testresultaat; uw limiet moet gebaseerd zijn op de waargenomen belasting en de capaciteit van de host.

1. Controleer of de container daadwerkelijk de bovenkant raakt.

Voer deze opdrachten uit op de Docker-host en vervang collaboradoor de daadwerkelijke containernaam:

docker stats --no-stream collabora
docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora

docker statsToont het huidige gebruik en de containerlimiet. De inspectie-uitvoer rapporteert de geconfigureerde geheugenlimiet in bytes en of Docker de container als OOM-killed registreert. Een inspectiewaarde van 0betekent dat Docker geen expliciete harde limiet voor die container heeft; het betekent niet dat de machine onbeperkt RAM heeft. Een hoge waarde alleen is geen bewijs van een out-of-memory-gebeurtenis, dus vergelijk deze met de herstartgeschiedenis, logboeken en het tijdstip waarop gebruikers fouten hebben gezien.

Voordat u de limiet verhoogt, controleert u hoeveel RAM er nog beschikbaar is voor het besturingssysteem en andere services. De richtlijnen van Docker voor resourcegebruik raden aan om de vraag naar applicaties te testen en containers te draaien op hosts met voldoende resources. Controleer bij Docker Desktop ook Instellingen > Resources : het geheugen dat is toegewezen aan de Docker VM is een aparte limiet die wordt gedeeld door de containers. Het verhogen van de CODE-limiet boven deze toewijzing kan geen extra fysiek geheugen creëren; raadpleeg de resource-instellingen van Docker Desktop .

2. Wijzig de limiet van de Compose-service.

Bewerk de bestaande CODE-service in uw Compose-bestand. Behoud de huidige imagetag, poorten, omgeving, volumes, netwerken en herstartbeleid; voeg alleen de geheugeninstelling toe of werk deze bij. Voor Riley's hypothetische voorbeeld van 4 GiB:

services:
  collabora:
    image: collabora/code:your-current-tag
    mem_limit: 4g
    # Keep the service’s existing settings below

Dit voorbeeld gebruikt de officiële CODE Docker-image van Collabora ; behoud de tag die al door uw implementatie wordt gebruikt. mem_limitis een harde limiet, geen reservering: Docker kan de container tot die hoeveelheid laten gebruiken, maar de instelling reserveert niet zoveel RAM op de host. De Docker Compose-servicereferentie definieert mem_limiten stelt dat deze moet overeenkomen met deploy.resources.limits.memoryals beide aanwezig zijn. Als uw implementatie een orchestrator of een platform-beheerd Compose-bestand gebruikt, gebruik dan het veld voor ondersteunde resources van dat platform en zorg ervoor dat dubbele limietwaarden consistent zijn.

Als je CODE rechtstreeks hebt gestart met docker run, maak het dan opnieuw aan vanuit de oorspronkelijke opdracht met --memory=4gen behoud alle huidige opties. Voor een snelle runtime-wijziging in een bestaande Linux-container ondersteunt Docker ook docker update --memory 4g <container_name>. Beschouw het Compose-bestand of de oorspronkelijke run-opdracht als de bron van waarheid, zodat een latere vervanging de oude cap niet herstelt. Zie de Docker-containerupdatehandleiding .

3. Herschrijf de CODE zodat de opgeslagen limiet van kracht wordt.

Valideer vanuit de map met het actieve Compose-bestand de samengevoegde configuratie en maak vervolgens alleen de CODE-service opnieuw aan:

docker compose config
docker compose up -d --no-deps --force-recreate collabora

Gebruik de servicesleutel uit uw bestand in plaats van collabora. Controleer de weergegeven configuratie voor de nieuwe limiet voordat u deze toepast. Het opnieuw aanmaken van CODE onderbreekt kortstondig bewerkingssessies die afhankelijk zijn van die container, dus plan de wijziging in wanneer een korte serviceonderbreking acceptabel is. Verwijder geen volumes en voer geen uit docker compose down -v; deze bewerkingen zijn niet nodig voor een wijziging van de geheugenlimiet en kunnen persistente gegevens van andere services verwijderen.

4. Controleer de nieuwe dop en beoordeel het gedrag onder belasting.

Nadat de service is teruggekeerd, controleer dan de daadwerkelijke container – niet alleen het YAML-bestand:

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora
docker stats --no-stream collabora

Voor de voorbeeldwaarde 4gzou de inspectie-uitvoer ongeveer 4 GiB aan bytes moeten weergeven en docker statseen limiet rond de 4 GiB moeten tonen. De onderstaande afbeelding gebruikt de voorbeelduitvoer alleen ter illustratie. Observeer vervolgens CODE tijdens het openen van de documenttypen en het geschatte aantal gelijktijdige sessies dat relevant is voor uw implementatie. Controleer of de container actief blijft, of er geen zichtbare fouten meer optreden en of de host voldoende geheugen behoudt voor de andere processen.

Als het probleem aanhoudt

Als de nieuwe limiet aanwezig is, maar CODE nog steeds opnieuw opstart, controleer dan docker inspectde status docker logsen de kernel- of Docker-gebeurtenissen van de host op een melding van geheugenproblemen. Als de container gezond blijft, maar de documentverwerking nog steeds opschoning activeert, is Docker mogelijk niet de actieve bottleneck. Collabora's eigen coolwsdconfiguratie heeft geheugenbeheergedrag dat losstaat van de Docker cgroup-limiet; de configuratiesjabloon van het project documenteert de server-side controles. Controleer de configuratie voor uw geïnstalleerde CODE-release voordat u deze wijzigt.

Los onzekerheid niet op door de container onbeperkt geheugen te geven of de 'out-of-memory killer' uit te schakelen. Docker waarschuwt dat een container met onbeperkt geheugen kan leiden tot overbelasting van het hostgeheugen en problemen kan veroorzaken voor andere services. Als de host geen veilige marge heeft, is de beste oplossing het vergroten van de capaciteit van de host of de Docker VM, het verminderen van de gelijktijdige workload of het verdelen van de taken – en niet het verhogen van de limiet boven het beschikbare RAM-geheugen.