Afficher une page quand son serveur dédié reboot

[colonies]

Bonjour,
Ces derniers temps, j'ai des problèmes de stabilité qui m'obligent à rebooter tous les jours ou tous les deux jours. Je ne vais pas m'étendre dessus, j'ai une erreur avec MariaDB, et quand j'en cherche l'origine il n'y a qu'UN résultat dans Google... et c'est le code source de MariaDB, avec un commentaire FIXME. Bref.

Mon problème est que quand je reboot, il n'y a rien, que la page d'erreur par défaut du navigateur qui dit que le site est introuvable.
J'aimerais afficher une page HTML (hébergée ailleurs, donc) pour prendre le relais quand le serveur est down. Il faudrait que ce soit une solution gratuite.
Avez-vous mis en place quelque chose comme ça et si oui, avec quoi / comment ?

Merci d'avance pour vos réponses.

 

[spout]

Cloudflare propose une solution de load balancer / failover : https://www.cloudflare.com/learning/performance/what-is-server-failover/
(jamais testé)

NB : je suis curieux qd même de savoir quelle erreur il s'agit et le fameux commentaire FIXME ?
NB2 : tu peux aussi envisager de migrer à PostgreSQL si MariaDB c'est de la daube ?

 

[colonies]

NB : je suis curieux qd même de savoir quelle erreur il s'agit et le fameux commentaire FIXME ?
NB2 : tu peux aussi envisager de migrer à PostgreSQL si MariaDB c'est de la daube ?

Quand ça commence à déraper, les erreurs de ce type s'enchainent :
2024-12-17 18:08:36 0 [Note] InnoDB: Memory pressure event freed 52325 pages
P.S. : je me suis planté, le commentaire est dans un bloc IF au-dessus.

MariaDB marchait bien depuis des années, mais pas depuis la dernière mise à jour dist-upgrade de Debian qui a mis à jour le noyau, entre autres. Et c'est bien ça qui est relou : quand autant de choses sont mises à jour d'un coup, il y. des doutes sur qui est vraiment responsable... du reste il ne plante pas, mais une page qui mettait 0,02s à être générée peut passer à 0,2s, puis ça dérive jusqu'à plusieurs secondes et c'est vraiment très énervant quand on a soigné ses perfs.

J'ai regardé la mémoire avec top, j'ai augmenté les buffers innoDB, regardé si mysqltuner.pl avait quelque chose à me signaler, mais je n'ai rien vu. Mais je n'ai pas le temps de me consacrer à un projet de plus en ce moment, d'où les reboots en attendant.

Passer à Postgres n'est pas au programme : même si tous mes appels à la DB sont centralisés dans une classe, comme c'est un truc que j'ai fait évoluer au fil de mes besoins sur plus de 20 ans, même si ça faisait partie d'un CMS avec une couche d'abstraction il y a de ça très, très longtemps, le code n'a plus rien à voir aujourd'hui et je n'ai pas de solution de remplacement rapide possible sans avoir à tester. Non pas que je pense que ça soit impossible, mais si je fais ça, je ne mettrai pas en prod avant trois mois sans erreur en dev ou quelque chose comme ça.

 

[spout]

Et tu ne sais pas mettre en place un cache (Redis/Memcached) pour cette partie là ?

 

[colonies]

Et tu ne sais pas mettre en place un cache (Redis/Memcached) pour cette partie là ?

J'ai déjà ce qu'il faut en cache. Le truc c'est que des requêtes nécessaires qui d'habitude prennent quelque chose comme 0,00014 seconde peuvent prendre 8 secondes - mais pas après un reboot, ça se produit progressivement, de plus en plus fréquemment, et c'est de plus en plus lent.

Le problème n'arrive pas sur une table en particulier, pas parce qu'il manque des indexes ou quoi : certaines requêtes deviennent aléatoirement ultra lentes alors qu'elles trouvent directement les deux lignes qu'il leur faut. Mais même quand ça se produit, tu peux très bien naviguer avec des pages 10x plus lentes sans t'en rendre compte sur 5 pages, mettons, puis la 6ème va prendre 10 secondes, parce qu'une requête ultra simple a été bloquante pendant 9 secondes.

C'est vraiment bizarre. Il faudrait que je fasse un test de la mémoire après un reboot, on ne sait jamais - et en affichant une page d'attente aux utilisateurs, bien sûr ;-)

 

[colonies]

Je suis peut-être en train de voir le bout du tunnel, même si c'est un peu tôt pour crier victoire.
Ma (peut-être) solution : faire des ANALYZE TABLE sur toutes les tables.
Je détaille au cas où quelqu'un tomberait sur le même problème et sur ce sujet.
Apparemment, le message des logs concernant la mémoire n'a aucun intérêt. C'est un simple message de notification. Je ne l'avais pas avant, et ça a été une mauvaise piste.
J'ai passé beaucoup de temps à chercher quoi faire, entrecoupé d'optimisations d'opération sur la DB, à examiner les pages les plus populaires et à essayer de tout optimiser à mort, pour au moins tenter de ralentir la vitesse de dégradation des perfs. Mais la vitesse de dégradation semblait assez aléatoire.

J'ai fait des OPTIMIZE TABLE... mais ça ne s'applique qu'au stockage.

En réalité, ce qui concerne les indexes et l'optimiseur, c'est ANALYZE TABLE, et maintenant c'est persistant (si vous avez regardé la doc depuis longtemps). Donc c'était peut-être ça. Des anciennes stats devenues TRÈS contre-productives, et qui revenaient malgré les reboots.
Ce qui est inquiétant, c'est que les perfs se dégradaient. Alors j'espère que c'est dû à un bug avec un changement au niveau des stats d'indexes et que les mises à jour permettront que tout redeviendra stable.
Bref, je croise les doigts.

 

[pomination]

Bonjour, un EXPLAIN n'indiquait rien ?

 

[colonies]

Bonjour, un EXPLAIN n'indiquait rien ?

Tout semblait OK. Bons indexes, peu de lignes ramenées... le log des requêtes lentes montrait des délais de parfois plusieurs secondes pour récupérer un pauvre enregistrement de quelques octets alors que la requête n'avait qu'un WHERE id = xxx et que id est la colonne de la clé primaire. Ça n'avait aucun sens.

Mon serveur semblait être redevenu stable, mais comme hier Debian a proposé une mise à jour, je l'ai appliquée.
J'espère que ça restera stable, mais si ça tient, est-ce que ça sera grâce aux ANALYZE TABLE ou grâce à cette mise à jour... ça restera un mystère.

 

[pomination]

Au moment de la lenteur, ça aurait pu être intéressant de voit l'état des tables innoDB : SELECT * FROM mysql.innodb_table_stats;
normalement, le analyze table n'est pas souvent nécessaire. Sauf, par exemple, dans le cas d'une suppression massive de données.

Toutefois, je crois me souvenir, qu'il est bon de programmer un analyze de temps, de façon récurrente, via cron ou autre. A voir selon les chutes de perfs, mais ça peut être mensuel ou trimestriel.

 

[colonies]

Bon, eh bien a priori, c'est bien ANALYZE TABLE qui sauve la mise.

Un composant de mon serveur a lâché et a laissé la db avec des tables crashées. Toutes les tables ayant des problèmes ont été réparées.
Au bout de quelques heures sont réapparus les entrées log "InnoDB: Memory pressure event freed" et les problèmes de lenteur.
J'ai refait des ANALYZE TABLE et je n'ai plus ces erreurs.
C'est tout ce que j'ai fait, je n'ai même pas redémarré mariadb, et il n'y a pas eu de mises à jour qui rendent les choses difficiles à interpréter.

Je croise les doigts, mais étant donné que ça a stoppé net le problème, je suis assez confiant.
Reste plus qu'à ouvrir un rapport de bug, mais en attendant, si quelqu'un transpire depuis des jours sur ce problème et tombe sur ce message...