Aller au contenu

Lenteurs et erreurs 504

Comprendre le 504

Le message 504 Gateway Time-out vient de votre reverse proxy (nginx, Apache, HAProxy, pare-feu applicatif), pas d'InfraRiver : le proxy a attendu la réponse plus longtemps que son délai (60 secondes par défaut avec nginx), puis il a abandonné. InfraRiver, lui, a souvent continué son travail. La cause est donc une page lente, à trouver dans InfraRiver ou dans MariaDB. Suivez les étapes dans l'ordre : la première règle la majorité des cas.

502 n'est pas 504

502 Bad Gateway veut dire que le proxy n'a pas pu joindre InfraRiver du tout (service arrêté, mauvais port) : voir Le service ne démarre pas ou ne répond pas.

1. Vérifier la mémoire de MariaDB

C'est la cause la plus fréquente sur un parc réel : MariaDB est resté à sa valeur d'origine (128 Mo de mémoire tampon) et relit les tables sur le disque à chaque page.

mysql -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS memoire_Mo, @@max_connections AS connexions_max;"
Taille du parc innodb_buffer_pool_size attendu
Jusqu'à 500 hôtes 2 Go
Jusqu'à 1 000 hôtes 3 Go
Jusqu'à 2 500 hôtes 5 Go
Jusqu'à 5 000 hôtes 8 Go
Jusqu'à 10 000 hôtes 16 Go
Jusqu'à 20 000 hôtes 32 Go

connexions_max doit valoir 250 ou plus. Si memoire_Mo affiche 128, ou si connexions_max affiche 151 : appliquez le fichier /etc/my.cnf.d/infrariver.cnf de la page Base de données MariaDB avec la valeur de votre palier (Dimensionnement), puis :

sudo systemctl restart mariadb
sudo systemctl restart infrariver infrariver-ingest

Sur une machine dédiée à InfraRiver et MariaDB, la mémoire tampon peut aller jusqu'à 70 % de la RAM. La base doit rester plus petite que deux fois cette mémoire ; au-delà, agrandissez la machine.

2. Trouver la page lente

Le service infrariver mesure lui-même ses pages lentes, sans agent (Collecte des performances). Toute requête plus lente que SLOW_REQUEST_SECONDS (5 secondes par défaut, dans /etc/infrariver/server.conf) laisse une ligne SLOWREQ dans le journal du portail, avec sa durée réelle, même si le proxy avait déjà abandonné :

journalctl -u infrariver --since "-48 hours" -o cat | grep SLOWREQ | tail -40

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 …
Ce que dit la ligne Ce que ça veut dire
La même page revient souvent C'est elle qu'il faut transmettre au support.
sql= élevé (plusieurs centaines) La page charge trop de lignes une par une : correction dans InfraRiver.
Peu d'instructions, mais beaucoup de temps en base (in …s db) Une instruction lente : index manquant ou mémoire de MariaDB insuffisante (étape 1).
Peu de temps en base, mais une durée totale longue Le serveur manque de processeur, ou une autre tâche l'occupe (synchronisations).

Les lignes contiennent les noms des paramètres, jamais leurs valeurs, ni aucune donnée de votre parc.

3. Produire le rapport de performance

Lancez-le pendant la lenteur si possible :

sudo infrariver-admin perf-report

Il crée /var/lib/infrariver/diagnostics/perf-<serveur>-<date>.tar.gz. C'est le document à transmettre au support. Il contient :

  • l'état du système ;
  • les réglages non secrets ;
  • les pages lentes classées ;
  • ce que le service fait à cet instant ;
  • l'activité et les réglages de MariaDB.

Le détail de son contenu, et l'enregistrement des instructions lentes de la base le temps d'une observation (perf-on / perf-off), sont décrits dans Diagnostiquer une lenteur ou un 504.

4. Accorder les délais

Trois délais doivent rester dans cet ordre, du plus court au plus long :

Délai Où Défaut
DB_MAX_STATEMENT_TIME : une instruction SQL d'affichage est arrêtée au-delà /etc/infrariver/server.conf 55 s
proxy_read_timeout (nginx), ProxyTimeout (Apache), timeout server (HAProxy) votre reverse proxy 60 s (nginx)
délai éventuel d'un pare-feu applicatif ou d'un équilibreur en amont votre réseau —

Si DB_MAX_STATEMENT_TIME dépasse le délai du proxy, la base continue une requête que plus personne n'attend, et chaque rechargement de la page en empile une nouvelle : la lenteur s'aggrave toute seule.

Allonger le délai du proxy n'est pas une correction

Passer proxy_read_timeout à 120 s peut dépanner le temps de trouver la cause. Dans ce cas, montez aussi DB_MAX_STATEMENT_TIME (par exemple à 115) et redémarrez infrariver ; sinon la page échoue au bout de 55 s avec une erreur au lieu d'un 504. La vraie correction reste l'étape 1 ou une correction de la page lente.

Exemple nginx :

location / {
    proxy_pass         http://127.0.0.1:8000;
    proxy_read_timeout 120s;
}

5. Lenteurs aux heures de synchronisation

Les synchronisations des connecteurs tournent dans le même service que le portail. Si les pages ralentissent seulement à certaines heures :

  • comparez avec les horaires des tâches dans Administration → Scheduler ;
  • étalez les synchronisations des gros connecteurs (annuaire, vulnérabilités, cloud) ;

  • vérifiez la mémoire de MariaDB (étape 1) et l'espace disque :

    df -h /var/lib/mysql /var/lib/infrariver /var/log

    Agrandissez quand une partition dépasse 75 %.

Toujours lent ?

Transmettez au support l'archive du perf-report et les lignes SLOWREQ (voir Dépannage).