Bonjour Mickael,
J'ai eu un problème sur ma base de données cette nuit, elle n'était plus accessible et dans les logs j'ai des erreurs comme :
08/07/2020 08:10stderr2020-07-08 8:10:08 140472076855040 [ERROR] mysqld: Disk full (/dev/shm/#sql_1_46.MAI); waiting for someone to free some space… (errno: 28 "No space left on device")
08/07/2020 08:12stderr2020-07-08 8:12:37 140473281234688 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
08/07/2020 08:12stderr2020-07-08 8:12:37 140473012860672 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
08/07/2020 08:12stderr2020-07-08 8:12:37 140472209819392 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
08/07/2020 08:12stderr2020-07-08 8:12:37 140472207668992 [Warning] mysqld: Retry in 60 secs. Message reprinted in 600 secs
Savez vous quel est le problème svp ?
Merci.
Cordialement,
Julien
Bonjour Julien,
Ton https://dev.mysql.com/doc/refman/5.7/en/temporary-files.html tmpdir était plein.
Le tmpdir est utilisé par MySQL / MariaDB pour stocker des fichiers temporaires. Par exemple, quand tu fais un ALTER, la nouvelle table (celle qui contient la modification demandée) est souvent réécrite entièrement dans le tmpdir, puis les données sont déplacées. Mais pas que. Il sert également à stocker des résultats temporaires, lors de SELECT, par exemple. C'est pour ça qu'on a besoin que le stockage qui se trouve derrière soit hyper performant.
Pour ce faire, on a placé le tmpdir par défaut… dans la RAM (/dev/shm/)!
Avantage: les perfs sont vraiment bonnes.
Inconvénient: la place est limitée.
Si jamais ça te bloque, on te donne la possiblité, via ton https://www.ovh.com/manager Control Panel de changer ça en basculant le tmpdir de /dev/shm vers /tmp/.
Avantage: la place est vraiment grande.
Inconvénient: moins de perfs que dans la RAM. À relativiser tout de même: le stockage derrière les CloudDB, c'est du NVMe. C'est vraiment très rapide.
Mikaël
Bonjour Mikaël,
Merci pour votre retour rapide.
Est il possible dans ce cas d'avoir un reboot automatique du serveur, il était indisponible de 3h jusqu'à je reboot vers 9h.
J'aurai du voir ma RAM à fond dans la partie Métriques ? Ce n'était pas le cas pour info.
Avec aussi pas mal de message "User xxxx already has more than 'max_user_connections' active connections"
Cordialement,
Julien
Bonjour Julien,
> Est il possible dans ce cas d'avoir un reboot automatique du serveur, il était indisponible de 3h jusqu'à je reboot vers 9h.
En te fournissant un service un mode SaaS, on te garantie que ton instance tourne, 24/24. Que tu ais du rebooter toi même l'instance n'est pas normal. 2 choses rendent mon diag' très compliqué:
- Les interventions que j'ai fait ces derniers jours. Elles changent pas mal de choses et remplissent les logs.
- Le flood d'erreurs "Got an error reading communication packets" et "Got timeout reading communication packets". Il y en a vraiment beaucoup (ça risque même d'impacter les perfs de ton instance, c'est dommage). Ils sont dus à un client qui ne ferme pas bien ses connexions. Tu pourrais regarder ce point?
> J'aurai du voir ma RAM à fond dans la partie Métriques ? Ce n'était pas le cas pour info.
Non. La taille du /dev/shm/ est limité à la moitié de la RAM. 1 Go pour toi, donc.
> Avec aussi pas mal de message "User strackrlocal already has more than 'max_user_connections' active connections"
Oui, c'est une conséquence du problème. L'opération qui a remplit le tmpdir a très probablement lock une table. Les connexions attendent que le lock parte (mais il ne part pas). Les connexions s'empilent. Le max_user_connections est atteint.
Mikaël
Bonjour Mikaël,
Je vais regarder pour les "Got an error reading communication packets" et "Got timeout reading communication packets", merci.
J'ai encore eu 2 problèmes hier, donc une avec une courbe assez étonnante :
Depuis quelques jours, je remarque des problèmes de performances par moment, je suis le seul ? De mon coté je n'ai pas changé grand chose et mon serveur répond bien.
Je suis passé sur /tmp depuis hier soir après le second problème avec la base de données.
Cordialement,
Julien
Mikaël,
J'ai bien diminué le nombre de warning si ca peux vous aider.
Cordialement,
Julien
J'ai bien diminué le nombre de warning si ca peux vous aider.
Ah oui, effectivement! =) On est passés d'environ 5500 logs "\*reading communication packets\*" par jour à environ 500.
une courbe assez étonnante
Oui, j'en parlais https://community.ovhcloud.com/t/32296 ici: depuis la mise en place de l'amélioration, les courbes ne sont plus parlantes. «Je vois pour trouver une métrique plus probante, voir pour écrire dans un guide ce qu'est exactement cette métrique et comment l'interpréter.»
Merci pour votre retour @MikaelD1, pour le moment je n'ai plus eu de souci.
Bonjour @MikaelD1,
C'est prévu la haute disponibilité comme Scaleway ou AWS proposent ? (https://www.scaleway.com/fr/database/)