Plantage régulier mysql

[achtungbaby]

Depuis hier matin, mon serveur plante coup sur coup toutes les 4 heures.

Enfin Mysql plante, et je suis obligé de le redemarrer.

Hier, je n'arrivais quasiment pas à accéder à SSH, m'obligeant à demander un reboot de la machine. La mémoire du serveur a été changé par l'hebergeur, mais ce matin rebelotte mysl est tombé.

La j'arrive à me connecter via ssh sans probleme, et je relance mysql... mais ça va tenir combien de temps.

Je ne comprend pas ce qui se passe, ça tournait bien jusqu'alors donc pourquoi d'un coup mysql ne répond plus ?

Le serveur tourne sous FreeBSD avec apache 2 et mysql 4.1

[loletech]

Quand tu dis que MySQL plante, tu veux dire que le process tombe ou bien qu'il est bien là mais qu'il ne répond plus parceque la machine est trop occupée à faire on ne sait quoi ?

Si c'est la deuxième option, peut-être certaines grosses requêtes font-elles swapper ta machine alors que ce n'était pas le cas avant (tables plus grosses, plus d'utilisateurs concurrents ...). Dans ce cas, il faut soit plus de mémoire soit optimiser tes requêtes soit ... moins d'utilisateurs (non, je déconne)

[achtungbaby]

Le process tombe en fait. Pour la charge serveur, elle est tres faible.

C'est un athlon 64 avec 512 Mo de ram, je pense que ça doit quand meme tenir la charge. Au niveau requete, je pense que c'est ok car sur un mutu on a tenu le choc des 15.000 visiteurs sur une journée, donc sur un dédié ça doit tenir plus.

[loletech]

Si c'est un vrai plantage, il faut te demander ce que tu as pu changer récemment :
changement de version (MySQL, PHP ... autre), modif de paramètres système, ajout de modules apache ou PHP que tu n'utilisais pas jusque là, update de certains packages linux ...

Ca peut éventuellement aussi venir de nouveaux types de requêtes ou de fonctionnalités MySQL que tu n'utilisais pas jusque là et qui seraient buggés.

[achtungbaby]

Les dernieres MAJ systemes datent de samedi matin, donc le dédié a tourné normalement jusqu'à jeudi matin. J'ai pas l'impression que ça vient d'une mise à jour de ports.

Pour les scripts, pareil hormis des modifs d'affichages dans des scripts php, sans interventions ni conséquences sur les tables.

J'ai vraiment du mal a établir la raison de ces plantages.

[loletech]

Est-ce que tu as cherché dans les logs pour trouver des messages d'erreurs ?

[achtungbaby]

Rien trouvé, rien d'anormal. Ce soir ça a encore laggué, interruption de quelques secondes. Enfin la on a ajouté un service dans webmin pour redémarrer mysql au cas ou il tombe, ce qui évite que le site reste down jusqu'à ce qu'on s'en aperçoive.

Et pas de traffique particulier. La on nage dans la twilight zone.

On va tenter une maj globale des ports.

[shrom]

As-tu pensé à vérifier si tes tables ne sont pas endommagées ?

[loletech]

Tu peux aussi vérifier si tu n'as pas de blocs défectueux sur ton disque.

[achtungbaby]

à shrom : j'ai fait une réparation des tables par précaution, j'avais pensé.

à loletech : non on n'a pas vérifié de ce coté la.

Sinon, aujoud'ui on a re-subi un plantage. Un peu différent, sites inaccessibles. et acces ssh impossible.

On a redemandé un reboot du serveut (ça commance à faire beaucoup...

Et la après reboot, plus d"accé ssh. La on est mal. heureusement webmin fonctionne et on a pu réinstaller ssh, et on a pu se reconnecter.

Une panne matériel au niveau de l'alimentation pourrait-elle provoquer ce genre de problemes ? genre microcoupures

[loletech]

Oui c'est possible. Mais si c'est une panne matérielle, parierais plutôt pour la mémoire ou la carte mère (le contrôleur disque surtout).

[achtungbaby]

Merci de m'aider à solutionner le probleme.

Bon on a collé quelques outils d'analyses pour cherche l'origine, et tracer la panne.

On sait maintenant pourquoi Mysql plante. Le swap disponible diminue fortement à 8 heure du matin, et fait planter Mysql.

On a regardé si il y avait une tache qui s'exécutait à cette heure la, et... Ben rien, on ne sait pas pourquoi. Du coup on a augmenté la taille du swap, et on monitore en continu pour trouver la faille.

[loletech]

Si c'est tous les jours à 8 heures précises, c'est qu'il y a bien quelquechose qui se déclenche à cette heure là.

Est-ce que tu as regardé les crontabs de tous les users suceptibles de déclencher des choses sur ta machine : root, apache, mysql, tes autres users applicatifs ...

Bon courage

[achtungbaby]

Il n'y a justement aucun crontab qui se déclenche à cette heure la.

[achtungbaby]

Bon, replantage hier soir... entre 16h et 17h

Difficile d'accéder par ssh (pourquoi ? mystère).

Lancement du reboot de mysql, résultat : NUL

Conclusion, le énième reboot de la machine depuis jeudi.

Dernières analyse des logs et de tout notre "appareillage" de contrôle du Serveur.

Au départ, on pensait que le swap faisait planter mysql. Aujourd'hui on s'oriente sur l'inverse. Mysql s'affole, et vient utiliser de façon gargantuesque le swap, jusqu'à faire lagguer le serveur.

Notre théorie :
Mysql se plante lamentablement suite au lancement d'un script, ou l'utilisation de plusieurs scripts php.

Constation, certains scripts présentent des dysfonctionnements avec des variables, variables utilisées pour des requetes mysql. Nous pensons que la requete envoi des éléments 'vides' dans la requete, provoquant une boucle mysql en continue, et qui au bout d'un moment génère des connexions fantomes.

Les requetes concernées utilises des variables, genre limit, page, etc... Ces scripts n'utilisent pas $get pour envoyer les variables. Alors que les memes scripts fonctionnent parfaitement sur un mutualisé. Pour palier à ce probleme, je suis obligé de modifier le script de la façon suivante :

$page=$_GET['page'];
$limit=$_GET['limit'];
$ordre=$_GET['ordre'];

Ce problème, à mon avis, vient d'un mauvais paramétrage de php. Quel serait le paramétre manquant ?