How to Increase the Memory Limit for a Collabora Online CODE Container

If a Collabora Online Development Edition (CODE) container is being killed under load or consistently runs close to its Docker memory ceiling, the practical fix is usually to raise the container's Docker memory limit, not to change a setting inside Collabora itself. Docker applies memory limits at the container runtime level, and Collabora runs within that boundary.

This guide uses a clearly hypothetical example throughout: imagine a small team running a container named code on a Linux Docker host. The container has a 2 GiB hard memory limit, and during busy editing periods it approaches that limit. The team decides to test a 4 GiB ceiling while keeping enough RAM available for the operating system and other services. The figures and utilization values in this example are illustrative, not measured results from a real deployment.

As of October 2026, the commands below align with current Docker documentation. Collabora's own Docker documentation identifies the CODE image as a Docker-deployed Collabora Online option; Docker is the component that enforces container resource limits. Refer to the official Collabora Online CODE Docker documentation and Docker's resource constraints documentation when adapting the steps to your environment.

What increasing the memory limit actually changes

A Docker memory limit is a ceiling on how much RAM a container may use. Raising it gives CODE more headroom before the container encounters memory pressure or an out-of-memory condition. It does not reserve that entire amount in advance, and it does not guarantee that document editing will become faster. CPU saturation, storage latency, network conditions, document complexity, concurrent users, and application-level behavior can still be bottlenecks.

Docker documents --memory (or -m) as the hard container memory limit. Docker also provides --memory-swap, which controls the combined RAM-plus-swap allowance when a memory limit is set. Swap can provide a cushion, but frequent swapping has a performance cost. For an office editing service, avoid treating swap as a substitute for adequate physical memory.

Step 1: Confirm that memory pressure is the real problem

Start by identifying the running CODE container and observing its current resource use:

docker ps
docker stats code

In the hypothetical scenario, docker stats shows the code container using about 1.8 GiB out of a 2.0 GiB limit. That would be a reason to investigate further, but a single snapshot is not enough to justify a permanent change. Watch usage during the workload that causes failures, and inspect container logs for termination or restart symptoms.

Una regola decisionale utile è semplice: se il container si avvicina ripetutamente al limite massimo configurato, contemporaneamente a sessioni fallite, riavvii o eventi correlati a OOM (Out Of Memory), aumentare il limite è un test successivo ragionevole. Se la memoria rimane ben al di sotto del limite massimo, è improbabile che la modifica del limite risolva il problema di fondo.

Passaggio 2: Leggere il limite di memoria Docker configurato

Verifica direttamente il valore della memoria configurata del container:

docker inspect code --format '{{.HostConfig.Memory}}'

Docker riporta questo valore in byte. Ad esempio, 2147483648byte equivalgono a 2 GiB. È possibile convertirlo manualmente o tramite l'aritmetica della shell:

echo $((2147483648 / 1024 / 1024 / 1024))

Se il valore di inspect è 0, Docker normalmente considera il container come privo di un limite di memoria esplicito. In tal caso, la vera causa potrebbe essere una carenza a livello host, un altro orchestratore o un vincolo diverso. Docker afferma che i container non hanno vincoli di risorse per impostazione predefinita, a meno che non vengano configurati dei limiti.

Passaggio 3: Aumentare il limite su un container Linux esistente

Docker supporta la modifica del limite di memoria di un container esistente con docker update. Per l'ipotetica modifica da 2 GiB a 4 GiB:

docker update --memory 4g --memory-swap 4g code

Impostando --memory-swaplo stesso valore di si --memoryimpedisce a quel container di utilizzare lo swap secondo le regole di swap della memoria documentate da Docker. Se la tua policy operativa consente lo swap, scegli un valore deliberatamente invece di copiare questo esempio. Ad esempio, un --memory-swapvalore più grande consente un po' di swap oltre il limite di RAM, mentre -1consente uno swap illimitato in base allo swap disponibile dell'host.

La documentazione attuale di Docker sull'aggiornamento dei container Docker elenca --memory, --memory-reservation, e --memory-swapcome impostazioni aggiornabili. Docker nota anche che docker updatenon è supportato per i container Windows; le distribuzioni CODE normalmente utilizzano un container Linux, ma questa distinzione è importante se si adatta il comando altrove.

Dopo l'aggiornamento, verificare sia la configurazione che lo stato di esecuzione:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

Non interpretate una percentuale inferiore dopo la modifica come prova che il servizio ora necessiti di meno RAM. La percentuale diminuisce perché il denominatore è maggiore. Ciò che conta è se il container rimane stabile sotto il carico di lavoro che in precedenza lo portava a una pressione eccessiva sulla memoria.

Passaggio 4: Rendere permanente la modifica in Docker Compose

Se il container è gestito da Docker Compose, aggiorna la configurazione di Compose come fonte di riferimento. In caso contrario, una futura ricreazione del servizio potrebbe ripristinare il limite precedente o rimuovere la modifica applicata solo in fase di esecuzione.

Nelle versioni moderne di Docker Compose, la proprietà `service-level` mem_limitimposta la quantità di memoria che il container può allocare:

services:
  collabora:
    image: collabora/code
    container_name: code
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "9980:9980"

La documentazione di riferimento di Docker Compose per `mem_limit` afferma che mem_limitconfigura il limite di memoria per un container di servizio. Compose supporta anche i limiti di risorse in `<resource_limit>` deploy.resources.limits.memory; se si utilizzano entrambe le forme, Docker afferma che i valori di memoria devono essere coerenti.

Applica la configurazione:

docker compose up -d

Quindi verifica se il servizio è stato ricreato o riavviato:

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

Quanta memoria dovresti assegnare?

Non esiste un singolo valore di sicurezza valido per tutte le installazioni di CODE. Il limite appropriato dipende dal numero di editor simultanei, dalle dimensioni e dalla complessità dei documenti, dalla capacità dell'host, dagli altri container e dal modo in cui il servizio è integrato. Il manuale SDK di Collabora include esempi di configurazione delle risorse Kubernetes, tra cui un esempio orientato alla produzione con richieste e limiti di memoria di diversi gigabyte, ma questo non deve essere considerato una formula universale per il dimensionamento di Docker.

Per il server ipotetico, il passaggio da 2 GiB a 4 GiB dovrebbe essere considerato come una modifica controllata della capacità. Il team dovrebbe verificare che l'host disponga di RAM libera sufficiente per assorbire il picco più elevato senza sovraccaricare altri servizi critici. Su un host con una quantità limitata di RAM libera, l'aumento del limite CODE potrebbe semplicemente spostare l'errore dal container all'host.

Un processo pratico di dimensionamento

• Registrare il limite attuale e il picco di utilizzo durante i periodi di maggiore affluenza tipici.
• È meglio aumentare il limite gradualmente, piuttosto che renderlo di fatto illimitato.
• Lascia spazio sufficiente per il sistema operativo host, il proxy inverso, Nextcloud o altri servizi di integrazione, i database e gli agenti di monitoraggio.
• Ripeti il ​​carico di lavoro e osserva il consumo effettivo di memoria, i riavvii dei container e gli errori visibili all'utente.
• Se l'utilizzo continua a crescere avvicinandosi a ogni nuovo limite, invece di aggiungere ripetutamente RAM, è consigliabile analizzare il comportamento dell'applicazione, documentare i modelli e i log.

E per quanto riguarda la prenotazione e lo scambio di memoria?

Docker distingue tra un limite di memoria rigido e una prenotazione di memoria flessibile. Una prenotazione può influenzare il comportamento quando l'host è conteso, mentre il limite rigido rimane il limite massimo assoluto. Per molte configurazioni CODE a singolo host, è più semplice iniziare con un limite rigido esplicito. Aggiungere una prenotazione solo quando si dispone di una chiara politica di condivisione delle risorse a livello di host.

Lo swap richiede particolare attenzione. La documentazione di Docker spiega che --memory-swaprappresenta la memoria totale più lo swap quando è impostato su un valore positivo. Se --memory=4ge --memory-swap=6g, il container può utilizzare fino a 4 GiB di RAM e fino a 2 GiB di swap aggiuntivo. Ciò può prevenire arresti anomali improvvisi in alcune situazioni, ma un'attività di swap prolungata può rallentare la modifica interattiva. Monitorare lo swap anziché presumere automaticamente una maggiore quantità di swap è più sicuro.

Come capire se il cambiamento ha funzionato

Il successo non è semplicemente vedere 4 GiB. docker statsI segnali significativi sono operativi:

• Il limite configurato e segnalato docker inspectcorrisponde al valore previsto.
• Il contenitore rimane al di sotto del nuovo soffitto durante il carico di lavoro che in precedenza causava problemi.
• In condizioni comparabili, i riavvii imprevisti o i guasti correlati alla memoria insufficiente cessano di verificarsi.
• L'host Docker conserva ancora una buona riserva di memoria e non inizia a utilizzare intensamente lo swap.
• La modifica rimane reattiva anziché limitarsi a evitare la terminazione.

Se il container continua a fallire anche con valori ben al di sotto del nuovo limite, cambia approccio. Controlla docker logs codei log del kernel dell'host, gli errori del reverse proxy, i log del server di integrazione e la saturazione della CPU o dell'I/O. Un limite di memoria è solo uno degli aspetti di un'implementazione di Collabora.

Errori comuni da evitare

• Modificando solo il container in esecuzione, docker update è possibile risolvere il limite immediato, ma è necessario aggiornare anche i servizi gestiti da Compose nel file Compose.
• Assegnare a CODE tutta la memoria dell'host: l'host e i servizi vicini necessitano di margine di sicurezza. Un container senza restrizioni può contribuire all'instabilità dell'intero host.
• Supponendo che lo swap sia memoria libera: lo swap è più lento della RAM e Docker avverte esplicitamente di una penalizzazione delle prestazioni quando le applicazioni effettuano frequentemente lo swap.
• Confondere la memoria del container con la memoria PHP: il limite del container Docker CODE è separato dalle impostazioni PHP utilizzate da applicazioni come Nextcloud.
• Utilizzando un'istantanea come prova: misurare durante un periodo di domanda rappresentativo e confrontare il comportamento prima e dopo il cambiamento.

In conclusione

Per aumentare il limite di memoria per un container Collabora Online CODE, verificare innanzitutto che il limite Docker esistente venga effettivamente raggiunto. Per un container Linux esistente, docker update --memory ...è possibile modificare il limite massimo in fase di esecuzione. Per una distribuzione gestita da Compose, rendere persistente il limite con mem_limituna configurazione di risorse Compose coerente, quindi ricreare o aggiornare il servizio e verificarne il risultato.

L'esempio ipotetico del passaggio da 2 GiB a 4 GiB è utile perché mostra l'intero ciclo decisionale: osservare la pressione, confermare il limite configurato, aumentarlo deliberatamente, rendere persistente la configurazione e convalidarla con lo stesso carico di lavoro. Questo processo è più affidabile rispetto al semplice assegnare un valore elevato e presumere che il problema sia risolto.