[1034] Create index by sort failed

Bonjour @JulienH,
Peux-tu nous donner un peu plus d'info: type et version du SGBD, voir son nom (ici ou à moi en MP)?
Pour info, qu'est-ce que tu stock dans ta table pour qu'elle fasse 2 millions d'entrées?
CloudDB n'est pas du tout abandonnée par OVHcloud, qu'est-ce qui te fait penser ça?
Mikaël

Bonjour @MikaelD1,

C'est une base de données MariaDB 10.2, je vous donne le nom en MP?

> Pour info, qu'est-ce que tu stock dans ta table pour qu'elle fasse 2 millions d'entrées?

Un suivi d’éventements, ce n'est pas fait pour stocker des millions de données ?

> CloudDB n'est pas du tout abandonnée par OVHcloud, qu'est-ce qui te fait penser ça?

Par exemple la dernière version de MariaDB n'est pas disponible.

Julien

J'ai bien reçu le nom de l'instance, merci.

Peux-tu me confirmer que tu as tenté de mettre l'index le 6 mars entre 10:11 et 10:30 CET? Si oui, la génération de l'index a demandé beaucoup plus de RAM que ton instance n'en a. Tu peux tenter de modifier ton tmpdir (dans ton Manager), et le passer de «/dev/shm» (en RAM, rapide mais limité en taille) à «/tmp» (sur disque, plus lent mais «illimité» en taille).

> Un suivi d’éventements, ce n'est pas fait pour stocker des millions de données ?

Si, bien sûr. Après, il y a des bonnes pratiques, typiquement, celle du découpage.

Pour illustrer ça, je prends toujours l'exemple parlant du nombre de fichiers dans un répertoire. Sur ext4, le nombre de fichiers que tu peux mettre dans un répertoire n'est limité que par le nombre de fichiers que tu peux mettre sur le file-system (généralement, 4 mille milliards). En pratique, il ne faut pas faire ça.

Pour les SGBD **relationnels** (c'est important), c'est un peu le même principe, on peut mettre des dixaines, centaines de millions de lignes dans une table. En pratique, je déconseille.

> C'est une base de données MariaDB 10.2

OK, je posais la question au cas où tu ulitisais PostgreSQL. Pour info, il propose l'excellent partitionnement expliqué https://www.postgresql.org/docs/12/ddl-partitioning.html ici.

Merci pour votre retour et désolé pour mon retour tardif.

Je viens d'essayer de passer sur /tmp, ca ne fonctionne pas, toujours le même message d'erreur au bout de 55 secondes environ.
L'onglet Logs à au moins 30 minutes de retard, ce n'est pas super pratique...

Même problème si j'essaie de faire un alter table ...
Je suis bloqué je ne peux même pas update mon application.

D’ailleurs je continu à avoir des alertes de dépassement de la mémoire alors que j'étais sur tmp (j'avais bien redémarré)

(Échanges en cours en message privé avec @JulienH ; On vous tiens au courant de nos investigations)

@JulienH, comme vu ensemble, j'ai bien reçu les 2 requêtes SQL que tu tentais de faire passer. Une pour mettre en place un index, l'autre pour faire un `ALTER TABLE`.

**Diagnostique**

J'ai d'abord recréé une instance MariaDB iso avec la tienne (même version, mêmes limites…) dans laquelle j'ai restauré ton dernier dump, afin de ne pas impacter ta production. J'ai reproduit le problème. Il est dû à la surconsommation mémoire des 2 requêtes.

Voici la consommation mémoire de l'instance de test lors de la première tentative de création d'index:



Les mesures sont faites toutes les 2 secondes. L'abscisse est exprimée en numéro de mesure (on voit donc que l'instance MariaDB crash au bout de 46 secondes). L'ordonnée est exprimée en Mo (ton instance fait 1 Go).

J'ai ensuite augmenté l'instance sur l'offre directement supérieure, à 2 Go, donc. Ici, la création de l'index se passe bien:



Le pic que tu vois est à 1088 Mo exactement. Il est sûrement monté un peu plus haut (ma granularité est de 2 secondes, il peut se passer plein de choses entre 2 mesures), mais en bref, tu n'étais pas loin.

Même principe pour l'alter. Les 2 courbes sont extrèmement similaires.

Juste pour information, les prises de mesures ont été faites avec:

`# while $(/bin/true)`
`> do`
`> echo "$(($(cat /sys/fs/cgroup/memory/memory.usage_in_bytes)/1024/1024))"`
`> sleep 2`
`> done`

Attention également, les tests ont été faits avec un tmpdir set à /tmp/ pour ne pas fausser les données. Il est possible qu'avec un tmpdir set à /dev/shm/ (dans la RAM, donc), tu ais besoin de plus de RAM que ~1.1 Go.

**Solution (individuelle) court terme**

Pour résoudre ton problème, en théorie tu devrais augmenter ton offre. En pratique, ça serait dommage de faire x2 sur ton instance (et x2 sur le prix par la même occasion) pour simplement passer 2 requêtes. Si tu le souhaites, je peux passer moi même les 2 requêtes sur ta production, en ayant pris soin d'augmenter la RAM avant (que je remettrais à 1 Go juste après). Donne moi ton GO si on part là dessus.

**Solution (généralisée) moyen terme**

Tu n'es pas le seul à avoir se besoin d'augmentation très ponctuelle de RAM. Nous en sommes bien conscients et on travaille dessus depuis plusieurs mois. On a des idées que nous sommes en train de tester (à fond). Vous avez tellement de besoins et d'utilisations différentes: le sujet est aussi complexe que passionant. Je pense qu'on a vraiment de belles choses qui devraient sortir à propos de la gestion de la mémoire. On vous tiens au courant ;)

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.

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

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

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

Merci Mikaël pour votre retour.

La suite de l'histoire se passe https://community.ovhcloud.com/community/fr/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb?id=community_question&sys_id=c734f18c81928210f0780f07683eb20f ici =)

Bonjour @MikaelD1, super, merci pour votre retour !

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

Bonjour @JulienH,

Effectivement, la modif n'est pas encore passée sur ton serveur. J'ai mis à jour le https://community.ovhcloud.com/community/fr/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb?id=community_question&sys_id=c734f18c81928210f0780f07683eb20f thread pour expliquer un peu où on en est. Je continue avec toi en message privé pour te débloquer.

Mikaël

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

Julien

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

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

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/community/fr/amelioration-de-la-gestion-de-la-memoire-sur-les-clouddb?id=community_question&sys_id=c734f18c81928210f0780f07683eb20f 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/)