Vous n'êtes pas identifié(e).
Pages : 1
Bonjour et merci pour ce retour.
C'est bien ce que je craignais. Dommage.
Bonjour,
Sur Oracle (désolé) on a un truc qui permet de déclencher des commits automatiquement mais pas à chaque transaction. Plutôt toutes les 4000 transactions par exemple. On tape autocommit 4000. C'est pratique pour les batchs ; ça évite que le serveur ne passe son temps à gérer des commits d'une seule ligne. Du coup ça améliore franchement les perfs.
Je n'ai pas réussi à trouver l'équivalent sur PostgreSQL... quelqu'un pourrait m'éclairer svp ?
Complément d'info contextuel : je fais cela dans le cadre d'un comparatif de perf entre les 2 sgbd. Donc je voudrais être certain d'être bien optimisé des 2 côtés.
Merci d'avance
Jérôme
Merci, c'est bien ce que je craignais...
La perte de perf serait de quel ordre de grandeur ? 10% ? x2 ? x10 ?
On ne cherche pas forcément à être au top et 20% de perte de perf serait acceptable. Si c'est x2, c'est une autre histoire....
Je ne suis pas expert de vmware mais on me dit que, si on utilise les LUN mappés, on se priverai de certaines fonctionnalités de vmware comme les snapshots ou le déplacement de VM. D'un autre côté il me semble que les snapshot sont aussi pénalisants pour les perf. donc pas indiqué pour un SGBD.
Jérôme
Bonjour la Communauté
J'imagine que nombre d’entre vous se sont posé la question :
- est-ce que je mets mes tablespaces sur un disque virtuel géré par la couche vmware (mdk) ?
- ou bien est-ce que je court-circuite cette couche en mappant directement des LUNs de ma baie de stockage ?
Pourtant je n'ai pas trouvé de discussion sur ce thème...
Je vois deux problèmes que la couche vmware pourrait poser :
- non respect des écriture synchrones (fsync = on)
- ralentissement (en particulier lors des écritures synchrones)
Qui a un retour d'expérience sur ce sujet ? quelles sont les bonnes pratiques ?
Merci pour vos avis
Jérôme
DBA
Pages : 1
