Re: [pgsql-fr-generale] Différence entre PG 8.4 et 9.3 sur la configuration

Hello les amateurs d'éléphants !

Je cherche à vérifier les performances de PG 9.3 par rapport à notre
actuel 8.4 (intégration de CSV identiques, requêtes identiques, etc).
Pareil pour la conf. Mais les perfs en 9,3beta1 ne sont pas trés
bonnes. On suspecte la conf ou la VM.

Savez vous si la conf à changer pour la 9 sur la gestion des perfs ?
Si oui, avez vous des pointeurs intéressants ?

Merci d'avance.

Voici cette conf :

## Basic
fsync = on
autovacuum = off
synchronous_commit = off
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
data_directory = '/srv/postgresql/9.3/main'
hba_file = '/opt/conf/postgresql/9.3/main/pg_hba.conf'
ident_file = '/opt/conf/postgresql/9.3/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.3-main.pid'
unix_socket_directories = '/var/run/postgresql/'

## Advance
shared_buffers = {{20|percent_of_ram}}MB
effective_cache_size = {{60|percent_of_ram}}MB
wal_buffers = {{0.1|percent_of_ram}}kB
temp_buffers = {{0.5|percent_of_ram}}MB
work_mem = {{4|percent_of_ram}MB
maintenance_work_mem = {{not_below(8, to_M(percent_of_ram(0.25)))}}MB
wal_writer_delay = 2000ms
max_stack_depth = 6MB
max_connections = 64
max_prepared_transactions = 0
max_locks_per_transaction = 2048
checkpoint_segments = 64
checkpoint_timeout = 3600
default_statistics_target = 300

## Advance (exemple avec 8Go de RAM)
shared_buffers = 1601MB
effective_cache_size = 4803MB
wal_buffers = 8005kB
temp_buffers = 40MB
work_mem = 320MB
maintenance_work_mem = 20MB
wal_writer_delay = 2000ms
max_stack_depth = 6MB
max_connections = 64
max_prepared_transactions = 0
max_locks_per_transaction = 2048
checkpoint_segments = 64
checkpoint_timeout = 3600
default_statistics_target = 300

## Profiling
logging_collector = on
log_min_duration_statement = 0
log_line_prefix = '%t [%p]: [%l-1] '
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
log_directory = '/var/log/postgresql'
log_filename = 'postgresql-9.3-main-full.log'
log_truncate_on_rotation = off

--
Sebastien Douche <sdouche(at)gmail(dot)com>
Twitter: @sdouche / G+: +sdouche

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 09/09/2013 18:42, Sebastien Douche a écrit :
> Hello les amateurs d'éléphants !

Bonsoir Sébastien,

De nombreux paramètres ont été modifiés, mais à vue de nez, rien qui explique
une baisse de performance. En revanche, j'ai relevé quelques pistes
d'amélioration dans votre configuration.

>
> Je cherche à vérifier les performances de PG 9.3 par rapport à notre
> actuel 8.4 (intégration de CSV identiques, requêtes identiques, etc).
> Pareil pour la conf. Mais les perfs en 9,3beta1 ne sont pas trés bonnes.
> On suspecte la conf ou la VM.
>
> Savez vous si la conf à changer pour la 9 sur la gestion des perfs ? Si
> oui, avez vous des pointeurs intéressants ?
>
> Merci d'avance.
>
> Voici cette conf :
>
> ## Basic fsync = on autovacuum = off

A on, c'est préférable. Sauf bonne (et temporaire) raison.

> synchronous_commit = off

Pareil.

> lc_messages = 'C' lc_monetary = 'C' lc_numeric = 'C' lc_time = 'C'
> data_directory = '/srv/postgresql/9.3/main' hba_file =
> '/opt/conf/postgresql/9.3/main/pg_hba.conf' ident_file =
> '/opt/conf/postgresql/9.3/main/pg_ident.conf' external_pid_file =
> '/var/run/postgresql/9.3-main.pid' unix_socket_directories =
> '/var/run/postgresql/'
>
> ## Advance shared_buffers = {{20|percent_of_ram}}MB

Je lis 20% de la RAM, est-ce correct ?

> effective_cache_size = {{60|percent_of_ram}}MB wal_buffers =
> {{0.1|percent_of_ram}}kB

Laisser la valeur par défaut, elle est obtenu en fonction des shared_buffers.

> temp_buffers = {{0.5|percent_of_ram}}MB work_mem = {{4|percent_of_ram}MB
> maintenance_work_mem = {{not_below(8, to_M(percent_of_ram(0.25)))}}MB

128 MB à 512 MB

> wal_writer_delay = 2000ms max_stack_depth = 6MB max_connections = 64
> max_prepared_transactions = 0 max_locks_per_transaction = 2048
> checkpoint_segments = 64 checkpoint_timeout = 3600
> default_statistics_target = 300
>
> ## Advance (exemple avec 8Go de RAM) shared_buffers = 1601MB
> effective_cache_size = 4803MB wal_buffers = 8005kB temp_buffers = 40MB
> work_mem = 320MB

Cela me semble élévé si 64 clients simultanés.

> maintenance_work_mem = 20MB

Beaucoup trop faible.

> wal_writer_delay = 2000ms max_stack_depth = 6MB max_connections = 64
> max_prepared_transactions = 0 max_locks_per_transaction = 2048
> checkpoint_segments = 64 checkpoint_timeout = 3600
> default_statistics_target = 300
>
> ## Profiling logging_collector = on log_min_duration_statement = 0
> log_line_prefix = '%t [%p]: [%l-1] ' log_checkpoints = on log_connections
> = on log_disconnections = on log_lock_waits = on log_temp_files = 0
> log_directory = '/var/log/postgresql' log_filename =
> 'postgresql-9.3-main-full.log' log_truncate_on_rotation = off

- --
Stéphane Schildknecht
http://www.Loxodata.com
Contact régional PostgreSQL
http://bistri.me/sas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSLixaAAoJECIy/X6KSrGwiMkH/1GL1j1QYXLAPG71Ri6zd7JH
sIq3vHihR1ussMzu5m4dLyVskjqQSOxkVTFFt+ribb5Gi+KTQXEsw0taS6FdBKL2
wVr+aIgWBYVrNuiRpHlXxLnrEIYqU2ZvgnvAiO/DSe5Ta25/d2kUMtDtL223sr79
hmarME32Pmwlh7Mvrx+xefmyxlZ4/GmSyusxZdrTS+SNH+UjhRdFe/C2dFCdneFv
leJ16VLoThwGW97Zx+jtAUyh74Un3dgvMGdBF56SueGzO218/Y9MmGlX6y5wzCu1
SEFbAfyF0+qupUyVDuMmHUGrb26gjjCh1PHrTGFMWM4vgmn25Vf1QEgbRwbwrgU=
=KGV7
-----END PGP SIGNATURE-----

Bonsoir

> Je cherche à vérifier les performances de PG 9.3 par rapport à notre
> actuel 8.4 (intégration de CSV identiques, requêtes identiques, etc).
> Pareil pour la conf. Mais les perfs en 9,3beta1 ne sont pas trés
> bonnes. On suspecte la conf ou la VM.

vous devriez tester avec la version stable (sortie aujourd'hui), entre autre il y a un patch sur la création des fichiers WAL qui a été annulé.
Cela impacte peut-etre être tout particulièrement vos tests si vous ré-iniitialisez le dossier des données (initdb) avant chaque test.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

2013/9/9 Cédric Villemain <cedric(at)2ndquadrant(dot)com>:

> vous devriez tester avec la version stable (sortie aujourd'hui), entre autre il y a un patch sur la création des fichiers WAL qui a été annulé.
> Cela impacte peut-etre être tout particulièrement vos tests si vous ré-iniitialisez le dossier des données (initdb) avant chaque test.

Hello,
en fait c'était bien la VM qui semble poser soucis, sur la même VM PG
9.3b1 se comporte bien mieux. Je continue mes investigations, je vous
tiendrais au courant des résultats.

Ceci dit, je suis toujours intéressé par des pointeurs sur les
changements de conf pour PG9 :).

--
Sebastien Douche <sdouche(at)gmail(dot)com>
Twitter: @sdouche / G+: +sdouche

On Mon, Sep 9, 2013 at 6:42 PM, Sebastien Douche <sdouche(at)gmail(dot)com> wrote:
> Je cherche à vérifier les performances de PG 9.3 par rapport à notre
> actuel 8.4 (intégration de CSV identiques, requêtes identiques, etc).
> Pareil pour la conf. Mais les perfs en 9,3beta1 ne sont pas trés
> bonnes. On suspecte la conf ou la VM.

Bonjour,
ceci est un petit retour sans prétention sur nos tests entre PG8.4 et
PG9.3b1 (mais qui semble identique à la 9.3).

* Machine de test
- VM sur KVM
- 4 coeurs
- 8Go de RAM
- Entre chaque test : sync ; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

J'ai utilisé pgbadger et sysstat pour récuperer les infos.

* Scénario 1
Intégration de 310 CSV. La base intègre en permanence des CSV venant
de notre sniffer et aggrège les infos (d'ou des select / insert /
update)

* Scénario 2
Rapport de notre produit avec 13 vues, ce rapport fait de grosses
requetes qui prends du temps (jusqu'a 20s alors que la base est toute
petite, que des select).

* Résultats :
- PG 9.3 ~ +15% pour les INSERT
- PG 9.3 ~ +5% pour les SELECT (et semble prendre moins de CPU)

Je suis déçu par le résultat cat on espérait plus de perf vu qu'on
commence à être sérieusement limité de ce coté la (chez certains
clients, on dépasse 10 min sur certaines requêtes). Même avec une
machine de guerre (un de nos clients possède 1Tb en SSD, 192Gb RAM).
On est foncièrement mono-utilisateur. donc les apports multi-coeurs
n'apportent rien pour nous.

Notre configuration est sûrement perfectible (nous ne sommes pas des
DBA) mais peut être est on à la limite de ce que le modèle relationnel
est capable de nous offrir et devriez nous peut être nous limiter
(voir changer de type de base).

A suivre.

--
Sebastien Douche <sdouche(at)gmail(dot)com>
Twitter: @sdouche / G+: +sdouche

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 25/09/2013 17:05, Sebastien Douche a écrit :
> On Mon, Sep 9, 2013 at 6:42 PM, Sebastien Douche <sdouche(at)gmail(dot)com>
> wrote:
>> Je cherche à vérifier les performances de PG 9.3 par rapport à notre
>> actuel 8.4 (intégration de CSV identiques, requêtes identiques, etc).
>> Pareil pour la conf. Mais les perfs en 9,3beta1 ne sont pas trés bonnes.
>> On suspecte la conf ou la VM.
>
> Bonjour, ceci est un petit retour sans prétention sur nos tests entre
> PG8.4 et PG9.3b1 (mais qui semble identique à la 9.3).
>
> * Machine de test - VM sur KVM - 4 coeurs - 8Go de RAM - Entre chaque test
> : sync ; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
>
> J'ai utilisé pgbadger et sysstat pour récuperer les infos.
>
> * Scénario 1 Intégration de 310 CSV. La base intègre en permanence des CSV
> venant de notre sniffer et aggrège les infos (d'ou des select / insert /
> update)
>
> * Scénario 2 Rapport de notre produit avec 13 vues, ce rapport fait de
> grosses requetes qui prends du temps (jusqu'a 20s alors que la base est
> toute petite, que des select).
>
> * Résultats : - PG 9.3 ~ +15% pour les INSERT - PG 9.3 ~ +5% pour les
> SELECT (et semble prendre moins de CPU)
>
>
> Je suis déçu par le résultat cat on espérait plus de perf vu qu'on
> commence à être sérieusement limité de ce coté la (chez certains clients,
> on dépasse 10 min sur certaines requêtes). Même avec une machine de guerre
> (un de nos clients possède 1Tb en SSD, 192Gb RAM). On est foncièrement
> mono-utilisateur. donc les apports multi-coeurs n'apportent rien pour
> nous.

Bonsoir Sébastien,

Je comprends votre frustration, mais votre courriel laisse à penser que
PostgreSQL 9.3 offre peu de gain, voire apporte des régressions en terme de
performances.

Malheureusement, les informations fournies ne nous laissent que peu de chance
de vous aider à infirmer cette conclusion.

>
> Notre configuration est sûrement perfectible (nous ne sommes pas des DBA)
> mais peut être est on à la limite de ce que le modèle relationnel est
> capable de nous offrir et devriez nous peut être nous limiter (voir
> changer de type de base).

Il manque beaucoup de variables à l'équation pour nous permettre d'apprécier
vos propos.

Meilleures salutations,

- --
Stéphane Schildknecht
http://www.Loxodata.com
Contact régional PostgreSQL
http://bistri.me/sas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSQ2ERAAoJECIy/X6KSrGwjn4IAINYwYWEesCU3EwUOwp+2Hid
pfRhiXazUVH0f5OdDdwUbiR2kXlwGZ5dzuZt2r5rNrJhpkF1GaW4U3uKDxupOTIV
Ie9a0eYyk2cs96E9wUB8/cQomUTMiYRQHRTX+rlZpi2U7dirms6Ck2dVs523FHeC
8w3xGXPsbQ9bKFuBsE6Zeyl2MYZoqP4vq7DHPf2UWHp/jbs7+TJdpWklOPgp+Ha1
4JDFpXn05R8GkOB9Z/tSEQQ61iR/CrAo4bRV+rc3JcrSmPDEV+Cwi6fcTLAz6KYb
Kcn8EayfEMkWS2Y3zHOPG/FQV/MiVGfHI66mTLM8V7xqWc3j2PK9CzBTBp2+wrA=
=ss/z
-----END PGP SIGNATURE-----

2013/9/26 Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr>:
> Je comprends votre frustration, mais votre courriel laisse à penser que
> PostgreSQL 9.3 offre peu de gain, voire apporte des régressions en terme de

Peu de gains dans le cas précis de ces benchmarks (on connait tous la
difficulté de faire des benchmarks de qualité) qui correspond à notre
utilisation de PG.

> Malheureusement, les informations fournies ne nous laissent que peu de chance
> de vous aider à infirmer cette conclusion.

Ce n'était pas le but :). J'avais juste dit que je faisais un petit retour.

--
Sebastien Douche <sdouche(at)gmail(dot)com>
Twitter: @sdouche / G+: +sdouche