Re: Pb de perf sur une grosse base

Valérie,

Le jeudi 5 Août 2004 10:32, Valerie Schneider DSI/DEV a écrit :
> J'ai recréé ma table avec des types integer et real plutôt
> que numeric.
> Tout se trouve amélioré :
> schema | relfilenode | table | index | reltuples |
> size
> --------+-------------+------------------+------------+-------------+------
>---- public | 253442696 | data | | 1.25113e+08 |
> 29760016 public | 378639579 | data | i_data_dat | 1.25113e+08
> | 2744400 public | 378555698 | data | pk_data |
> 1.25113e+08 | 3295584 La table occupe 28 Gb au lieu de 68 Gb !

C'est un grand mieux ... ;o)

> Pour mes différentes requêtes, c'est nettement mieux mais pas encore ça :
> oracle PG hier (numeric) PG aujourd'hui (integer/real)
> Q1 <1s <1s <1s
> Q2 3s 8s 4s
> Q3 8s 1m20s 27s
> Q4 28s 17m20s 6m47s

Attention à une chose tout de même il ne faut pas s'attendre à obtenir les
temps de réponse d'Oracle avec PostgreSQL dans tous les cas ... mais on peut
peut-être améliorer la chose ...

> Le résultat du EXPLAIN ANALYZE :
>
> Q1 :
> Q2 :

On laisse tomber Q1 et Q2 qui semblent bonnes OK ?

> Q3 : bench=> explain analyze select 'Q3',sum(rr1),count(ff) from data where
> num_poste in (50,50+2);
> QUERY PLAN
> ---------------------------------------------------------------------------
>----- Aggregate (cost=963455.87..963455.87 rows=1 width=8) (actual
> time=27668.666..27668.667 rows=1 loops=1)
> -> Index Scan using pk_data, pk_data on data (cost=0.00..962236.31
> rows=243910 width=8) (actual time=16.251..27275.468 rows=250226 loops=1)
> Index Cond: ((num_poste = 50) OR (num_poste = 52))
> Total runtime: 27673.837 ms
> (4 rows)
>
>
> Q4 : bench=> explain analyze select 'Q4',count(*) from data where num_poste
> between 600 and 625;
> QUERY PLAN
> ---------------------------------------------------------------------------
>----- Aggregate (cost=14086174.57..14086174.57 rows=1 width=0) (actual
> time=428235.024..428235.025 rows=1 loops=1)
> -> Index Scan using pk_data on data (cost=0.00..14076910.99
> rows=3705431 width=0) (actual time=45.283..424634.826 rows=3252938 loops=1)
> Index Cond: ((num_poste >= 600) AND (num_poste <= 625))
> Total runtime: 428235.224 ms
> (4 rows)

Je ne sais pas si c'est vraiment pertinent mais il semble que l'index utilisé
pour ces deux requêtes est le double index ... est-ce que tu peux créer un
seul index sur le champs num_poste ... disons que la taille de l'index sera
plus petite sur le disque et que les accès risquent de s'en ressentir ...
Contrôle avant si un explain t'indique bien l'utilisation de ton nouvel index
sinon ça ne sert à rien ...

Si cela ne fonctionne pas ... (mais je suis intéressé par le résultat dans
tous les cas ...) alors il va falloir regarder du côté des options de
PostgreSQL parce qu'on peut difficilement optimiser les requêtes en tant que
tel.

Si un point aussi au niveau de la requête Q4, est-ce que tu peux faire un
count(num_poste) plutôt qu'un count(*) ... Ca joue sous Oracle, mais là je ne
sais plus si ca à un intérêt sous PostgreSQL, mais c'est pas plus mal de
prendre de bonnes habitudes ... :o)

> Concernant les paramètres de postgresql.conf :
>
> # - Memory -
>
> shared_buffers = 30000 # min 16, at least max_connections*2, 8KB
> each #sort_mem = 1024 # min 64, size in KB
> sort_mem = 5000 # min 64, size in KB

Est-ce que tu as constaté des écarts de vitesse entre 50000 d'hier et les
5000 ?

> #vacuum_mem = 8192 # min 1024, size in KB
>
> # - Free Space Map -
>
> #max_fsm_pages = 20000 # min max_fsm_relations*16, 6 bytes each
> #max_fsm_relations = 1000 # min 100, ~50 bytes each
>
> # - Planner Cost Constants -
>
> #effective_cache_size = 1000 # typically 8KB each
> effective_cache_size = 200000 # typically 8KB each
> #random_page_cost = 4 # units are one sequential page fetch cost

Baisse cette valeur à 2 c'est une machine rapide ...

Dans l'attente de ton retour ...

Cordialement,
--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902