Je ne connais pas ton applis, mais l'utilisation de transaction améliore significativement les performances. Tu regroupes plusieurs requêtes d'écriture dans une transaction. Il y a ainsi moins d'appel à fsync().
Pour améliorer de façon assez fabuleuse les performances en écriture de postgresql, tu peux désactiver sur le serveur PostgreSQL l'appel à fsync(). Par contre en cas de coupure de courant ou autre, tes données peuvent ne plus être cohérentes entre le serveur et le/les clients. Exemple :
- Client : Demande une place pour le train Paris-Lyon
- Serveur : retourne un numéro de place au client et écrit la réservation dans la base de donnée. La réservation sera définitivement écrite sur le disque dur une peu plus tard à la discrétion de l'OS.
- Coupure de courant : La réservation n'avait pas encore été écrite sur le disque dur.
- Retour courant : boot serveur.
On a maintenant un client bien réel qui a acheté la place 20 du train Paris-Lyon alors que cette information n'est pas écrite en base de donnée. La place 20 peut maintenant être vendue une seconde fois...
Si ton appli n'a pas ce type de problématique, que tu n'as pas de plantage et dispose d'un régulateur, alors tu peux envisager de désactiver l'appel à fsync().
[^] # Re: Sortie de PostgreSQL V7.3
Posté par matiasf . En réponse à la dépêche Sortie de PostgreSQL V7.3. Évalué à 2.
Je ne connais pas ton applis, mais l'utilisation de transaction améliore significativement les performances. Tu regroupes plusieurs requêtes d'écriture dans une transaction. Il y a ainsi moins d'appel à fsync().
Pour améliorer de façon assez fabuleuse les performances en écriture de postgresql, tu peux désactiver sur le serveur PostgreSQL l'appel à fsync(). Par contre en cas de coupure de courant ou autre, tes données peuvent ne plus être cohérentes entre le serveur et le/les clients. Exemple :
- Client : Demande une place pour le train Paris-Lyon
- Serveur : retourne un numéro de place au client et écrit la réservation dans la base de donnée. La réservation sera définitivement écrite sur le disque dur une peu plus tard à la discrétion de l'OS.
- Coupure de courant : La réservation n'avait pas encore été écrite sur le disque dur.
- Retour courant : boot serveur.
On a maintenant un client bien réel qui a acheté la place 20 du train Paris-Lyon alors que cette information n'est pas écrite en base de donnée. La place 20 peut maintenant être vendue une seconde fois...
Si ton appli n'a pas ce type de problématique, que tu n'as pas de plantage et dispose d'un régulateur, alors tu peux envisager de désactiver l'appel à fsync().