Cómo aumentar el límite de memoria para un contenedor de código de Collabora Online

Si un contenedor de Collabora Online Development Edition (CODE) se cierra debido a la carga o se ejecuta constantemente cerca del límite de memoria de Docker, la solución práctica suele ser aumentar el límite de memoria de Docker del contenedor, no modificar ninguna configuración dentro de Collabora. Docker aplica los límites de memoria a nivel de tiempo de ejecución del contenedor, y Collabora se ejecuta dentro de ese límite.

Esta guía utiliza un ejemplo claramente hipotético: imaginemos un pequeño equipo ejecutando un contenedor codeen un host Docker Linux. El contenedor tiene un límite de memoria de 2 GiB, y durante los periodos de edición más intensos, se acerca a dicho límite. El equipo decide probar un límite de 4 GiB, manteniendo suficiente RAM disponible para el sistema operativo y otros servicios. Las cifras y los valores de utilización de este ejemplo son ilustrativos y no representan resultados reales de una implementación.

A partir de octubre de 2026, los comandos que se muestran a continuación coinciden con la documentación actual de Docker. La documentación de Docker de Collabora identifica la imagen CODE como una opción de Collabora Online implementada con Docker; Docker es el componente que aplica los límites de recursos del contenedor. Consulte la documentación oficial de Docker para Collabora Online CODE y la documentación sobre restricciones de recursos de Docker al adaptar los pasos a su entorno.

¿Qué cambia realmente al aumentar el límite de memoria?

El límite de memoria de Docker establece un tope para la cantidad de RAM que puede usar un contenedor. Aumentarlo le da a CODE más margen de maniobra antes de que el contenedor experimente problemas de memoria o se quede sin memoria. No reserva toda la cantidad por adelantado ni garantiza que la edición de documentos sea más rápida. La saturación de la CPU, la latencia del almacenamiento, las condiciones de la red, la complejidad del documento, los usuarios concurrentes y el comportamiento de la aplicación aún pueden ser cuellos de botella.

Docker documenta --memory(o -m) como el límite de memoria del contenedor. Docker también proporciona --memory-swap, que controla la asignación combinada de RAM y swap cuando se establece un límite de memoria. El swap puede proporcionar un margen, pero el intercambio frecuente tiene un costo de rendimiento. Para un servicio de edición de oficina, evite usar swap como sustituto de una memoria física adecuada.

Paso 1: Confirmar que la presión sobre la memoria es el verdadero problema.

Comience por identificar el contenedor CODE en ejecución y observar su uso actual de recursos:

docker ps
docker stats code

En el escenario hipotético, docker statsse observa que el codecontenedor utiliza aproximadamente 1,8 GiB de un límite de 2,0 GiB. Esto justificaría una investigación más exhaustiva, pero una sola instantánea no es suficiente para justificar un cambio permanente. Supervise el uso durante la carga de trabajo que provoca fallos e inspeccione los registros del contenedor en busca de síntomas de terminación o reinicio.

Una regla de decisión útil es simple: si el contenedor se acerca repetidamente a su límite configurado al mismo tiempo que los usuarios experimentan fallos de sesión, reinicios o eventos relacionados con la falta de memoria, aumentar el límite es una prueba razonable. Si la memoria se mantiene cómodamente por debajo del límite, es poco probable que cambiarlo resuelva el problema subyacente.

Paso 2: Lea el límite de memoria de Docker configurado.

Compruebe directamente el valor de memoria configurado del contenedor:

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

Docker informa este valor en bytes. Por ejemplo, 2147483648bytes equivalen a 2 GiB. Puedes convertirlo manualmente o con aritmética de shell:

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

Si el valor de inspección es 0, Docker normalmente trata al contenedor como si no tuviera un límite de memoria estricto explícito. En ese caso, la causa real podría ser una escasez a nivel del host, otro orquestador o una restricción diferente. Docker indica que los contenedores no tienen restricciones de recursos por defecto, a menos que se configuren límites.

Paso 3: Aumentar el límite en un contenedor Linux existente.

Docker admite cambiar el límite de memoria de un contenedor existente con docker update. Para el cambio hipotético de 2 GiB a 4 GiB:

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

Si se establece --memory-swapel mismo valor, --memoryse impide que ese contenedor utilice el espacio de intercambio (swap) según las reglas de intercambio de memoria documentadas por Docker. Si su política operativa permite el intercambio, elija un valor específico en lugar de copiar este ejemplo. Por ejemplo, un --memory-swapvalor mayor permite cierto espacio de intercambio más allá del límite de RAM, mientras que -1permite un intercambio ilimitado sujeto al espacio de intercambio disponible del host.

La documentación actual de Docker sobre la actualización de contenedores enumera --memory, --memory-reservation, y --memory-swapcomo configuraciones actualizables. Docker también señala que docker updateno es compatible con contenedores de Windows; las implementaciones de CODE normalmente usan un contenedor de Linux, pero esa distinción importa si está adaptando el comando en otro lugar.

Tras la actualización, verifique tanto la configuración como el estado de ejecución:

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

No interprete un porcentaje menor tras el cambio como prueba de que el servicio ahora necesita menos RAM. El porcentaje disminuye porque el denominador es mayor. Lo que importa es si el contenedor se mantiene estable bajo la carga de trabajo que antes le generaba problemas de memoria.

Paso 4: Haz que el cambio sea persistente en Docker Compose.

Si el contenedor se gestiona mediante Docker Compose, actualice la configuración de Compose como fuente de información principal. De lo contrario, una futura recreación del servicio puede restaurar el límite anterior o eliminar el cambio que solo se aplicó en tiempo de ejecución.

En Docker Compose moderno, la mem_limitpropiedad de nivel de servicio establece la cantidad de memoria que el contenedor puede asignar:

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

La documentación de Docker Compose sobre `mem_limit` establece que mem_limitconfigura el límite de memoria para un contenedor de servicio. Compose también admite límites de recursos deploy.resources.limits.memory; si se utilizan ambas formas, Docker indica que sus valores de memoria deben ser consistentes.

Aplicar la configuración:

docker compose up -d

A continuación, verifique el servicio recreado o reiniciado:

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

¿Cuánta memoria debería asignar?

No existe un límite único y seguro para todas las instalaciones de CODE. El límite adecuado depende de los editores concurrentes, el tamaño y la complejidad de los documentos, la capacidad del servidor, otros contenedores y la forma en que se integra el servicio. El manual del SDK actual de Collabora incluye ejemplos de configuraciones de recursos de Kubernetes, incluido un ejemplo orientado a la producción con solicitudes y límites de memoria de varios gigabytes, pero esto no debe considerarse una fórmula universal para dimensionar Docker.

Para el servidor hipotético, pasar de 2 GiB a 4 GiB se trata mejor como un cambio de capacidad controlado. El equipo debe confirmar que el host tiene suficiente RAM libre para absorber el pico de uso sin sobrecargar otros servicios críticos. En un host con poca RAM disponible, aumentar el límite de CODE puede simplemente trasladar el fallo del contenedor al host.

Un proceso práctico de dimensionamiento

• Registre el límite actual y el uso máximo durante los períodos de mayor actividad representativos.
• Aumentar el límite de forma gradual, en lugar de hacerlo prácticamente ilimitado.
• Deje margen para el sistema operativo anfitrión, el proxy inverso, Nextcloud u otros servicios de integración, bases de datos y agentes de monitorización.
• Repita la carga de trabajo y observe el consumo real de memoria, los reinicios de los contenedores y los fallos visibles para el usuario.
• Si el uso sigue aumentando hasta alcanzar cada nuevo límite, investigue el comportamiento de la aplicación, documente los patrones y los registros en lugar de añadir RAM repetidamente.

¿Qué ocurre con la reserva y el intercambio de memoria?

Docker distingue entre un límite de memoria estricto y una reserva de memoria flexible. Una reserva puede influir en el comportamiento cuando el host está bajo contención, mientras que el límite estricto representa el tope absoluto. Para muchas configuraciones de CODE en un solo host, comenzar con un límite estricto explícito facilita el análisis. Agregue una reserva solo cuando tenga una política clara de uso compartido de recursos a nivel de host.

El intercambio de memoria (swap) requiere especial precaución. La documentación de Docker explica que --memory-swaprepresenta la memoria total más el intercambio cuando se establece en un valor positivo. Si --memory=4gy --memory-swap=6g, el contenedor puede usar hasta 4 GiB de RAM y hasta 2 GiB de intercambio adicional. Esto puede evitar fallos repentinos en algunas situaciones, pero la actividad sostenida del intercambio puede ralentizar la edición interactiva. Es mejor monitorizarlo que asumir que un mayor intercambio es automáticamente más seguro.

Cómo saber si el cambio funcionó

El éxito no consiste simplemente 4 GiBen ver docker stats. Las señales significativas son operativas:

• El límite configurado que se muestra docker inspectcoincide con el valor previsto.
• El contenedor permanece por debajo del nuevo techo durante la carga de trabajo que anteriormente causaba problemas.
• Los reinicios inesperados o los fallos relacionados con la falta de memoria dejan de producirse en condiciones similares.
• El host de Docker aún conserva un margen de memoria adecuado y no comienza a utilizar el intercambio de memoria de forma intensiva.
• La edición sigue siendo receptiva en lugar de simplemente evitar la terminación.

Si el contenedor sigue fallando muy por debajo del nuevo límite, cambie de estrategia. Revise docker logs codelos registros del kernel del host, los errores del proxy inverso, los registros del servidor de integración y la saturación de la CPU o de E/S. Un límite de memoria es solo una capa de una implementación de Collabora.

Errores comunes que se deben evitar

• Modificar únicamente el contenedor en ejecución docker update puede solucionar el problema inmediato, pero los servicios gestionados por Compose también deben actualizarse en el archivo Compose.
• Asignar a CODE toda la memoria del host: el host y los servicios vecinos necesitan margen de maniobra. Un contenedor sin restricciones puede contribuir a la inestabilidad de todo el host.
• Suponiendo que el intercambio es memoria libre: el intercambio es más lento que la RAM, y Docker advierte explícitamente de una penalización en el rendimiento cuando las aplicaciones realizan intercambios frecuentes.
• Confundir la memoria del contenedor con la memoria de PHP: el límite del contenedor Docker CODE es independiente de la configuración de PHP utilizada por aplicaciones como Nextcloud.
• Utilizando una sola instantánea como evidencia: mida durante un período de demanda representativo y compare el comportamiento antes y después del cambio.

En resumen

Para aumentar el límite de memoria de un contenedor Collabora Online CODE, primero verifique que se esté alcanzando el límite de Docker existente. En el caso de un contenedor Linux existente, docker update --memory ...puede modificar el límite en tiempo de ejecución. Para una implementación gestionada por Compose, mantenga el límite con mem_limituna configuración de recursos de Compose consistente, luego recree o actualice el servicio y verifique el resultado.

El ejemplo hipotético de 2 GiB a 4 GiB resulta útil porque muestra el ciclo de decisión completo: observar la presión, confirmar el límite configurado, aumentarlo deliberadamente, mantener la configuración y validarla bajo la misma carga de trabajo. Este proceso es más fiable que simplemente asignar un número grande y asumir que el problema está resuelto.