Discussion :

[olivtone]

bonjour a tous

Question pour les experts sur PostgreSQL, vous est il déja arrivé de toucher le parametre f_sync ou autre option dans le fichier de config postgres.conf ?

Je m'explique parfois sur une machine Nous rencontrons des pb de performance apparement sur les IO (cela se produit qu'une fois par an lors de forte charge)

J'ai pas plus d'information pour le moment, je suis vraiment desole, juste pour la peche aux infos sur des DBA qu'ont eu ce genre de pb sur Postgres

Autre Question la Mise a jour de 9.6 vers 15.0 va t elle améliorer les performances (je sais la question est vague) ?

Merci a vous ^^

[SQLpro]

bonjour a tous

Question pour les experts sur PostgreSQL, vous est il déja arrivé de toucher le parametre f_sync ou autre option dans le fichier de config postgres.conf ?

ATTENTION danger.... Une base de données ce sont d'un côté des données, de l'autre des transactions. Les transactions sont écrite de manière synchrone par rapport aux modification apportées aux tables/index. Des marques de type LSN (log Segment Number) sont apportées dans les lignes des tables de manière à savoir à quelle transaction achevée et validé se rapprte telle ou telle information. En cas de désynchronisation (différentiel entre LSN des lignes et dernière transactions validé dans le journal) alors le SGBDR ne peut pas savoir quelles sont les lignes valides (il en garde plusieurs dan les pages de données. La base est alors considérée comme définitivement corrompue et plus aucune mie à jour n'est possible... Il faut reprendre la dernière sauvegarde et accepter de perdre les données intermédiaires... Donc, mettre f_sync à OFF va te faire gagner en IO sur le journal de transaction sachant que le risque est la perte de la base... Le jeu en vaut-il la chandele ? Sur une BD de prod critique, je dirais absolument NON !!!

À lire : https://postgresqlco.nf/doc/fr/param/fsync/

Pour améliorer les performances en IO, il existe différentes méthodes...

Si tu as plusieurs bases dans le même "cluster" (instance en fait) PostGreSQL, alors tu peut créer plusieurs instances avec chacune sa base. En effet, PostGreSQL n'utilise qu'un seul journal de transaction (constitué d'un seul fichier) contrairement à d'autres systèmes comme Microsoft SQL Server ou chaque base à son propre journal...

Tu peux aussi jouer sur les disques :

• Éviter absolument les disques virtuels. Mettre des disques physiques (c'est possible, même dans une VM avec le concept de "disk pass through").
• Jouer aussi sur les agrégats : éviter le RAID 5, RAID 6, RAID 50, RAID 60, RAID DP... Utiliser RAID 0 et RAID 1 et toutes combinaisons (0+1 ou 1+0)
• Ajouter plus de disques en parallèle
• Éviter les SANs mutualisés

Si tu étais sous Microsoft SQL Server tu pourrais utiliser le concept de journalisation asynchrone, car SQL Server ne passant pas par l'OS pour les lectures/écritures physique, cette journalisation te garantie l'intégrité de la base, au risque que les dernières transactions soient perdues, alors qu'elles semblaient validées (il faut dans ce cas, savoir ou l'on en est). Dans un tel cas, chaque transaction doit être marqué avec un "COMMIT TRANSACTION WITH ( DELAYED_DURABILITY = ON )...
Mais PostGreSQL est loin de valoir SQL Server !

A +

[olivtone]

Merci fred davoir pris ton temps de me repondre

Autre question : Postgres relache t il la mémoire qu'on lui donne comme sur SQL Server ?

merci encore

[SQLpro]

Normalement oui... Et pour la même raison que PG ne gère pas directement la RAM...

SQL Server ne relâche pas la RAM acquise, sauf sur demande expresse de l'OS... Ce qui peut poser problème !

A +