Lenteurs sur Nextcloud (+ solution)

Bonjour,

Je créé ce thread pour faire un post-mortem sur un incident qui a eu lieu a une date indéterminée sur le nextcloud de katzei.

Les évènements:

Lundi 25 au soir lors de la formation d’un membre de l’association nous constatons que la page d’inscription au nextcloud de l’association (exploitant un script maison ) répond extrêmement lentement (plus d’une minute pour afficher le formulaire plus de deux minutes pour créer un utilisateur)

Après enquête ce n’est pas le script qui est lent mais l’api de nextcloud. De même ce ralentissement semble postérieur (de plus de 10 jours) à la dernière intervention significative sur ce serveur (qui consistait a lui ajouter de la RAM).

Les symptômes sont donc a ce niveau la:

  • L’api de Nextcloud est extrêmement lente.
  • Nextcloud se comporte normalement en dehors de son api.

Nous décidons de mettre a jour le logiciel vers la dernier version 21 dans le doute, cette mise a jour ne change rien. Au vue de l’heure et du fait que nous devions travailler le lendemain nous décidons de fermer les inscriptions (le module étant inutilisable) le temps de comprendre et corriger le problème.

Une semaine plus tard on trouve la solution: optimiser la base de donnée.

En fait ce n’tait pas nextcloud qui était lent mais mysql. Pour l’optimiser on se connecte dessus (dans mon cas avec le super utilisateur mais on doit pouvoir le faire avec un autre user), on liste les tables avec

SHOW TABLES;

Puis on utilise cette liste des tables pour toutes les optimiser:

OPTIMIZE TABLE oc_accounts, oc_accounts_data, oc_activity, oc_activity_mq, oc_addressbookchanges, oc_addressbooks, oc_appconfig, oc_authtoken, oc_bruteforce_attempts, oc_calendar_invitations, oc_calendar_reminders, oc_calendar_resources, oc_calendar_resources_md, oc_calendar_rooms, oc_calendar_rooms_md, oc_calendarchanges, oc_calendarobjects, oc_calendarobjects_props, oc_calendars, oc_calendarsubscriptions, oc_cards, oc_cards_properties, oc_collres_accesscache, oc_collres_collections, oc_collres_resources, oc_comments, oc_comments_read_markers, oc_dav_cal_proxy, oc_dav_shares, oc_direct_edit, oc_directlink, oc_federated_reshares, oc_file_locks, oc_filecache, oc_filecache_extended, oc_files_trash, oc_flow_checks, oc_flow_operations, oc_flow_operations_scope, oc_group_admin, oc_group_user, oc_groups, oc_jobs, oc_known_users, oc_login_flow_v2, oc_migrations, oc_mimetypes, oc_mounts, oc_notifications, oc_notifications_pushtokens, oc_oauth2_access_tokens, oc_oauth2_clients, oc_preferences, oc_privacy_admins, oc_properties, oc_ratelimit_entries, oc_recent_contact, oc_schedulingobjects, oc_share, oc_share_external, oc_storages, oc_storages_credentials, oc_systemtag, oc_systemtag_group, oc_systemtag_object_mapping, oc_text_documents, oc_text_sessions, oc_text_steps, oc_trusted_servers, oc_twofactor_backupcodes, oc_twofactor_providers, oc_user_status, oc_user_transfer_owner, oc_users, oc_vcategory, oc_vcategory_to_object, oc_webauthn, oc_whats_new;

La commande a mis environ 5 seconde a passer et a résolu les problemes de lenteures.

4 Likes

Est-ce nextcloud qui impose les tables en format MyIsam ? Vous pourriez vous éviter de devoir gérer cela à la main en utilisant un moteur plus performant (InnoDB ou TokuDB). Visiblement votre point de contention est au niveau des I/O, ça vaudrait le coup de tester les performances d’une compression (le temps CPU ajouté devrait être minime par rapport aux accès disques évités). Enfin, si vous voulez mettre en place un cluster ou une réplication plus tard, MyIsam est déconseillé.

La bdd est généré par Nextcloud, j’avoue que je ne me suis pas trop posé la question quand je l’ai mise en place. Je regarderai avec quoi elle tourne quand j’aurais accès a mon infra. Il me semble que innodb à le même problème (mais moins prononcé peut être). En pratique en dehors de ce problème je n’ai jamais eu de problèmes d’io sur cette vm ou sur l’hyperviseur en général (les stockages sont sur un SSD ce qui est largement suffisant au vue de mon trafique).

Edit après vérification toutes les tables sont en innodb