Re: Pb de perf sur une grosse base

From: Hervé Piedvache <herve(at)elma(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org, Valerie Schneider DSI/DEV <Valerie(dot)Schneider(at)meteo(dot)fr>
Subject: Re: Pb de perf sur une grosse base
Date: 2004-08-04 15:12:05
Message-ID: 200408041712.05134.herve@elma.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonjour,

Le mercredi 4 Août 2004 15:09, Valerie Schneider DSI/DEV a écrit :
> Sous oracle la SGA est de 500 Mb.
> Pour PG le postgresql.conf :
> max_connections = 1500
> shared_buffers = 30000
> sort_mem = 50000

Ca me paraît beaucoup ... essayez de diviser par deux ... ou pas dix.
C'est aloué par process ... donc ca risque de vous pénaliser d'avoir une
valeur trop importante ...

> effective_cache_size = 200000
> et les valeurs par défaut pour les autres paramètres.

Quelles sont les valeurs de max_fsm_pages et max_fsm_relations ?
Que disent les deux dernières lignes du vacuum full verbose analyze; ?
Quelles sont les valeurs de random_page_cost, cpu_tuple_cost,
cpu_index_tuple_cost, cpu_operator_cost ?
Si vous êtes sur les paramètres par défaut vous pouvez déjà passer le
random_page_cost = 2 ou 3 ... la machine est rapide ...

> J'ai une table nommée "data" qui ressemble à :
> bench=> \d data
> Table "public.data"
> Column | Type | Modifiers
> ------------+-----------------------------+-----------
> num_poste | numeric(9,0) | not null
> dat | timestamp without time zone | not null
> datrecu | timestamp without time zone | not null
> rr1 | numeric(5,1) |
> qrr1 | numeric(2,0) | ...
> ... all numeric fields

Pourquoi utilisez-vous des Numeric ? Est-ce véritablement une obligation ? Ou
est-ce du au portage Oracle->PostgreSQL ?
Les Integers sont mieux gérés pour les CAST de l'optimiseur, et prennent moins
de place sur le disque.

> Indexes:
> "pk_data" primary key, btree (num_poste, dat)
> "i_data_dat" btree (dat)

A la vue des quatres requêtes ... je ne vois pas trop l'intérêt de l'index
i_data_dat ... mais bon c'est juste une histoire de place et de rapidité des
INSERT ... et puis vous faites peut-être des requêtes juste sur le
date ... :o)

> Ma première remarque est que la table occupe beaucoup plus de place
> sur PG (70 Gb) que sur oracle (35 Gb).
> Le calcul : 125 000 000 rows x 256 b = 32 Gb donne une idée du volume
> occupé, pas si mauvais pour oracle. Qu'en est-il pour PG ?
> Comment les données sont stockées ?

Il est clair qu'avec des Integer la place que le disque serait grandement
réduite ... et donc les accès en lecture seront aussi optimisés !

> Bien sûr lorsque je lance en parallèle 1000 requêtes Q3 ou Q4 les perf
> deviennent désastreuses !

La machine doit bien ramer en lecture ... c'est clair, il faut impérativement
optimiser la structure de la table ...

Cordialement,
--
Hervé Piedvache

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

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Jouneau Luc 2004-08-04 15:26:08 Re: Pb de perf sur une grosse base
Previous Message Valerie Schneider DSI/DEV 2004-08-04 14:13:16 Re: Pb de perf sur une grosse base