Une utilisation élevée du processeur par coolwsdun processus ancien loolwsdn'est pas forcément synonyme d'erreur : Collabora crée des processus de traitement de documents, et l'ouverture ou la modification de fichiers complexes peut consommer des ressources processeur. Commencez par identifier le processus qui consomme le plus de ressources, puis associez-le aux documents ouverts et aux utilisateurs dans la console d'administration. Si un document monopolise un processus lorsqu'il est inactif, consultez les journaux et les paramètres de nettoyage avant toute intervention ; l'arrêt brutal des processus peut interrompre l'édition en cours.
Les installations récentes utilisent le coolwsdnom ; les installations plus anciennes peuvent encore afficher l'ancien nom loolwsd. Les notes de mise à niveau de Collabora 21.11 décrivent la migration unique de l'ancien nom /etc/loolwsd/loolwsd.xmlvers le nouveau /etc/coolwsd/coolwsd.xml. Veillez à utiliser les noms de service et de configuration installés sur votre hôte au lieu de supposer que chaque déploiement est identique.
Sur un hôte systemd, vérifiez le service puis listez les processus par utilisation du processeur :
systemctl status coolwsd
ps -eo pid,ppid,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20
Si le service est nommé `<nom_du_service>` loolwsd, remplacez ce nom dans la commande `systemctl`. Analysez plusieurs relevés sur une période donnée avec `<commande_de_l'outil top>` plutôt que de considérer un pic ponctuel comme un problème persistant. Examinez l'arborescence des processus : le processeur peut être utilisé par les processus de travail de documentation sous le démon, et non par le processus parent lui-même. Sous Docker, vérifiez le total du conteneur avec docker stats --no-stream CONTAINER_NAME`<commande_de_l'outil>` ; sous Kubernetes, utilisez les métriques de ressources du pod pertinentes. Ces relevés concernent des périmètres différents ; comparez donc attentivement les valeurs de l'hôte, du conteneur et des processus de travail.
Connectez-vous à la console d'administration de Collabora et consultez les utilisateurs connectés, les documents ouverts, l'utilisation des ressources et les graphiques récents. La FAQ officielle de Collabora décrit ces fonctionnalités de surveillance. Si la charge augmente pendant l'ouverture ou la conversion d'une feuille de calcul, d'une présentation, d'un PDF ou d'un document volumineux, observez si elle diminue une fois l'opération terminée. Un pic temporaire lié à une charge de travail réelle nécessite une planification des capacités ou une réduction de la charge ; il ne constitue pas en soi la preuve d'un emballement du processus.
Si un document continue de consommer beaucoup de ressources processeur après sa fermeture par l'utilisateur, vérifiez qu'aucune session de navigateur ni intégration ne le maintient ouvert. Notez l'identifiant du document affiché dans la console, l'ID du processus, la durée, la mémoire utilisée et si le fichier était actif ou inactif. Évitez de mentionner des noms de documents personnels ou confidentiels dans les demandes d'assistance publiques.
Comparez le démon avec ses processus enfants ; le processus le plus actif n'est pas forcément le parent coolwsd.
Corrélez l'historique du processeur avec les utilisateurs actifs et les documents avant de modifier les paramètres du serveur.
Pour une installation systemd basée sur des paquets, examinez les messages de service récents :
journalctl -u coolwsd --since "15 minutes ago"
Utilisez cette commande loolwsdsi c'est le nom du service sur votre système. Surveillez les erreurs répétées de chargement ou de conversion de documents, les redémarrages des processus et les messages indiquant une augmentation de l'utilisation du processeur. Si votre déploiement écrit dans un fichier plutôt que dans le journal système, utilisez la destination de journalisation configurée. Pour les conteneurs, consultez les journaux du conteneur Collabora à l'aide de la commande `log` de votre environnement d'exécution. L'emplacement pertinent et les messages disponibles varient selon la méthode d'installation et la version.
Une erreur répétée liée à un seul fichier suggère d'isoler une copie de ce fichier et de vérifier si le même problème se reproduit. Une augmentation généralisée touchant plusieurs documents indique plutôt un problème de concurrence ou de capacité du serveur. Si les journaux signalent un défaut connu, mettez à jour Collabora via le canal officiel de votre installation ; consultez les notes de version de votre édition et de votre version plutôt que d'appliquer une solution de contournement non pertinente.
Le schéma de configuration de Collabora définit per_document.max_concurrencyle nombre maximal de threads utilisés lors du traitement d'un document. Le modèle de configuration officiel actuel de coolwsd documente également les contrôles de nettoyage des documents inactifs et dont les ressources dépassent les seuils configurés. Les valeurs par défaut et les champs disponibles peuvent varier selon la version ; consultez donc la coolwsd.xmlconfiguration fournie avec votre version installée avant d'apporter des modifications.
Réduire ce paramètre max_concurrencypeut limiter l'utilisation du processeur par un document, mais risque de ralentir l'édition, le chargement ou la conversion. Il ne s'agit pas d'une limite quant au nombre d'utilisateurs ou de documents. Ne le modifiez qu'après avoir analysé la charge de travail par document, en effectuant un ajustement à la fois et en comparant le temps de réponse et l'utilisation du processeur sous une charge de travail représentative. Ne copiez pas directement un extrait de code d'une autre version en production sans avoir validé sa structure et les paramètres pris en charge.
La configuration de nettoyage vise à identifier les documents gourmands en ressources restés inactifs pendant une période définie et, si les conditions sont toujours remplies, à interrompre le processus du document associé. Il ne s'agit pas d'une limitation générale du processeur et elle ne résout pas les problèmes d'utilisation du processeur liés à l'édition active ou aux conversions répétées. Vérifiez son activation et ses seuils par rapport à votre configuration installée ; une politique trop restrictive pourrait fermer une session dont les utilisateurs ont encore besoin. Sauvegardez la configuration et prévoyez un redémarrage contrôlé du service si votre modification l'exige.
Comparez l'état du service avec les messages de journalisation récents pour voir si la hausse de l'utilisation du processeur coïncide avec des erreurs ou des redémarrages de processus.
Vérifiez le schéma de la version installée avant de modifier les seuils de concurrence ou de nettoyage.
Si l'utilisation du processeur reste élevée sans document actif, persiste après un redémarrage contrôlé ou coïncide avec des plantages répétés, veuillez collecter la version de Collabora, la méthode d'installation, les journaux de service/conteneur, l'arborescence des processus et les détails anonymisés des documents pour le responsable de la maintenance ou le fournisseur. Évitez de supprimer systématiquement les processus enfants : Collabora gère ces processus et leur arrêt manuel peut perturber les utilisateurs sans résoudre le problème sous-jacent.
Vérifiez si Docker limite la mémoire de Collabora CODE, augmentez la limite de mémoire de Compose en toute sécurité et confirmez que le conteneur en cours d'exécution a bien reçu la nouvelle limite.
Simplifiez Collabora CODE grâce au mode Compact ou à onglets et aux contrôles WOPI PostMessage pour masquer en toute sécurité les boutons, commandes et onglets sélectionnés.
Confiez la gestion du HTTPS à Nginx pour un conteneur Collabora CODE, configurez correctement l'édition des WebSockets et vérifiez le point de terminaison public sans exposer le port 9980.
Dépannage des problèmes de masquage du texte par le clavier d'un navigateur mobile dans Collabora Online, avec des solutions de contournement rapides et des vérifications distinctes pour les navigateurs, les WebViews intégrées et les pages hôtes.
Définissez des limites d'impression et de téléchargement pour les liens ONLYOFFICE, les membres d'une salle ou les sessions de l'API Docs, puis vérifiez les restrictions à partir d'un compte destinataire.
Définissez une destination de sauvegarde, une planification, une couverture de messagerie et une limite de conservation dans ONLYOFFICE Workspace, puis vérifiez que l'archive est prête à être restaurée.
Démarrez la pile Docker Compose d'entreprise, enregistrez sa licence et ses données, configurez JWT en toute sécurité et vérifiez que les éditeurs sont prêts à s'intégrer.
Utilisez une macro JavaScript ONLYOFFICE pour supprimer les caractères non imprimables et les espaces superflus d'une plage de feuille de calcul définie, avec un flux de travail de révision sécurisé.
Déplacez les données du portail depuis le disque par défaut vers un fournisseur de stockage cloud compatible, ou déplacez les données Docker en toute sécurité en modifiant leur mappage de volume hôte.
Identifiez si Document Server utilise un package Linux ou Docker, supprimez uniquement ses composants et vérifiez les données restantes sans supprimer par erreur les services partagés.
