Skip site navigation (1) Skip section navigation (2)

Re: Volumes importants - lenteur.

From: Thomas Reiss <thomas(dot)reiss(at)interieur(dot)gouv(dot)fr>
To: alain(dot)benard(at)nancy(dot)inra(dot)fr
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Volumes importants - lenteur.
Date: 2011-04-12 11:48:45
Message-ID: 4DA43C1D.9010907@interieur.gouv.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Bonjour,

J'aurai tendance à dire que votre volumétrie commence à devenir vraiment 
trop importante pour stocker les données sur une seule table. D'autant 
plus que, de ma propre expérience, les données carto sont assez 
volumineuses.
A mon avis, vous devriez gagner à partitionner la table en question. La 
volumétrie des partitions sera réduite et par conséquent les opérations 
de maintenance plus efficaces (vacuum et analyze).

Pour mieux vous rendre compte de la volumétrie, vous pouvez utiliser les 
fonctions de calcul de la taille des objets de la base 
(http://docs.postgresql.fr/8.3/functions-admin.html#functions-admin-dbsize) 
- notamment pg_relation_size et pg_total_relation_size.

Pour en revenir à votre configuration, vous pouvez la commande SHOW pour 
afficher la valeur d'une variable GUC.

Pour améliorer vos écritures, vous pouvez augmenter checkpoint_segments 
à 10. Et augmenter également le paramètre effective_cache_size pour 
refléter la taille totale des mémoires caches de votre base 
(shared_buffers + RAM libre + taille du cache Linux) - à la louche 3Go 
sur votre système.

Par ailleurs, la valeur de work_mem me semble très élevée, mais elle 
peut correspondre à vos besoins. Cela m'amène à vous poser ces 
différentes questions :
- Combien de clients se connectent en même à votre base de données ?
- Avez-vous encore de la mémoire libre ?
- Votre serveur est-il surchargé (iowait + swap) ?

Voilà dans un premier temps ce qui me vient à l'esprit.

Cordialement,
Thomas Reiss


Le 12/04/2011 11:50, Alain Benard a écrit :
> Bonjour,
> je voudrai savoir s'il existe une limite de bonne pratique dans la 
> taille d'une table postgresql. Je travaille sur des données 
> géographiques avec Postgres / Postgis et stocke des points 
> géographiques auxquels sont associés par exemple une mesure de 
> température. Jusqu'ici ma plus grosse table représentait 27 millions 
> de lignes avec des temps d'accès restant raisonnables. Je viens 
> d'intégrer de nouvelles données pour un total d'environ 300 millions 
> de lignes et là ça devient catastrophique. La structure de la table :
>
>     X (integer)    champ indexé btree
>     Y (integer)    champ indexé btree
>     Mesure (smallint)
>     the_geom (geometry point)    indexé gist
>
>     La clé primaire est constituée du couple x,y
>
> Le constat :
>
>     des vaccum analyze qui n'en finissent pas.
>     un select count (*) qui dure qui dure qui dure ...
>
> La conf :
>
>     Un serveur debian / etch / postgresql 8.3 avec 4 Go de ram.
>     Postgresql :
>
>         shared_buffers = 1024MB
>         work_mem = 18MB
>         maintenance_work_mem = 176MB (par ailleurs j'ai passé la
>         commande suivante 'alter user postgres set
>         maintenance_work_mem to '512MB'; ' - je ne sais d'ailleurs pas
>         comment afficher si c'est pris en compte)
>         max_fsm_pages = 1560000    (valeur fixée suite à la demande de
>         postgresql lors de vacuum)
>         wal_buffers = 8MB
>
> j'espère que quelques âmes charitables spécialistes pourront me donner 
> des pistes. Merci par avance.
> Alain.
>
>
>
>
>
>

In response to

Responses

pgsql-fr-generale by date

Next:From: Sihem MOUALHIDate: 2011-04-12 14:02:18
Subject: trigger d'historisation
Previous:From: Alain BenardDate: 2011-04-12 09:50:31
Subject: Volumes importants - lenteur.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group