/dev/shm c'est du RAM DISK donc en passant de 2Go à 4Go bah tu n'auras plus (ou moins) le problème de "No space left on device"
Rien à voir avec le nombre de CPU sauf si l'offre lie la RAM et le nombre de vCPU (je ne connais pas cette gamme cloudDB)
ce n'est pas normal que je dois redémarrer le serveur manuellement
Non je te confirme, ce n'est clairement pas normal qu'un serveur redémarre. Le seul redémarrage normal, c'est celui qui est fait pour mettre à jour ton instance d'une version mineure du DBMS à une autre. Pour info, ça arrive 5 à 10 fois par an en fonction des DBMS, et la coupure est généralement de moins de 5 secondes.
Dans ton cas, ton problème vient du `tmpdir`de MySQL/MariaDB qui est plein. Par défaut, on le fait pointer sur `/dev/shm` qui est, comme le dit @TTY, de la RAM. On a fait ça pour des raisons de performance(*). Si tu vas dans ton Control Panel, tu pourras changer cette conf, et le passer sur du disque, où tu as beaucoup plus de place.
(*) Pour être tout à fait transparent, ça avait un gain non négligeable à l'époque où les CloudDB étaient sur du disque plateau distant. Depuis qu'ils utilisent un stockage local en NVMe, les perfs des disques sont juste incroyables, et on s'interroge sur le fait de laisser cette option (qui a beaucoup moins d'avantages qu'avant et qui a l'inconvénient que tu décris).
/dev/shm c'est du RAM DISK
Pour être plus précis, c'est du tmpfs. Le RAM disk est au disque ce que le tmpfs est à la partition. En d'autres termes, tu peux formater un RAM disk (en ext4 par exemple), mais pas un tmpfs, sur lequel tu peux directement stocker tes fichiers. Dans les 2 cas, c'est de la RAM, effectivement.
Rien à voir avec le nombre de CPU sauf si l'offre lie la RAM et le nombre de vCPU (je ne connais pas cette gamme cloudDB)
Exact, l'offre CloudDB, telle qu'elle l'est actuellement, ne lie pas la RAM et le nombre de vCPU. Quelle que soit l'offre que tu prends, le calcul décrit dans https://community.ovhcloud.com/t/17147 ce commentaire reste valable.
Merci pour toutes ces précisions @MikaelD1.
Ça fait vraiment plaisir de voir le staff OVH intervenir ici.
Je ne comprend pas le "déport" du support qui répond sur Twitter et qui n'offre pas les outils pour trouver de quoi les dépanner, les éclairer que l'on trouve sur comunity (tous le monde n'est pas sur Twitter en plus). Bref c'est HS -> je sort.
Je viens d'optimiser les indexes sur 3 tables, une seule est réellement utilisée régulièrement mais je doute que cela soit le problème (200k entrée et peu de columns).
J'ai un peu plus d'espoir sur le passage à /tmp, je vais laisser tourner une semaine afin de voir les résultats.
Petite question, je ne retrouve plus cette offre dans le menu du site OVH, elle va disparaitre ?
Le changement est déjà flagrant, bien joué! \o/
je ne retrouve plus cette offre dans le menu du site OVH, elle va disparaitre ?
Ah non, pas du tout… La page est https://www.ovh.com/fr/cloud-databases/">ici. Honnêtement, j'avoue que c'est dur dur de s'y retrouver =/ Mais on est en train de vous préparer des p'tits truc franchement cool qui vont améliorer tout ça. Je ne vous en dit pas plus
Bon week-end tout le monde!
Merci beaucoup @MikaelD1
L'horaire c'est en UTC sur le chart ou horaire FR ? J'ai fait le switch vers /tmp à 8h et les indexes vers 12h (horaire FR).
> Ah non, pas du tout… La page est ici. Honnêtement, j'avoue que c'est dur dur de s'y retrouver =/ Mais on est en train de vous préparer des p'tits truc franchement cool qui vont améliorer tout ça. Je ne vous en dit pas plus
Super, bon week end!
C'est effectivement de l'UTC =)
Ok donc ca concorde avec les indexes, merci beaucoup ! (si on peut avoir ce chart dans le backoffice OVH ca serai top )
Normalement, tu y as déjà accès. Non seulement à la métrique du CPU, mais également plein plein (plein) d'autres.
Le guide pour récupérer les métriques est https://docs.ovh.com/fr/hosting/recuperer-les-metriques-dun-sql-prive-sur-grafana/ ici.
Merci @MikaelD1 , je vais regarder.
Un petit retour après mon congé, je n'ai plus eu de problème suite à la place de l'index manquant. Merci beaucoup @MikaelD1 pour ton aide !
Je pense qu'il faut mettre en avant le fait qu'il est possible de récupérer les slow queries dans le FTP directement dans le dashboard 