Diagnostiquer une lenteur ou un 504

Quand une page met trop de temps, votre reverse proxy (ou un pare-feu applicatif) coupe la connexion et l'utilisateur voit un 504. Le serveur InfraRiver, lui, continue souvent son travail : la cause se trouve dans InfraRiver ou dans sa base MariaDB, pas dans le 504 lui-même. Trois outils, sans secret ni donnée métier collectés, permettent de la retrouver et de la transmettre au support.

1. Le journal des requêtes lentes (toujours actif)

Toute requête web plus lente que SLOW_REQUEST_SECONDS (défaut 5 secondes, 0 = désactivé, dans /etc/infrariver/server.conf) laisse une ligne dans le journal du service :

SLOWREQ 63.4s GET /servers/ params=f_name,per_page status=200 sql=412 in 61.9s db; slowest 31.0s: SELECT … FROM server_software …

On y lit la durée réelle (même si le proxy avait déjà abandonné), la page, les noms des paramètres (jamais leurs valeurs), le nombre d'instructions SQL, le temps passé en base et l'instruction la plus lente, avec ses valeurs remplacées. Pour les consulter :

journalctl -u infrariver --since "-24 hours" -o cat | grep SLOWREQ

Les instructions SQL lancées par une page sont arrêtées au bout de DB_MAX_STATEMENT_TIME (55 s par défaut) : gardez cette valeur inférieure au délai de votre reverse proxy, sinon la base poursuit des requêtes abandonnées et chaque rechargement en empile une nouvelle.

2. Le rapport de performance (une seule commande)

sudo infrariver-admin perf-report

Produit /var/lib/infrariver/diagnostics/perf-<serveur>-<date>.tar.gz (droits 0640) à transmettre au support. Contenu :

Fichier	Ce qu'il contient
`00-summary`	Versions des paquets, noyau, nombre de processeurs, état SELinux
`10-system`	Charge, mémoire, disques, processus les plus gourmands, connexions, arrêts par manque de mémoire
`20-app`	Quelques réglages non secrets de `server.conf` (liste fixe de clés ; les valeurs de requêtes SQL, les adresses e-mail, les noms d'annuaire et le contenu des enregistrements verrouillés sont masqués dans tout le rapport), temps de réponse local de la page de connexion (5 mesures : l'application seule, sans votre proxy), connexions par état
`30-slow-requests`	Les lignes `SLOWREQ` des 24 dernières heures et le classement des pages (nombre, moyenne, maximum)
`31-errors-scheduler`	Erreurs, délais dépassés, connexions perdues, signes de surcharge du planificateur, tâches des deux dernières heures (valeurs de paramètres SQL retirées)
`32-inflight-threads`	Ce que le service fait à cet instant : requêtes en cours depuis plus d'une seconde, réserves de connexions, pile de chaque thread (utile quand la requête ne se termine jamais)
`40-db-variables-status`	Réglages et compteurs MariaDB (mémoire tampon, connexions, tables temporaires sur disque, verrous, interblocages…)
`41-db-activity`	Instructions en cours (valeurs remplacées), connexions par utilisateur, transactions longues, attentes de verrou
`42-db-innodb`	État InnoDB (transactions, dernier interblocage, mémoire tampon)
`43-db-tables`	Tables les plus volumineuses et taille du parc (serveurs, logiciels, CVE ouvertes…)
`44-db-slow-statements`	Synthèse des instructions lentes de la base (voir ci-dessous)

Les valeurs des instructions SQL sont toujours remplacées (texte → S, nombres → N). Une clé privée, un jeton ou une clé d'accès trouvés par erreur dans le rapport l'empêchent d'être archivé. Option --no-dump : ne pas interroger le service en cours d'exécution (fichier 32 absent). Lancez-le pendant la lenteur si possible : c'est là que les fichiers 32 et 41 sont les plus parlants.

3. Le journal des requêtes lentes de la base (le temps d'une observation)

sudo infrariver-admin perf-on      # enregistre les instructions de plus d'une seconde
   … quelques heures, en reproduisant la lenteur …
sudo infrariver-admin perf-report  # la synthèse apparaît dans 44-db-slow-statements
sudo infrariver-admin perf-off

perf-on n'agit que jusqu'au prochain redémarrage de MariaDB. Les commandes utilisent le compte administrateur de la base (socket local, droit root), à défaut le compte de l'application, qui ne voit alors que ses propres connexions.

Ce qu'il faut regarder en premier

Un SLOWREQ répété sur la même page avec beaucoup d'instructions SQL (sql= élevé) : page qui charge trop de lignes une par une ; avec peu d'instructions mais beaucoup de temps en base : une instruction lente à indexer.
Innodb_buffer_pool_reads élevé par rapport à Innodb_buffer_pool_read_requests, ou une mémoire tampon restée à 128 Mo : le fichier /etc/my.cnf.d/infrariver.cnf de l'étape 3 de l'installation n'a pas été appliqué. Réglez innodb_buffer_pool_size à la valeur de votre palier (jusqu'à 60-70 % de la mémoire d'un serveur dédié).
Beaucoup de Created_tmp_disk_tables : tris ou regroupements trop gros pour la mémoire.
Délais de votre proxy : un proxy_read_timeout de 60 s (valeur par défaut de nginx) coupe toute page plus lente ; le rapport dit quelles pages sont concernées.