11 commentaires
exactement. le default sur des kernels plus anciens peut être cfq ou deadline qui sont pas du tout faits pour du ssd/nvme. passe en noop avec echo noop > /sys/block/nvme0n1/queue/scheduler et voit si ça stabilise
ok je suis en deadline là. je vais tester noop. par contre c'est une VM sur Proxmox avec un backend Ceph. ça change quelque chose ou l'OS invité doit quand même avoir noop ?
oui noop sur l'invité c le standard pour ce genre de setup. mais aussi vérifie le discard ou fstrim. si t'es sur un FS qui supporte trim et que ça se déclenche mal ou pas du tout ça peut accumuler de la garbage et ralentir les I/O à la longue
j'ai activé noop et ça semble déjà un peu mieux mais j'ai toujours des pics occasionnels. vous pensez aux tailles de blocs ? la db est configurée pour des blocs de 8k. l'OS est en 4k. ça peut créer du désalignement et des perfs pourries non ?
et aussi la taille de la queue I/O du device. /sys/block/nvme0n1/queue/nr_requests. Si c'est trop bas ça peut limiter les IOPS en parallèle. Tente d'augmenter ça ptete à 256 ou 512 si tu as beaucoup de requêtes concurrentes
ok j'ai checké l'alignement et c'était pas optimal. j'ai remonté la queue size et j'ai reconfiguré noop. les perfs sont vachement plus stables maintenant. la db respire mieux. merci pour les conseils précis !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la compagnie ! j'ai un souci de perf i/o super fluctuantes sur une VM prod (Debian 11 kernel 5.10) qui utilise des disques NVMe virtuels. Parfois c'est fulgurant et d'autres fois on a des latences de plusieurs dizaines de ms pour des petites écritures. C'est surtout visible sur des charges de type base de données. On dirait que le scheduler i/o fait n'importe quoi. Des idées pour optimiser ça ?