Re: Volumes importants - lenteur.

Le 12 avril 2011 22:29, F. BROUARD / SQLpro <sqlpro(at)club-internet(dot)fr> a écrit :
> En fait vous êtes un peu aux limites de PG. Le problème de PG c'est qu'il ne
> sait pas multithreader une même requête. C'est son gros point noir pour
> traiter de forts volumes de données, à la différence de Oracle ou MS SQL
> Server qui savent parfaitement multithreader une même requête, voir même
> trop (si il y a 32 processeurs, les requêtes candidates au multithreading
> vont s'exécuter sur les 32 coeurs) et il faut les brider en limitant le
> parallélisme...
>
> Effectivement si vous pouvez découper votre table en plusieurs petites, ce
> sera déjà un peu quelques chose. Ensuite rien ne vous empêche de créer une
> vue agrégeant les tables à l'aide d'un UNION ALL et pour les mise à jour
> passer par des triggers de mise à jour (via les règles).
> http://docs.postgresqlfr.org/8.0/rules-update.html

Il existe une notion d'héritage dans PostgreSQL:
http://doc.postgresql.fr/9.0/ddl-partitioning.html

>
> A +
>
>
> --
> Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
> Le site sur le langage SQL et les SGBDR  :  http://sqlpro.developpez.com
> Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> *********************** http://www.sqlspot.com *************************
>
>
> Le 12/04/2011 19:32, Alain Benard 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.
>> 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