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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-fr-generale by date

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