perf postgres pour du datamart sur une vm linux lente

Question

salut les pros, on a une vm linux (ubuntu 20.04) avec postgresql 14 dessus qui sert de datamart pour de l'analytics. on ingère des gigas de données toutes les nuits, puis on fait des requêtes complexes avec pas mal de joins et d'agrégations. le truc c'est que les perfs sont aux fraises, surtout pendant l'ingestion et les rebuild d'index. le disque est un ssd local sur la vm, pas du réseau. j'ai déjà tuné le postgresql.conf mais le bottleneck semble plus bas niveau.

-- Exemple de requête qui prend des plombes
SELECT date_trunc('day', transaction_time) as jour,
       sum(amount) as total_ventes
FROM sales
JOIN products ON sales.product_id = products.id
WHERE transaction_time >= now() - interval '1 month'
GROUP BY 1
ORDER BY 1;

stephanie74 · Answer

hello. t'as vérifié quel I/O scheduler ton kernel utilise ? (cat /sys/block/sdX/queue/scheduler). pour du SSD le plus souvent c'est noop ou deadline le meilleur. cfq est nul pour ça.

jerome38 · Answer

je suis en cfq. j'ai jamais touché à ça. j'essaie de passer en noop. ça va changer le comportement du disque direct ou faut rebooter ?

marty-renee · Answer

ça change à chaud avec echo noop > /sys/block/sdx/queue/scheduler. pas besoin de reboot. par contre faut le rendre persistant dans grub ou udev rules. et tu utilises quelle taille de bloc sur ton filesystem ext4 ? la taille du bloc postgres correspond ?

adrien-bonneau · Answer

un autre truc important c'est le swappiness. pour une base de données tu veux que ça swap le moins possible. check cat /proc/sys/vm/swappiness. si c'est haut, mets-le à 1 ou 10. et les options de montage de ton filesystem ? noatime ?

jerome38 · Answer

j'ai mis swappiness à 10. il était à 60. et j'ai monté le disque avec noatime. je viens de passer l'i/o scheduler en noop. ça a l'air un peu plus réactif. mais les phases d'ingestion restent longues. on utilise pas du direct i/o. ptete qu'il faut forcer postgres à utiliser O_DIRECT pour bypasser le cache du kernel pour les gros fichiers ?

stephanie74 · Answer

oui exactement ! pour des bases de données avec leur propre cache (genre postgres buffer cache) tu veux souvent utiliser O_DIRECT pour éviter le double caching (kernel + postgres) qui peut être contre-productif. ça se configure dans postgresql.conf via data_sync_retry = on ou en utilisant fsync correctement. mais surtout, l'os cache peut être désactivé au niveau du mountpoint avec -o directio si ton fs le supporte.

marty-renee · Answer

attention avec directio sur le mountpoint ça peut impacter d'autres applications sur le même disque. regarde si tu peux pas gérer ça au niveau de la config postgres directement ou via des libs spécifiques si c'est possible.

jerome38 · Answer

ok je vais chercher les options postgres. mais pour le moment le changement de scheduler et le swappiness ont déjà donné un petit coup de boost. on a un système de sauvegarde qui fait des snaphots tous les jours, ptete ça aussi ça impacte les IOPS pendant la nuit.

adrien-bonneau · Answer

les snapshots sur VM ça freeze les i/o pour un court instant, mais ça devrait pas impacter la perf en continu. sauf si t'as une infra de snapshot vraiment chelou. vérifie tes logs dmesg pour voir si t'as des messages de latence disque importants à ce moment-là.

jerome38 · Answer

bon j'ai configuré postgres pour utiliser wal_sync_method = fdatasync et j'ai re-testé. le noop + swappiness 10 + noatime + fdatasync c'est le combo gagnant. les ingestions sont bien plus rapides, et les requêtes moins. merci beaucoup pour l'aide, c'était super utile !

stephanie74 · Answer

top ! fdatasync c'est une bonne option pour éviter le double buffering et s'assurer que les données sont bien sur disque sans attendre un full sync. content que ça ait marché !

perf postgres pour du datamart sur une vm linux lente

Commentaires

Laisser une réponse

Value Stream Management: Du Code à la Valeur en Temps Record

Les bases fondamentales de l'affichage graphique en SDL2

DevOps et méthodologie Agile

Rejoindre la communauté