Re: Volumes importants - lenteur.

From: "F(dot) BROUARD / SQLpro" <sqlpro(at)club-internet(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Volumes importants - lenteur.
Date: 2011-04-12 20:29:54
Message-ID: 4DA4B642.2020002@club-internet.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

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

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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Cédric Villemain 2011-04-12 20:46:18 Re: Volumes importants - lenteur.
Previous Message Cédric Villemain 2011-04-12 18:14:15 Re: Volumes importants - lenteur.