Re: Volumes importants - lenteur.

Le 12 avril 2011 19:32, Alain Benard <alain(dot)benard(at)nancy(dot)inra(dot)fr> a écrit :
> 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.

En particulier avec du 'the_geom' au milieu.

Habituellement 100millions de lignes pour une table est un nombre qui
commence a etre limite, principalement en raison des taches de
maintenances.

Vu les volumes en base, et votre volume de ram, je suis assez
pessimiste sur les performances que vous pouvez espérer obtenir au
final... tout dépend de vos requetes bien sur.

> 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.
>
>
>
>
>
>
>
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
>

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support