Comment augmenter la limite de mémoire d'un conteneur CODE Collabora Online

Si un conteneur Collabora Online Development Edition (CODE) est arrêté brutalement en raison d'une charge importante ou s'il atteint constamment sa limite de mémoire Docker, la solution consiste généralement à augmenter cette limite, et non à modifier un paramètre de Collabora. Docker applique les limites de mémoire au niveau de l'exécution du conteneur, et Collabora s'exécute dans ces limites.

Ce guide utilise un exemple purement hypothétique : imaginez une petite équipe exécutant un conteneur codesur un hôte Docker Linux. Ce conteneur dispose d'une limite de mémoire de 2 Gio, et lors des périodes de forte activité, cette limite est presque atteinte. L'équipe décide alors de tester une limite de 4 Gio tout en conservant suffisamment de RAM disponible pour le système d'exploitation et les autres services. Les chiffres et les valeurs d'utilisation présentés dans cet exemple sont donnés à titre indicatif et ne correspondent pas à des résultats mesurés lors d'un déploiement réel.

En octobre 2026, les commandes ci-dessous sont conformes à la documentation Docker en vigueur. La documentation Docker de Collabora indique que l'image CODE est une option Collabora Online déployée via Docker ; Docker est le composant qui applique les limites de ressources des conteneurs. Veuillez vous référer à la documentation Docker officielle de Collabora Online CODE et à la documentation relative aux contraintes de ressources de Docker pour adapter ces étapes à votre environnement.

Ce que change concrètement l'augmentation de la limite de mémoire

La limite de mémoire Docker plafonne la quantité de RAM qu'un conteneur peut utiliser. L'augmenter offre à CODE une plus grande marge de manœuvre avant que le conteneur ne rencontre une saturation de la mémoire. Cela ne réserve pas la totalité de cette quantité à l'avance et ne garantit pas une accélération de l'édition de documents. La saturation du processeur, la latence du stockage, les conditions du réseau, la complexité des documents, le nombre d'utilisateurs simultanés et le comportement de l'application peuvent toujours constituer des goulots d'étranglement.

La documentation Docker --memory(ou -m) définit la limite de mémoire vive du conteneur. Docker propose également `swap` --memory-swap, qui contrôle la somme de la RAM et du swap allouée lorsqu'une limite de mémoire est définie. Le swap peut servir de marge de manœuvre, mais des échanges fréquents ont un impact sur les performances. Pour un service de traitement de texte, il est déconseillé de considérer le swap comme un substitut à une mémoire physique suffisante.

Étape 1 : Confirmer que la pression sur la mémoire est le véritable problème

Commencez par identifier le conteneur CODE en cours d'exécution et observez son utilisation actuelle des ressources :

docker ps
docker stats code

Dans ce scénario hypothétique, docker statsle codeconteneur utilise environ 1,8 Gio sur une limite de 2,0 Gio. Cela justifierait une investigation plus approfondie, mais un simple instantané ne suffit pas à justifier une modification permanente. Surveillez l'utilisation pendant la charge de travail à l'origine des défaillances et examinez les journaux du conteneur pour détecter d'éventuels signes d'arrêt ou de redémarrage.

Une règle de décision utile est simple : si le conteneur atteint régulièrement sa limite maximale configurée, et que les utilisateurs constatent des échecs de session, des redémarrages ou des erreurs de mémoire insuffisante, augmenter cette limite constitue une piste raisonnable. En revanche, si la mémoire reste largement en dessous de cette limite, il est peu probable que la modifier résolve le problème sous-jacent.

Étape 2 : Lire la limite de mémoire Docker configurée

Vérifiez directement la valeur de mémoire configurée du conteneur :

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

Docker affiche cette valeur en octets. Par exemple, 21474836482 Gio équivalent à 2 Gio. Vous pouvez la convertir manuellement ou à l'aide d'opérations en ligne de commande :

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

Si la valeur d'inspection est nulle 0, Docker considère généralement que le conteneur n'a pas de limite de mémoire stricte explicite. Dans ce cas, une insuffisance de mémoire au niveau de l'hôte, un autre orchestrateur ou une autre contrainte peuvent être la véritable cause. Docker précise que les conteneurs n'ont pas de contraintes de ressources par défaut, sauf si des limites sont configurées.

Étape 3 : Augmenter la limite d’un conteneur Linux existant

Docker permet de modifier la limite de mémoire d'un conteneur existant docker update. Prenons l'exemple d'une modification de 2 Gio à 4 Gio :

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

Définir --memory-swapcette valeur sur la même valeur --memoryempêche ce conteneur d'utiliser le swap conformément aux règles de swap de mémoire documentées par Docker. Si votre politique opérationnelle autorise le swap, choisissez une valeur spécifique plutôt que de copier cet exemple. Par exemple, une --memory-swapvaleur plus élevée autorise un swap au-delà de la limite de RAM, tandis qu'une valeur plus faible -1autorise un swap illimité dans la limite du swap disponible sur l'hôte.

La documentation actuelle de Docker concernant la mise à jour des conteneurs indique que `docker container update`--memory , --memory-reservation`docker container update` et `docker container --memory-swapupdate` sont des paramètres modifiables. Docker précise également que `docker docker updatecontainer update` n'est pas pris en charge pour les conteneurs Windows ; les déploiements CODE utilisent généralement un conteneur Linux, mais cette distinction est importante si vous adaptez la commande ailleurs.

Après la mise à jour, vérifiez la configuration et l'état d'exécution :

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

N'interprétez pas une baisse du pourcentage après la modification comme la preuve que le service a désormais besoin de moins de RAM. Le pourcentage diminue car le dénominateur est plus grand. Ce qui importe, c'est de savoir si le conteneur reste stable sous la charge de travail qui, auparavant, entraînait une saturation de la mémoire.

Étape 4 : Rendre la modification permanente dans Docker Compose

Si le conteneur est géré par Docker Compose, mettez à jour la configuration Compose, qui fait foi. Sinon, une recréation ultérieure du service pourra rétablir l'ancienne limite ou supprimer la modification d'exécution.

Pour les versions modernes de Docker Compose, la mem_limitpropriété de niveau de service définit la quantité de mémoire que le conteneur peut allouer :

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

La documentation de Docker Compose concernant la propriété `mem_limit` indique qu'elle mem_limitconfigure la limite de mémoire d'un conteneur de service. Compose prend également en charge les limites de ressourcesdeploy.resources.limits.memory ; si vous utilisez les deux, Docker précise que leurs valeurs de mémoire doivent être cohérentes.

Appliquer la configuration :

docker compose up -d

Vérifiez ensuite le service recréé ou redémarré :

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

Quelle quantité de mémoire devez-vous allouer ?

Il n'existe pas de limite unique et sûre pour toutes les installations de CODE. La limite appropriée dépend du nombre d'éditeurs simultanés, de la taille et de la complexité des documents, de la capacité de l'hôte, des autres conteneurs et du mode d'intégration du service. Le manuel du SDK de Collabora inclut des exemples de configurations de ressources Kubernetes, dont un exemple orienté production avec des demandes et des limites de mémoire de plusieurs gigaoctets, mais celui-ci ne doit pas être considéré comme une formule universelle de dimensionnement Docker.

Pour un serveur hypothétique, le passage de 2 Gio à 4 Gio doit être considéré comme une modification de capacité maîtrisée. L'équipe doit s'assurer que l'hôte dispose de suffisamment de RAM libre pour absorber le pic d'utilisation sans saturer la mémoire des autres services critiques. Sur un hôte avec peu de RAM disponible, augmenter la limite CODE peut simplement déplacer la défaillance du conteneur vers l'hôte.

Un processus de dimensionnement pratique

• Enregistrez la limite actuelle et la consommation de pointe pendant des périodes de forte affluence représentatives.
• Augmenter la limite progressivement plutôt que de la rendre pratiquement illimitée.
• Prévoyez une marge de manœuvre pour le système d'exploitation hôte, le proxy inverse, Nextcloud ou d'autres services d'intégration, les bases de données et les agents de surveillance.
• Répétez la charge de travail et observez la consommation réelle de mémoire, les redémarrages des conteneurs et les défaillances visibles par l'utilisateur.
• Si l'utilisation continue d'augmenter jusqu'à chaque nouvelle limite, étudiez le comportement de l'application, documentez les tendances et les journaux au lieu d'ajouter de la RAM de manière répétée.

Qu’en est-il de la réservation et de l’échange de mémoire ?

Docker distingue une limite de mémoire stricte d'une réservation de mémoire souple. Une réservation peut influencer le comportement en cas de contention de l'hôte, tandis que la limite stricte représente le plafond absolu. Pour de nombreuses configurations CODE sur un seul hôte, il est plus simple de commencer par une limite stricte explicite. N'ajoutez une réservation que si vous avez une politique de partage des ressources clairement définie au niveau de l'hôte.

L'espace d'échange (swap) mérite une attention particulière. La documentation Docker explique que, --memory-swaplorsqu'il est défini sur une valeur positive, il représente la mémoire totale plus l'espace d'échange. Si `<valeur>` --memory=4get ` <valeur>` sont égaux --memory-swap=6g, le conteneur peut utiliser jusqu'à 4 Gio de RAM et jusqu'à 2 Gio d'espace d'échange supplémentaires. Cela peut éviter une panne brutale dans certaines situations, mais une activité d'échange soutenue peut ralentir l'édition interactive. Il est donc plus sûr de surveiller l'espace d'échange plutôt que de supposer qu'une plus grande quantité est automatiquement suffisante.

Comment savoir si le changement a fonctionné

Le succès ne se résume pas à voir 4 GiBà l'intérieur docker stats. Les signes significatifs sont opérationnels :

• La limite configurée et signalée docker inspectcorrespond à la valeur prévue.
• Le conteneur reste sous le nouveau plafond pendant la charge de travail qui causait auparavant des problèmes.
• Les redémarrages inattendus ou les pannes liées à une erreur de mémoire insuffisante cessent de se produire dans des conditions comparables.
• L'hôte Docker conserve une marge de mémoire suffisante et ne commence pas à utiliser intensivement la fonction swap.
• L'édition reste réactive et ne se contente pas d'éviter l'arrêt du système.

Si le conteneur continue de dysfonctionner bien en deçà de la nouvelle limite, changez de stratégie. Examinez docker logs codeles journaux du noyau hôte, les erreurs du proxy inverse, les journaux du serveur d'intégration et la saturation du processeur ou des E/S. La limite de mémoire ne représente qu'un aspect du déploiement Collabora.

Erreurs courantes à éviter

• Modifier uniquement le conteneur en cours d'exécution docker update peut résoudre la limite immédiate, mais les services gérés par Compose doivent également être mis à jour dans le fichier Compose.
• Allouer toute la mémoire hôte à CODE : l'hôte et les services voisins ont besoin de marge de manœuvre. Un conteneur sans restriction peut contribuer à l'instabilité de l'ensemble du système hôte.
• En supposant que la mémoire d'échange soit de la mémoire libre : la mémoire d'échange est plus lente que la RAM, et Docker avertit explicitement d'une perte de performance lorsque les applications utilisent fréquemment la mémoire d'échange.
• Confusion entre la mémoire du conteneur et la mémoire PHP : la limite du conteneur Docker CODE est distincte des paramètres PHP utilisés par des applications telles que Nextcloud.
• Utiliser un seul instantané comme preuve : mesurer pendant une période de demande représentative et comparer le comportement avant et après le changement.

En résumé

Pour augmenter la limite de mémoire d'un conteneur Collabora Online CODE, vérifiez d'abord que la limite Docker existante est effectivement atteinte. Pour un conteneur Linux existant, docker update --memory ...vous pouvez modifier cette limite à l'exécution. Pour un déploiement géré par Compose, conservez la limite via mem_limitune configuration de ressources Compose cohérente, puis recréez ou mettez à jour le service et vérifiez le résultat.

L'exemple hypothétique d'une augmentation de 2 Gio à 4 Gio est utile car il illustre le cycle de décision complet : observation de la pression, confirmation de la limite configurée, augmentation volontaire de cette limite, enregistrement de la configuration et validation sous la même charge de travail. Ce processus est plus fiable que la simple attribution d'une valeur élevée et la supposition que le problème est résolu.