Como aumentar o limite de memória para um contêiner CODE do Collabora Online

Se um contêiner do Collabora Online Development Edition (CODE) estiver sendo encerrado sob carga ou estiver constantemente operando próximo ao limite de memória do Docker, a solução prática geralmente é aumentar o limite de memória do Docker para o contêiner, e não alterar uma configuração dentro do próprio Collabora. O Docker aplica limites de memória no nível de tempo de execução do contêiner, e o Collabora opera dentro desse limite.

Este guia utiliza um exemplo claramente hipotético: imagine uma pequena equipe executando um contêiner chamado `<nome_do_contêiner>` codeem um host Docker Linux. O contêiner tem um limite rígido de memória de 2 GiB e, durante períodos de edição intensa, ele se aproxima desse limite. A equipe decide testar um limite máximo de 4 GiB, mantendo RAM suficiente disponível para o sistema operacional e outros serviços. Os valores e a utilização apresentados neste exemplo são ilustrativos e não representam resultados reais de uma implementação.

A partir de outubro de 2026, os comandos abaixo estão em conformidade com a documentação atual do Docker. A própria documentação do Docker da Collabora identifica a imagem CODE como uma opção do Collabora Online implantada via Docker; o Docker é o componente que impõe os limites de recursos do contêiner. Consulte a documentação oficial do Docker para o Collabora Online CODE e a documentação sobre restrições de recursos do Docker ao adaptar as etapas ao seu ambiente.

O que realmente muda ao aumentar o limite de memória?

O limite de memória do Docker é um teto para a quantidade de RAM que um contêiner pode usar. Aumentá-lo dá ao CODE mais margem de segurança antes que o contêiner encontre pressão de memória ou uma condição de falta de memória. Isso não reserva toda essa quantidade antecipadamente e não garante que a edição de documentos se tornará mais rápida. Saturação da CPU, latência de armazenamento, condições de rede, complexidade do documento, usuários simultâneos e o comportamento do aplicativo ainda podem ser gargalos.

O Docker documenta --memory(ou -m) como o limite máximo de memória do contêiner. O Docker também fornece --memory-swap, que controla a quantidade combinada de RAM e swap alocada quando um limite de memória é definido. O swap pode fornecer uma margem de segurança, mas a troca frequente de memória tem um custo de desempenho. Para um serviço de edição de escritório, evite tratar o swap como um substituto para memória física adequada.

Passo 1: Confirme se a pressão na memória é realmente o problema.

Comece por identificar o contêiner CODE em execução e observar seu uso atual de recursos:

docker ps
docker stats code

No cenário hipotético, docker statso codecontêiner está utilizando cerca de 1,8 GiB de um limite de 2,0 GiB. Isso seria motivo para uma investigação mais aprofundada, mas um único snapshot não justifica uma alteração permanente. Monitore o uso durante a carga de trabalho que causa as falhas e inspecione os logs do contêiner em busca de sintomas de encerramento ou reinicialização.

Uma regra de decisão útil é simples: se o contêiner se aproximar repetidamente do limite configurado ao mesmo tempo em que os usuários observam falhas de sessão, reinicializações ou eventos relacionados à falta de memória (OOM), aumentar o limite é um próximo passo razoável. Se a memória permanecer confortavelmente abaixo do limite, alterá-lo provavelmente não resolverá o problema subjacente.

Etapa 2: Leia o limite de memória do Docker configurado.

Verifique diretamente o valor de memória configurado no contêiner:

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

O Docker reporta esse valor em bytes. Por exemplo, 2147483648bytes equivalem a 2 GiB. Você pode convertê-lo manualmente ou usando aritmética no terminal:

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

Se o valor de `inspect` for `false` 0, o Docker normalmente trata o contêiner como se não tivesse um limite rígido de memória explícito. Nesse caso, uma escassez de memória no nível do host, outro orquestrador ou uma restrição diferente podem ser a causa real. O Docker afirma que os contêineres não têm restrições de recursos por padrão, a menos que limites sejam configurados.

Etapa 3: Aumente o limite em um contêiner Linux existente

O Docker permite alterar o limite de memória de um contêiner existente com o comando `docker-compose up` docker update. Para uma alteração hipotética de 2 GiB para 4 GiB:

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

Definir --memory-swapo mesmo valor --memoryimpede que o contêiner use swap de acordo com as regras de swap de memória documentadas pelo Docker. Se sua política operacional permite swap, escolha um valor deliberadamente em vez de copiar este exemplo. Por exemplo, um --memory-swapvalor maior permite algum swap além do limite de RAM, enquanto um -1valor maior permite swap ilimitado, sujeito ao swap disponível no host.

A documentação atual do Docker sobre atualização de contêineres lista `docker-compose up` --memory, --memory-reservation`docker-compose up` e ` --memory-swapdocker-compose up` como configurações atualizáveis. O Docker também observa que ` docker updatedocker-compose up` não é compatível com contêineres Windows; as implantações do CODE normalmente usam um contêiner Linux, mas essa distinção é importante se você estiver adaptando o comando em outro contexto.

Após a atualização, verifique a configuração e o estado de execução:

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

Não interprete uma porcentagem menor após a alteração como prova de que o serviço agora precisa de menos RAM. A porcentagem cai porque o denominador é maior. O que importa é se o contêiner permanece estável sob a carga de trabalho que anteriormente o levava à pressão de memória.

Passo 4: Tornar a alteração permanente no Docker Compose

Se o contêiner for gerenciado pelo Docker Compose, atualize a configuração do Compose como fonte de verdade. Caso contrário, uma futura recriação do serviço poderá restaurar o limite anterior ou remover a alteração que afetou apenas o tempo de execução.

Para o Docker Compose moderno, a propriedade de nível de serviço mem_limitdefine a quantidade de memória que o contêiner pode alocar:

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

A referência de serviços do Docker Compose para `mem_limit` define mem_limito limite de memória para um contêiner de serviço. O Compose também suporta limites de recursos em `resource_limit` deploy.resources.limits.memory; se você usar ambas as formas, o Docker afirma que seus valores de memória devem ser consistentes.

Aplicar a configuração:

docker compose up -d

Em seguida, verifique o serviço recriado ou reiniciado:

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

Quanta memória você deve alocar?

Não existe um número único e seguro para todas as instalações do CODE. O limite apropriado depende do número de editores simultâneos, do tamanho e da complexidade do documento, da capacidade do host, de outros contêineres e da forma como o serviço está integrado. O manual atual do SDK da Collabora inclui exemplos de configurações de recursos do Kubernetes, incluindo um exemplo voltado para produção com solicitações e limites de memória de vários gigabytes, mas isso não deve ser considerado uma fórmula universal para dimensionamento do Docker.

Para o servidor hipotético, a transição de 2 GiB para 4 GiB deve ser tratada como uma alteração de capacidade controlada. A equipe deve confirmar se o host possui RAM livre suficiente para absorver o pico de uso sem sobrecarregar outros serviços críticos com excesso de memória. Em um host com pouca RAM disponível, aumentar o limite de CODE pode simplesmente transferir a falha do contêiner para o host.

Um processo prático de dimensionamento

• Registre o limite atual e o pico de consumo durante períodos de maior movimento.
• Aumente o limite em etapas moderadas, em vez de torná-lo praticamente ilimitado.
• Deixe espaço livre para o sistema operacional do host, proxy reverso, Nextcloud ou outros serviços de integração, bancos de dados e agentes de monitoramento.
• Repita a carga de trabalho e observe o consumo real de memória, as reinicializações de contêineres e as falhas visíveis ao usuário.
• Se o uso continuar aumentando em direção a cada novo limite, investigue o comportamento do aplicativo, documente padrões e registros em vez de adicionar RAM repetidamente.

E quanto à reserva e à troca de memória?

O Docker distingue um limite rígido de memória de uma reserva flexível de memória. Uma reserva pode influenciar o comportamento quando o host está sob contenção, enquanto o limite rígido permanece o teto absoluto. Para muitas configurações CODE de host único, começar com um limite rígido explícito é mais fácil de entender. Adicione uma reserva somente quando você tiver uma política clara de compartilhamento de recursos em nível de host.

O uso de swap requer atenção redobrada. A documentação do Docker explica que, --memory-swapquando definido com um valor positivo, representa a memória total mais o swap. Se `swap` --memory=4ge ` swap` estiverem configurados como `true` --memory-swap=6g, o contêiner pode usar até 4 GiB de RAM e até 2 GiB adicionais de swap. Isso pode evitar falhas abruptas em algumas situações, mas o uso contínuo de swap pode tornar a edição interativa lenta. Monitorar o uso de swap em vez de presumir que mais swap é automaticamente mais seguro.

Como saber se a mudança funcionou

O sucesso não se resume a ver 4 GiB. docker statsOs sinais significativos são operacionais:

• O limite configurado relatado docker inspectcorresponde ao valor pretendido.
• O contêiner permanece abaixo do novo teto durante o período de trabalho que anteriormente causava problemas.
• Reinícios inesperados ou falhas relacionadas à falta de memória deixam de ocorrer em condições semelhantes.
• O host Docker ainda mantém uma margem de memória adequada e não começa a usar a memória virtual de forma intensiva.
• A edição mantém-se responsiva, em vez de simplesmente evitar o encerramento.

Se o contêiner ainda falhar mesmo estando muito abaixo do novo limite, mude de estratégia. Inspecione docker logs codeos logs do kernel do host, erros do proxy reverso, logs do servidor de integração e a saturação de CPU ou E/S. Um limite de memória é apenas uma camada de uma implementação do Collabora.

Erros comuns a evitar

• Alterar apenas o contêiner em execução docker update pode resolver a limitação imediata, mas os serviços gerenciados pelo Compose também devem ser atualizados no arquivo Compose.
• Atribuir toda a memória do host ao CODE: o host e os serviços vizinhos precisam de espaço livre. Um contêiner sem restrições pode contribuir para a instabilidade em todo o host.
• Considerando que a memória swap seja considerada memória livre: a memória swap é mais lenta que a RAM, e o Docker alerta explicitamente sobre uma perda de desempenho quando os aplicativos realizam trocas de memória com frequência.
• Confundir memória do contêiner com memória do PHP: o limite de memória do contêiner Docker CODE é independente das configurações do PHP usadas por aplicativos como o Nextcloud.
• Utilizando um único momento como evidência: faça a medição durante uma demanda representativa e compare o comportamento antes e depois da mudança.

Resumindo

Para aumentar o limite de memória de um contêiner do Collabora Online CODE, primeiro verifique se o limite atual do Docker está sendo atingido. Para um contêiner Linux existente, docker update --memory ...é possível alterar o limite máximo em tempo de execução. Para uma implantação gerenciada pelo Compose, persista o limite com mem_limituma configuração de recurso consistente do Compose e, em seguida, recrie ou atualize o serviço e verifique o resultado.

O exemplo hipotético de 2 GiB para 4 GiB é útil porque mostra todo o ciclo de decisão: observar a pressão, confirmar o limite configurado, aumentá-lo deliberadamente, persistir a configuração e validar sob a mesma carga de trabalho. Esse processo é mais confiável do que simplesmente atribuir um número grande e presumir que o problema está resolvido.