Nextcloud : des retours sur de grosses instances ?

Bonjour tout le monde,

Je suis intéressé par des retours d’expérience de CHATONS (ou pas CHATONS) ayant dû gérer un Nextcloud de grande taille.
Je ne parle pas de la gestion de nombreuses instances (comme c’est le cas pour Framaspace) mais bien d’une seule instance qui accueillerait plusieurs milliers de personnes.
Donc je recherche plutôt des retours sur des outils comme Framagenda ou Framadrive (ce dernier étant par ailleurs limité à 5000 utilisateur·ices), ou toute autre instance dont l’usage est mutualisé avec les autres utilisateur·ices, qui dépasse a minima les 100 personnes.

  • Combien d’utilisateur·ices hébergez vous sur votre instance ?
  • Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?
  • Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…
  • Nextcloud gère-t-il bien la montée en charge, de manière générale ?
  • Une instance de cette taille nécessite-t-elle des précautions particulières par rapport à une instance classique ? Par exemple :
    • Opérations de maintenance spécifiques ;
    • Concernant le cloisonnement des utilisateur·ices sur l’instance ;
    • Autre…
  • Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ? Lesquelles sont les plus difficiles ou coûteuses en consommation de ressources ? Pourquoi ? :
    • Files
    • Calendar
    • Contacts
    • Polls
    • Forms
    • Talk
    • Activity
    • Deck
    • Autre (spécifiez)
  • Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?
  • Questions sur Collabora/Onlyoffice (si applicable) :
    • Utilisez-vous une version « débridée » du logiciel pour passer outre les limites d’utilisation concurrente de l’éditeur sur la version gratuite ?
    • Mutualisez-vous l’instance Office avec d’autres instances de Nextcloud ?
    • Comment l’instance est-elle dimensionnée ? (conso CPU/RAM)
    • Quels problèmes rencontrez-vous (ou avez-vous rencontré) avec ce logiciel ?

Je me permets un petit ping @Zaclys @infini @Framasoft @Libretic, si jamais vous avez un peu de temps pour partager vos expériences, ça nous sera utile :pray:
(et si vous avez de la documentation ou des confs qui présentent déjà tout cela en détail, je prends également volontiers.)

Merci !

2 Likes

Je réponds pas pour NextCloud, mais pour Collabora : on paye Collabora 2000 € / an pour avoir le support et les paquets Debian débridés officiels.

En pratique on ne gère plus notre instance, c’est notre hébergeur Octopuce qui a une grosse instance Collabora qu’il partage entre tous ses clients. Tu peux peut-être les contacter car ils ont peut-être aussi des grosses instances NextCloud ?

On a eu des soucis de perte de données sur les documents, mais ça semble résolu maintenant. En général quand on a un bug, on remonte au support et dans les semaines qui suivent c’est corrigé. Généralement je remonte le bug à la fois sur Github pour que d’autres qui auraient le même souci puissent tomber dessus, et à la fois via le support commercial.

2 Likes

Bonsoir, les petits nouveaux de BOC47 vont essayer de vous donner un peu de matière par rapport à notre instance, si besoin de compléments, n’hésitez pas. Notre instance Nextcloud existe depuis un peu plus d’un an et demi et, à ce jour, nous comptons pas loin de 300 utilisateurs, j’avais déjà eu l’occasion d’installer plusieurs instances auto-hébergées à titre personnel mais rien qui me permettait d’avoir du recul sur ce projet quant aux thématiques que vous abordez. Ma prise de poste au sein du collectif depuis Février 2024 me permet désormais de mieux les évaluer avec une instance qui est clairement utilisée et évolue au fur et à mesure. Même dans le cadre d’une instance privée avec très peu d’utilisateurs, je trouvais que Nextcloud était un peu « usine à gaz », à la différence d’autres projets similaires (quoique moins complets) comme Seafile; aujourd’hui, je dois dire que ce n’est plus le cas et que, au vu de toutes les fonctions que ce logiciel remplit, il s’en sort particulièrement bien en termes de charge. J’ai beaucoup travaillé dessus mais ce n’est pas moi qui avait procédé à l’installation initiale, notre conteneur Proxmox abritant notre instance dispose de 2 To de stockage dédié aux données, de 8 coeurs et de 16 Go de RAM et, clairement, avec ce dimensionnement de ressources, on est loin de le saturer, globalement, on doit consommer 4 Go de RAM et à peine 10/15 % du CPU pendant les horaires de bureau + environ 650 Go de consommé en termes de stockage, j’avais envisagé de les réduire mais, ayant les mêmes craintes que vous concernant une montée en charge subite, je les ai conservées. Toutefois, malgré une nette augmentation de nos utilisateurs en 2024, les exigences matérielles de notre instance n’ont que peu évoluées voir quasiment pas du tout donc, oui, Nextcloud gère très bien la montée en charge. Pour la configuration, à aujourd’hui encore, rien de très spécifique de notre côté : pas (encore) d’équilibrage de charge, de réplication (même si c’est dans les cartons), pas de BDD séparée (ça aussi c’est en réflexion pour le futur), tâches cron et cache Redis, effectivement oui. Plutôt qu’Apache, c’est Nginx qui fait office de serveur web, là dessus il a fallu beaucoup travailler pour avoir une instance qui tourne bien : on a un reverse proxy nginx en frontal de tous nos conteneurs et Nextcloud ne passe pas parfaitement bien derrière un proxy qui fait de la décharge SSL, j’ai opté pour l’utilisation du module stream de Nginx pour certains cas particuliers dont Nextcloud, ainsi, on fait plutôt du TCP passthrough, le serveur nextcloud écoute sur le port 443, gère lui-même son certificat et sa sécurité et nous n’avons plus d’erreur de réécriture d’URL comme cela arrivait souvent au début (même si ma conf nginx suivait la doc officielle et les réécritures nécessaires + d’autres trouvées sur le forum officiel). Sa sécurisation via les conf proxy et serveur web + un WAF (Crowdsec en ce qui nous concerne) sont nécessaires car ce service héberge des données personnelles, hormis cela, pas vraiment de précaution particulière (ou alors je n’ai pas bien compris la question :sweat_smile:). Des applications que vous citez, toutes sont faciles à maintenir car intégrées, Talk nécessitera de la configuration supplémentaire (un serveur coturn séparé, une bonne bande passante voire de la QOS pour prioriser le traffic => solution visio = latence la plus faible possible, je crois que nos soucis viennent plus de là que de la configuration, d’ailleurs). Pour la modération, en l’état actuel, ça n’est jamais encore arrivé et, en cherchant un peu, certaines nouvelles extensions permettent de le faire mais pas de manière générale, plutôt dans un contexte particulier comme le partage de liens publics, au préalable, les fichiers sont scannés par un antivirus mais cela s’arrête là dans le contrôle des données uploadées + le fait que notre instance doit permettre la collaboration et être plus respectueuse de la vie privée et des données personnelles que les services des GAFAM donc pas de surveillance/modération mais une incitation à la responsabilisation (également sur le volet consommation de l’espace de stockage). Pour Onlyoffice que nous utilisons pour la création/édition de documents, effectivement, nous utilisons une version débridée sinon ce ne serait pas viable, si besoin de liens, n’hésitez pas à demander et en termes de consommation des ressources, on est larges avec 2 coeurs/4 Go de RAM et un espace de stockage de 50 Go, c’est que de l’applicatif, je pourrais même réduire, les seuls problèmes rencontrés avec OnlyOffice concerne plus le couple Nextcloud/OnlyOffice via le connecteur officiel, attention aux versions, essayez d’être toujours au plus proche des dernières versions que ce soit Nextcloud, le connecteur OO ou le serveur Office, depuis quelques temps, plus de réel souci à ce niveau là car on est à jour et que de nouvelles fonctionnalités importantes n’ont pas été implémentées depuis deux trois versions mais on effectivement eu des périodes où on était à jour de quasiment tout sauf du serveur OO et ça créait des erreurs dans Nextcloud. Voilà, j’espère avoir répondu à au moins une partie de vos questions, si besoin de compléments et que je suis en capacité de répondre, pas de souci. Bonne soirée. Renaud.

1 Like

Hello !

Merci pour ce retour :slight_smile:
Une question : y a-t-il une raison particulière d’utiliser onlyoffice au lieu de Collabora ?

Bonjour, avec plaisir, pas de souci, je pense que c’est plus pour permettre aux personnes désireuses de basculer vers nos services de pouvoir effectuer la transition en douceur, généralement utilisatrices des solutions Microsoft Office, elles peuvent ainsi garder leurs habitudes et leurs documents sous format natif.

Je réponds pour Framagenda/Framadrive (et avec 2/3 détails sur Framaspace). Il est possible qu’un collègue vienne compléter. :slight_smile:

  • Combien d’utilisateur·ices hébergez vous sur votre instance ?
    138156 / 6647. Évidemment, le nombre d’utilisateurs actifs mensuellement est beaucoup plus faible - autour de 10%. Nous avons comme objectif de redévelopper une application pour purger les utilisateurs inactifs - je l’avais fait il y a 8 ans, mais ça fait très longtemps qu’elle ne fonctionne plus.

  • Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?

    Pour les deux services, la base de données se trouve sur un autre serveur (grâce à pgbouncer). La consommation RAM n’a jamais été trop le point critique, on a énormément de mémoire cache.

    Information Framagenda Framadrive
    Modèle du serveur principal AX51-NVMe (équivalent AX52) EX42 (équivalent EX44)
    Modèle du serveur de base de données AX41-NVMe (équivalent AX42) EX41-SSD (équivalent EX44)
    Load average Entre 2 et 14 (pics sur les jours de semaine) « ça passe » Entre 0,5 et 1,5 « c’est très large »
  • Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…

    Redis utilisé partout où c’est possible comme cache Nextcloud. Il y a aussi la possibilité de mettre les sessions PHP dans Redis (on le fait parfois). Cron système évidemment (réglé à 5 minutes, avec un fichier de lock). Pas de réplication, ni de load balancing. Quelques tweaks de configuration pgbouncer (nombre de connexion). L’application notify_push évite énormément de requêtes de polling pour des changements de la part des clients bureau.

  • Nextcloud gère-t-il bien la montée en charge, de manière générale ?

    À notre échelle, oui, mais notre nombre d’utilisateur·ices évolue lentement. C’est plus les mises à jour qui posent parfois des problèmes de performance.

  • Une instance de cette taille nécessite-t-elle des précautions particulières par rapport à une instance classique ?

    • Évidemment, upgrade uniquement via CLI pour éviter un timeout si fait côté web (upgrade.disable-web pour forcer upgrade via CLI).
    • Framagenda étant concentré sur les agendas, on a un job cron dédié pour ça dav:send-event-reminders (pour être sûr que le rappel de l’événement est envoyé à temps).
    • Concernant le cloisonnement des utilisateur·ices sur l’instance, on désactive l’autocomplétion tant que l’identifiant ou l’email n’est pas entré en entier (il reste qu’on peut utiliser cette méthode pour vérifier si un utilisateur existe par exemple).
  • Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ? Lesquelles sont les plus difficiles ou coûteuses en consommation de ressources ?

    • Polls n’est pas une application officielle et son développeur… a du mal à comprendre ce que sont des migrations de base de données, gérant les choses à sa sauce. Ainsi, la migration de cette application était souvent ce qui prenait le plus longtemps lors des mises à jour de Framagenda. L’application est assez pratique, mais codée un peu n’importe comment. C’est notamment la raison qui fait qu’on ne l’a pas installée jusqu’ici sur Framaspace.
    • Talk, en l’absence du backend de haute performance, fait en permanence des long polling côté serveur pour récupérer les nouveaux messages, ce qui monopolise les threads php-fpm. L’application semble trop peu utilisée pour que ça soit gênant sur Framagenda ou Framadrive, mais on a patché pour Framaspace, en attendant d’avoir le temps de mettre en place le backend de haute performance.
    • Cercles/Équipes a un niveau d’abstraction assez énorme, pas mal de bidouilles propres à l’auteur et du code de qualité discutable, ce qui mène souvent à des problèmes de régressions. Par exemple on a ce patch non mergé sur Framagenda (qui fait logiquement beaucoup d’appels pour lister les agendas et leurs permissions). Mais bon, pas trop le choix, c’est dans le core et ça reste utile.

    On n’a pas de problèmes avec le reste, de ce que je me souvienne.

  • Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?
    Jamais de modération du contenu, juste une fois ou deux une personne qui a partagé un contenu avec le mauvais compte, ce qui mène à incompréhension.

  • Questions sur Collabora/Onlyoffice
    Non déployé sur Framagenda et Framadrive. Sur Framaspace on a principalement (97% des espaces) du Collabora débridé, dockerisés et répartis sur 2 VM dédiées « office » de 4-6 vCPU et 30GB de RAM chaque. On est pour le moment sur 50 espaces par Collabora dockerisé (mutualisé, donc), mais c’est pas sûr que le ratio soit le plus optimal. On observe parfois des processus zombies et des pics de mémoire avec les conteneurs Collabora, donc on a mis un restart nocturne des conteneurs faute de mieux, et il faut encore qu’on affine quelques trucs (utiliser les limites de ressources Docker).
    On n’a pas (encore) d’OnlyOffice débridé, on en utilise un par espace (encore dockerisé).

    De manière générale c’est clair que c’est difficile de provisionner de manière optimale, certains groupes d’utilisateur·ices ne vont jamais utiliser les offices quand d’autres vont se connecter tous au même moment.

On a quelques détails supplémentaires sur notre infra par ici :

2 Likes

Bonjour,
Je peux partager l’expérience de Numericloud, presque 900 utilisateur·ices actuellement ().sur une VM avec une stack Docker. Nous utilisons un build de l’image apache-full pour ajouter entre autres des configs adaptées pour opcache et php, quelques configurations aussi pour le cron (utilisation de preview-generator et de memories pour un club photo).
La VM utilise docker et Portainer avec pas mal de ressources (10CPU/16G de RAM), sachant qu’il a d’autres stacks aussi attachées à cette VM. Nextcloud va utilisé plutôt vers les 4G de ram
pour l’utilisation des CPU il reste plutôt en-dessous des 20%, mais peut avoir des pics.
Tout cela aussi sur un Promox, un volume pour /var/www/html sur du RAID ssd et les data un RAID sata. Il faut ajouter à cela un disque de cache, le risque est d’avoir beaucoup d’écritures disques I/O…
Sinon nextcloud semble bien gérer la charge, mais par exemple avec des grosses instances comme celle-ci, les mises à jour des modules demande de mettre le serveur en mode maintenance et sont un peu plus longues. Il y a parfois des bugs à corriger soit sur des applications, soit dans le core de Nextcloud. Il peut y avoir des choses à corriger, rarement dans
la BDD.
Pour les exemples d’application, Polls a déjà eu des versions avec des changement de tables qui cassait l’application, mais c’était possible de résoudre, il y a même une commande occ maintenant pour la migration des tables de polls…
Calendar et Contacts, ça va dépendre du nombres d’utilisateurs qui synchronisent avec le webdav, mais ça semble bien gérer.
Talk est clairement gourmand en ressources. Nous avons installer un serveur Hautes Performances (spreed-signaling) sur autre VM qui permet de faire des visios, qui gère aussi Coturn.
Activity, j’ai entendu autrefois que cette app consommait beaucoup de ressources, mais je pense que ce n’est plus le cas.
Deck, rien à dire, ça fonctionne bien.
Nous utilisons Collabora Office pour l’édition collaborative. Parfois le service Collabora est dans la stack pour l’instance Nextcloud dédiée seulement, ou sur un serveur Collabora code qui peut mutualiser des instances, ainsi qu’un serveur Collabora Online, car partenaires de Collabora. Collabora demande peut-être plus de ressources que OnlyOffice puisque les requêtes sont plus côté serveur. Le fichier de configuration coolwsd.xml pour collabora est touffu, mais assez explicite…
Petite parenthèse, Nextcloud aussi avec Yunohost a l’avantage d’être très bien maintenu et la future version de Yuno qui arrive bientôt va améliorer les performances du LDAP dans le cas où les utilisateurs sont nombreux. Le paquet Collabora et OnlyOffice aussi sont maintenus, il y a une app Coturn et une app Signaling pour Talk. Depuis peu on peu aussi ajouter Notify-push…

Ce qui est embêtant c’est le client de synchronisation qui suivant les OS fonctionne plus ou moins bien. Sans parler de modération, il y a souvent un besoin d’aider les utilisateurs avec leurs synchronisations…

2 Likes

Un grand merci pour vos incroyables retours. J’ai bien fait de demander ici :smile:

Je suis assez étonné pour la consommation en RAM, chez nous on a deux instances de Collabora pour 8 instances de Nextcloud, et chaque Collabora prend 2 Go en moyenne, et monte parfois à plus de 5 Go à cause de « sessions fantômes » (même problème que tcit a mentionné, je pense).
Je retiens l’astuce de tcit sur la cron nocturne pour Collabora.


Question bête, mais maintenant que ./occ user:lastseen --all a été introduit dans la version 29, est-ce que tu penses qu’il serait envisageable de scripter une routine avec notification:generate, user:disable et user:delete pour votre cas d’utilisation, ou cela ne prendrait pas en compte certaines problématiques ? (après, ce n’est peut-être juste pas votre priorité)

En tout cas, votre nombre de comptes est délirant sur Framagenda, je ne pensais pas que NC pouvait en supporter autant.

Il me semblait que dans votre conf aux JRES que vous utilisiez plutôt pgpool-II, est-ce que vous avez changé entre temps, ou alors pg_bouncer ne concerne que Framadrive/Framagenda et pas framaspace ? (ou alors, vous utilisez la combinaison des deux ?)

Ça, c’est super intéressant. Est-ce qu’une instance de notify_push peut être mutualisée sur plusieurs instances Nextcloud, par hasard ? (je vois qu’il faut lui donner le fichier de configuration NC, donc dans l’idée ça m’a l’air compliqué.)


Ah, oui, le développeur de Polls… Même retour pour ma part, et le retour de tcit vient corroborer. J’ai déjà eu à restaurer un backup sur ses tables à cause d’une migration de son app.
Je trouve aussi qu’il y a du mieux depuis un an.

En fait, je me suis trompé, on a bien commencé à mettre ça en place, avec une limite à un petit peu plus de 2Go, et un autorestart du conteneur si jamais la mémoire est atteinte (ce qui arrive). On n’a pas encore eu de retours comme quoi c’était inutilisable :sweat_smile:. La plupart des conteneurs idle sont à 200/300Mo.

Je ne connaissais pas cette commande, merci. Ça pourrait marcher ainsi, mais il y aurait quand même besoin de bricoler un peu plus, notamment stocker la liste des comptes concernés quelque part avec un statut si on veut plusieurs emails d’avertissement (oui, car les notifications ne déclenchent pas forcément l’envoi d’un mail, et les mails de notification ne seraient pas explicites, donc je préfère un vrai mail). Vu qu’il ne semble pas avoir de pagination sur cette commande, ça pourrait être aussi un peu violent. De plus, une application dédiée permettrait également à n’importe qui de l’installer, donc ça serait quand même bénéfique pour nous.

Et encore, il y a aussi du monde qui supprime rapidement son compte après avoir testé et être insatisfait grâce à notre application. :sweat_smile:
Même sans le système Global Scale, il y a clairement encore de la place pour scale verticalement et horizontalement (ouais, y a enfin des transactions à peu près correctes dans Nextcloud), tant qu’on ne regarde pas à la dépense…
Mais dans le cas de Framagenda, rappel que le nombre d’utilisateurs actifs est bien plus faible… et qu’on ne s’occupe pas de fichiers ! Même avec 24M d’événements en BDD et 2.5M de contacts, la taille de la base de données (140GB) n’est pas forcément le point le plus gênant.

Oui, c’est bien cela, pgpool sur Framaspace et pg_bouncer sur Framadrive/Framagenda Je laisse @Framasky expliquer le choix (probablement le fait que pg_bouncer ne fait pas de load balancing ?).

Hélas non, ce qui fait aussi qu’on ne l’a pas non plus sur Framaspace. Et faut même plusieurs redis séparés à cause de prefix redis channels with redis db id by icewind1991 · Pull Request #202 · nextcloud/notify_push · GitHub qui n’est pas mergé.

1 Like

Salut, je réponds pour @infini :

Les infos sur notre instance sont dispos ici https://cloud.infini.fr/ocs/v2.php/apps/serverinfo/api/v1/info?format=json

Combien d’utilisateur·ices hébergez vous sur votre instance ?

244

Pour cette instance, comment le serveur est-il dimensionné ? Vous avez combien en consommation moyenne disque / CPU / RAM ?

Comme tous nos services (sauf etherpad qui ne le permet pas facilement), nextcloud est installé en mode HA sur deux vms dont voici les caractéristiques à l’instant :

Cpu ................: 6 x  QEMU Virtual CPU version 2.5+ @ 2397.222
Memory .............: 145.00 Mo (Free) / 7978.09 Mo (Total)
Load Averages ......: 0.32, 0.41, 0.43 (1, 5, 15 min)

Utilisez-vous des configurations ou modules particuliers ? Par exemple : cache Redis, Cron système, réplication, load balancing, configuration de BDD spécifique…

Pour le cache donc, on applique ce que je citais ici Redirect loop login / Renewing session token failed · Issue #13431 · nextcloud/server · GitHub pour les sessions PHP gérées par memcached, sinon on est sur de la conf « classique » cf :

  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',

Puis du memcached_servers branché sur notre pool memcached de trois nodes.

Nextcloud gère-t-il bien la montée en charge, de manière générale ?

Aucun pb a signaler de notre côté, mais notre instance n’est pas très sollicitée par rapport à d’autres.

Parmi les applications suivantes, lesquelles sont les plus faciles à maintenir ?

Voici la liste des apps qu’on propose, aucune ne nous a jamais posé de pb.

  - activity: 2.21.1
  - calendar: 4.7.16
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contacts: 6.0.3
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.4
  - drawio: 3.0.3
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.1
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - gpoddersync: 3.12.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - news: 24.0.0
  - nextcloud_announcements: 1.18.0
  - notes: 4.11.0
  - notifications: 2.17.0
  - oauth2: 1.17.1
  - password_policy: 1.19.0
  - photos: 2.5.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - systemtags: 1.19.0
  - tables: 0.9.0
  - tasks: 0.16.1
  - text: 3.10.1
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - updatenotification: 1.19.1
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0

Avez-vous déjà eu à modérer du contenu sur cette instance ? Souvent ? Comment ça se passe ?

Jamais, on a lutim et lufi pour nous occuper sur le sujet :stuck_out_tongue:

Questions sur Collabora/Onlyoffice (si applicable)

On ne les propose pas.

1 Like

Je suis étonné de voir l’idée de restart des conteneurs Collabora, car si vous faites ça et que des gens sont en train d’éditer des contenus, ils risquent de perdre leurs modifs (dans Collabora c’est le serveur qui édite le document, le client n’a qu’une vue de ce que le serveur fait, donc si on kill le serveur, le document en cours d’édition est perdu si non enregistré). Bon il y a normalement une sauvegarde auto, mais ça me semble risqué quand même.

D’autre part je ne suis pas sûr qu’utiliser beaucoup de conteneurs Collabora (par exemple un pour chaque instance NextCloud) soit le mieux niveau ressources, car ce qui prend de la RAM c’est l’instance Collabora (penser que c’est comme si on lance un LibreOffice, sans ouvrir de document), ensuite chaque document et chaque utilisateur prend un peu de RAM mais ça reste faible. Sur le paquet Collabora Debian voici ce que je mesure :

  • Collabora sans aucun document ouvert = 400 Mo de RAM
  • Document texte vide ouvert = 15 Mo
  • Document texte de 50 pages ouvert (taille du doc = 250 Ko) = 50 Mo
  • Document texte de 13 pages ouvert avec plein d’images (taille du doc = 13 Mo) = 50 Mo
  • Chaque utilisateur connecté à un document = ~2 Mo (quel que soit le type de document)

Collabora une console admin très utile pour suivre ça, qu’on peut activer via une directive de coolwsd.xml

La logique c’était surtout de se dire que si le Collabora a besoin de 27GB de mémoire (on a déjà eu des OOM sur notre VM à 30GB de RAM) c’est probablement que les modifications sont déjà perdues. :stuck_out_tongue: Mettre une limite permet d’éviter qu’un conteneur rende indisponible les X autres sur le même serveur en prenant toute cette mémoire. Maintenant, y a besoin qu’on affine un peu et qu’on étudie les éventuels retours. Potentiellement la fuite mémoire a été corrigée depuis.

C’est clairement pas ce qu’on fait hein, on est actuellement à 50 espaces sur chaque conteneur Collabora. Mais on est bien d’accord sur la logique que tu décris. Il me semble toutefois qu’on avait entendu parler et identifié des limites sur le nombre de connexions globales à un serveur Collabora, non pas sur la mémoire utilisée, mais sur les performances du rendu des tuiles et de la réactivité perçue du service.
Imaginons qu’à 18h30, 100 assos (5% de nos espaces totaux) avec en moyenne 1,5 personne se connectent en même temps, ça fait un sacré pic qui peut être bien mieux réparti par le fait qu’on utilise plusieurs conteneurs et plusieurs serveurs physiques.

Après, pareil, le nombre est un curseur qui peut bouger un peu (et Collabora produit souvent des améliorations satisfaisantes).

La plus grosse instance nextcloud que je gère à 800 utilisateurices (mais c’est un intranet et certaines personnes se connectent rarement). C’est un setup nextcloud_ynh (avec yunohost) standard avec un peu d’optimisation sur php fpm. Elle est dimensionnée avec 3Go de ram et 2vcpu. Seuls une trentaine de personnes sont censées pouvoir déployer le client de synchro…

J’ai aussi fait des nextcloud pendant le covid pour des écoles, environ 300 utilisateurices, 100+ connectés dans les 5 dernières minutes (4Go de ram et 4vcpu). J’avais écris un article dans le wiki chatons pour partager le paramétrage.

Je n’ai jamais déployé polls car je propose une installation de framadate.

Je suis en mesure de proposer de la visio (j’ai empaqueté nextcloud signaling pour yunohost) mais c’est peu utilisé pour l’instant.

Un document qui peut aider (je le retrouve plus que via archive.org…): Deployment Recommendations — Nextcloud 11 Server Administration Manual 11 alpha documentation

Après il prend de l’age et nextcloud a beaucoup évolué. Ceci dit on voit qu’il semble possible de faire des NC pour 100000 utilisateurices (en mode entreprise, donc salarié⋅es).

2 Likes