Bonjour,
J'essai de faire des modifications sur une table qui fait à peu prés 2 millions d'entrée, j'ai eu du mal à créer un champs mais j'ai enfin réussi, par contre j'aimerai créer un index mais j'ai toujours cet erreur :
```
[1034] Create index by sort failed
```
Comment y remédier ?
Merci
ps: j'ai l'impression que CloudDB est abandonnée par OVH…
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/t/32296 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/t/32296 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.