[1034] Create index by sort failed

[JulienH]

Merci pour les informations détaillées @MikaelD1 .

Je veux bien que les 2 requêtes soient exécutées par vous avec un dump avant svp, merci.
Mes clients attendent depuis une semaine.

Le crash du serveur quand on arrive à la limite de la mémoire c'est quelque chose que vous avez mise en place ?
Ca serait bien aussi de pouvoir redescendre d'offre comme le propose Azure ou AWS quand on à juste un besoin ponctuel.

[MikaelD1]

Voila qui est fait.

• 19:39: upgrade de ton instance à 2 Go de RAM.
• 19:40-19:41 CET: dump. Comme les autres, il est visible depuis ton Control panel (Manager).
• 19:42-19:43: mise en place de l'index:

Query OK, 2822240 rows affected (1 min 18.43 sec)      
Records: 2822240  Duplicates: 0  Warnings: 0

• 19:44-19:45: passage de l'alter:

Query OK, 2822284 rows affected (1 min 21.08 sec)      
Records: 2822284  Duplicates: 0  Warnings: 0

• 19:47: downgrade de ton instance à 1 Go de RAM (elle a redémarré proprement en 5 secondes environ).

Bonne soirée =)

Mikaël

[JulienH]

Bonjour @MikaelD1

Merci beaucoup !

Le bug sera corrigé prochainement ?
Hier j'ai fais quelques test avec Amazon RDS et il n'y a absolument aucun problème pour réaliser l'index et l'alter avec 1Go de RAM.

Je préfère OVH mais si je dois encore rester un mois à attendre une solution avec un support qui me dit qu'il n'y a aucun problème et d'aller chercher un Webmaster (je suis dev depuis 15 ans...) je n'aurai pas le choix...

Julien

[MikaelD1]

Le bug sera corrigé prochainement ?

Quand tu as besoin de 1.2 Go de RAM alors que tu n'en as que 1.0 de disponible, il n'y a pas beaucoup de choix possibles:
1. Soit tu swap,
2. Soit tu te fais OOM kill.
(Je le fais simple: il y en a d'autres peu applicables ici)

Ici, on a fait le choix 2., parceque le choix 1. a des avantages, mais également beaucoup d'inconvénients. Ce n'est donc pas un bug, mais un choix.

Après, je comprends ton problème, et comme je te disais, on y travaille. Les 3 pistes qu'on creuse sérieusement (ça avance beaucoup):

• Sortir le tmpdir du quota de RAM. Ça implique plein de problématiques techniques qu'on essaye d'adresser. Ça veut également dire qu'on vous ferait cadeau de RAM en plus, ou qu'il faut augmenter les prix. On ne souhaite pas augmenter les prix, on a donc un défi supplémentaire.

• Et si on revenait sur le choix 1. ou 2. (RAM ou OOM kill)? Vos instances tournent maintenant sur des monstres d'IOs (du NVMe). On peut se reposer la question.

Ca serait bien aussi de pouvoir redescendre d'offre comme le propose Azure ou AWS quand on à juste un besoin ponctuel.

• Oui, c'est la 3ème piste =)

Mikaël

[JulienH]

Merci Mikaël pour votre retour.

[MikaelD1]

La suite de l'histoire se passe ici =)

[JulienH]

Bonjour @MikaelD1, super, merci pour votre retour !

[JulienH]

Bonjour,

J'imagine que ce n'est pas toujours activé sur mon serveur, j'ai voulu faire un ALTER TABLE, obligé d'upgrader juste pour ça...

[MikaelD1]

Bonjour @JulienH,

Effectivement, la modif n'est pas encore passée sur ton serveur. J'ai mis à jour le thread pour expliquer un peu où on en est. Je continue avec toi en message privé pour te débloquer.

Mikaël

[JulienH]

Merci pour votre retour.
La MAJ sera disponible dans les prochaines semaines ou plutôt les prochains mois ?

Julien

[MikaelD1]

La mise à jour va commencer à être appliquée dans les prochaines semaines.

Le déploiement massif se terminera plus tard, dans les prochains mois.

[JulienH]

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

[MikaelD1]

Bonjour Julien,

Ton 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 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

[JulienH]

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

[MikaelD1]

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

[JulienH]

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

[JulienH]

Mikaël,

J'ai bien diminué le nombre de warning si ca peux vous aider.

Cordialement,
Julien

[MikaelD1]

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 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.»

[JulienH]

Merci pour votre retour @MikaelD1, pour le moment je n'ai plus eu de souci.

[JulienH]

Bonjour @MikaelD1,
C'est prévu la haute disponibilité comme Scaleway ou AWS proposent ? (https://www.scaleway.com/fr/database/)