Bonsoir,
merci Thomas pour ces éléments de réponse. Effectivement mon fichier
source de 6 Go occupe 136 Go (index compris - 53 Go pour le seul index
de l'objet géométrique) sous postgresql. Le checkpoint_segments est déjà
à 16 avec un effective_cache_size = 2GB. Le work_mem a été passé à 18 Mb
sur les conseil de l'outil pgtune. Coté mémoire libre je n'ai pas
l'impression de manquer de mémoire (le serveur est dédié à postgresql et
ne subit aucune charge significative). Pour info un vaccum analyse
démarré hier à 21H10 n'est pas terminé ce soir à 19H00. Je pense
effectivement que postgresql n'est pas capable de gérer cette volumétrie
en une seule table et j'espère qu'un découpage me permettra de m'en sortir.
Le SHOW fonctionne bien ;-) . Merci encore. Si quelqun a d'autres pistes
n'hésitez pas.
Alain.
Le 12/04/2011 13:48, Thomas Reiss a écrit :
> 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.
>>
>>
>>
>>
>>
>>
>