Empêcher le serveur de documents ONLYOFFICE de manquer de mémoire VPS

Si ONLYOFFICE Document Server se bloque ou redémarre en raison d'une saturation de la mémoire de votre VPS, commencez par confirmer l'incident de mémoire insuffisante et vérifiez si la limite de mémoire Docker est suffisante. Ensuite, allouez suffisamment de RAM physique pour la charge de travail et n'ajoutez de la mémoire d'échange qu'à titre de sécurité ; redémarrer l'éditeur à plusieurs reprises ne résoudra pas un problème de capacité persistante.

1. Démontrer que la pression sur la mémoire est à l'origine de l'échec

Commencez par les paramètres du VPS Linux, et non ceux de l'intégration ONLYOFFICE. Un message d'erreur tel que « Impossible de charger le document » peut également être dû à un problème de réseau ou d'authentification. Il est donc important de vérifier si le processus a bien été interrompu par le mécanisme de gestion de la mémoire insuffisante (OOM) de Linux.

Exécutez ces commandes via SSH. Remplacez onlyoffice-document-serverpar le nom du conteneur affiché par docker ps -a:

free -h
docker ps -a
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' onlyoffice-document-server

free -hAffiche la RAM et le swap disponibles sur l'hôte. docker statsMesure la mémoire d'un conteneur en cours d'exécution, tandis que la commande `inspect` indique son état (arrêté par manque de mémoire), son dernier code de sortie et ses limites de ressources configurées en octets. Une HostConfig.Memoryvaleur différente de zéro indique une limite de mémoire explicite. Les statistiques de mémoire de Docker peuvent exclure certains caches de fichiers ; il convient donc de les comparer aux mesures de l'hôte plutôt que de les considérer comme exhaustives. Consultez la documentation de référence des statistiques Docker .

Si le conteneur est arrêté, docker statsil est impossible d'afficher son pic précédent. Consultez plutôt le journal du noyau et les messages récents des applications :

sudo journalctl -k --since "-2 hours" | grep -Ei 'out of memory|killed process|oom'
docker logs --tail 100 onlyoffice-document-server

Les messages du noyau mentionnant « Mémoire insuffisante » ou « Processus arrêté » permettent d'identifier le processus concerné. OOMKilled=trueIls constituent un indice fort d'une erreur de mémoire insuffisante (OOM) du conteneur, mais falsen'excluent pas la possibilité que le noyau hôte ait arrêté un processus enfant alors que le conteneur reste actif. De même, le code de sortie 137 indique uniquement un arrêt suite à un signal SIGKILL, et non sa cause. En l'absence de preuve d'une erreur de mémoire insuffisante, il est conseillé d'examiner les journaux et les erreurs de connexion avant d'ajouter de la mémoire vive.

2. Allouez suffisamment de RAM au VPS avant de régler quoi que ce soit d'autre.

En octobre 2026, le fichier README officiel du serveur de documents Docker d'ONLYOFFICE recommandait au moins 4 Go de RAM et 2 Go de swap. La documentation officielle de l'installateur en un clic, quant à elle , préconisait 4 Go de RAM pour les environnements de test Docker, 8 Go ou plus pour la production, et au moins 4 Go de swap. Ces documents décrivant des contextes de déploiement différents, 4 Go de RAM ne constituent pas une garantie de performances fiables en production.

Si votre VPS ne dispose que de 1 à 2 Go de RAM, la mise à niveau de son forfait est la solution la plus judicieuse pour une installation Docker. S'il possède déjà 4 Go, vérifiez la consommation de mémoire du système d'exploitation, de la base de données, du proxy inverse, de Nextcloud et des autres conteneurs. Un serveur qui semble fonctionner correctement en veille peut se retrouver à court de mémoire lorsque plusieurs utilisateurs ouvrent des documents ou convertissent simultanément de grands tableurs.

Sur un serveur très sollicité, utilisez cette méthode ps aux --sort=-rss | headpour identifier les processus gourmands en mémoire et répétez l'opération docker statslors d'une session d'édition représentative. Réservez de la mémoire vive pour le reste de la machine au lieu d'allouer toute la RAM disponible à ONLYOFFICE. Si la demande continue dépasse la capacité du serveur, déplacez les services concurrents ou mettez à niveau votre VPS ; une modification au niveau de l'application ne peut pas créer de mémoire physique manquante.

Vérifiez si une limitation de mémoire Docker est accidentellement appliquée.

Par défaut, les conteneurs Docker n'ont pas de limite de mémoire stricte, mais une configuration peut être définie lors du déploiement, notamment avec `docker run` ou --memory`compose` mem_limit. Par exemple, une limite de 2 Go peut entraîner des erreurs de type « mémoire insuffisante » (OOM) même si l'hôte dispose de 8 Go de RAM libre. Il est donc important de vérifier la limite réelle avant de la modifier. Si elle est trop basse, ajustez la configuration Docker ou Compose d'origine à une valeur justifiée par des mesures et la capacité restante de l'hôte. Consultez la documentation de Docker sur les contraintes de ressources et la spécification du service Compose .

N'allouez pas aveuglément une mémoire illimitée à un VPS partagé : cela peut exposer d'autres services à des erreurs de mémoire insuffisante (OOM) affectant l'ensemble de l'hôte. Vérifiez également --memory-swaples paramètres de Composememswap_limit ; Docker comptabilise la RAM et le swap combinés dans ce paramètre. Des limites égales pour la RAM et le swap combinés désactivent de fait le swap pour le conteneur. Si vous gérez ONLYOFFICE avec Compose, modifiez le fichier Compose correspondant afin que le paramètre soit conservé lors de la recréation du conteneur.

3. Ajoutez une mémoire tampon d'échange si le VPS n'en possède pas.

Le swap peut absorber un pic temporaire de consommation de mémoire, mais il est stocké sur disque et est beaucoup plus lent que la RAM. Vérifiez swapon --showd' df -h /abord. L'exemple suivant ajoute un fichier de swap de 2 Gio à un VPS utilisant un système de fichiers local compatible tel que ext4, lorsqu'il /swapfilen'existe pas déjà et que le fournisseur autorise le swap :

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h

Ne rendez le nouveau fichier d'échange persistant qu'après swaponla réussite de l'opération. Vérifiez s'il existe déjà une entréegrep -F '/swapfile' /etc/fstab ; si aucune n'existe, ajoutez-la une seule fois :

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

La création de fichiers d'échange sur Btrfs, les systèmes de fichiers réseau et certaines autres configurations nécessite une procédure différente. N'exécutez pas ces commandes sur un fichier d'échange existant et ne présumez pas fallocatequ'elles fonctionnent partout. Le manuel de la commande `swapon` sous Linux explique les restrictions liées au système de fichiers. Si le VPS utilise régulièrement l'échange de données lors d'une charge d'édition normale, privilégiez l'augmentation de la RAM plutôt que la taille du fichier d'échange.

4. Vérifiez à nouveau le serveur sous une charge de travail d'édition réaliste.

Changer de forfait VPS ou activer le swap ne nécessite généralement aucune modification de la configuration ONLYOFFICE. Si vous avez modifié un paramètre de déploiement Docker, planifiez une maintenance et veillez à conserver les points de montage, les secrets, les chemins de certificats et les paramètres d'intégration existants lors de l'application de la modification. Le fichier README de ONLYOFFICE Docker documente documentserver-prepare4shutdown.shles arrêts planifiés et indique que la déconnexion des éditeurs peut prendre plusieurs minutes. Ne recréez pas et ne redémarrez pas un serveur de documents en cours d'utilisation sans précaution, car les modifications non enregistrées pourraient être affectées.

Une fois le service prêt, vérifiez que le conteneur est en cours d'exécution et inspectez à nouveau sa mémoire :

docker ps --filter name=onlyoffice-document-server
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}}' onlyoffice-document-server
docker exec onlyoffice-document-server curl -fsS http://localhost:8000/info/info.json

La dernière vérification utilise le point de terminaison d'informations internes indiqué dans le contrôle d'intégrité officiel ONLYOFFICE Docker Compose ; exécutez-la à l'intérieur du conteneur car le port 8000 peut ne pas être ouvert sur le VPS. La réponse du point de terminaison indique la disponibilité du service, mais pas nécessairement le bon fonctionnement de chaque intégration de stockage ou rappel de sauvegarde.

Vérifiez que le problème de mémoire est résolu.

Rouvrez un petit document, puis un document volumineux représentatif via votre instance Nextcloud, ownCloud ou autre intégration. Enregistrez une modification sans conséquence et vérifiez qu'elle apparaît bien après la réouverture du fichier. Surveillez free -hles docker statsjournaux OOM (mémoire insuffisante) du noyau pendant la période d'utilisation qui a précédemment provoqué des erreurs.

Une solution efficace signifie que les documents continuent de s'ouvrir et de s'enregistrer normalement, que l'utilisation de la mémoire reste dans les limites du VPS et du conteneur, et qu'aucun nouvel incident de type « mémoire insuffisante » (OOM) ne se produit. Si les plantages cessent uniquement en période de faible activité, le VPS manque encore de marge pour les pics d'utilisation ; dimensionnez la RAM en conséquence plutôt que de vous fier à un échange continu de données. Si la RAM reste disponible et qu'aucun nouveau message OOM n'apparaît, mais que les documents continuent de planter, concentrez vos investigations sur les journaux ONLYOFFICE, le proxy inverse ou votre connecteur de stockage au lieu de modifier davantage la mémoire.