Re: Optimisation

bonjour

j'ai eu des réponse allant dans ce sens sur la mailing liste performance.

Et effectivement j'ai diminuer mes temps de traitement déja par 2 en
modifiant effective-cache-size, et en modifiant shared-buffers.

J'aimerais plus de détail sur la notion de fsm, qu'elle valeur me
suggéreriez vous.

j'ai certaines table qui ont environ 7 000 000 de ligne et qui prenne
pour l'instant 1 000 000 par mois, mais j'augmente de 30% par mois

j'avais demandé aaussi, est ce qu'il pourrait etre intéresssant sur des
tables qui font beaucoup de select, d'update, d'insert de faire les
select sur une vue, et d'utiliser l'accès à la table directement
uniquement pour les updates et insert ?

Merci d'avance

Cordialement

David

Cédric Villemain a écrit :
> dforums a écrit :
>> Bonjour,
>>
>> J'ai un serveur Quad Xeon, avec 8 Go de ram,
>>
>> Une base de donnée postgresql qui fait 10 Go.
>>
>> J'ai des requetes sur des tables qui sont beaucoup updaté et qui
>> prenne beaucoup de temps (0.3300 ms).
>>
> ... comme l'a dit Sébastien, en dessous de la milliseconde c'est pas
> très long.
>> Je pense que j'ai un souci sur l'optimisation des paramétres de la
>> base de donnée
>>
>>
>
> Est-ce un serveur dédié à PostgreSQL ou y a-t-il *aussi* serveur
> web/appli ou autre service utilisant fortement la machine.
>
> Et bien sur il faut connaître la version du serveur ( est-ce un 8.1, 8.0
> ?) Et l'OS (pas un windows j'espère) ?
>
> La version 8.3 est sortie, essayer de mettre à jour au minimum vers la
> version 8.2.
>
>> voici mes params :
>>
>>
>> max_connections = 256
>> shared_buffers = 1500 # min 16 or max_connections*2,
>> 8KB each
>> temp_buffers = 500 # min 100, 8KB each
>> max_prepared_transactions = 100
>>
>> work_mem = 22000 # min 64, size in KB
>> maintenance_work_mem = 500000 # min 1024, size in KB
>> max_stack_depth = 8192
>>
>>
>> max_fsm_pages = 100000 # min max_fsm_relations*16, 6
>> bytes each
>> max_fsm_relations = 5000
>>
>> vacuum_cost_delay = 50 # 0-1000 milliseconds
>> vacuum_cost_page_hit = 1000 # 0-10000 credits
>> vacuum_cost_page_miss = 1000 # 0-10000 credits
>> vacuum_cost_page_dirty = 120 # 0-10000 credits
>> vacuum_cost_limit = 2000 # 0-10000 credits
>>
>> # - Background writer -
>>
>> bgwriter_delay = 50 # 10-10000 milliseconds
>> between rounds
>> bgwriter_lru_percent = 1.0 # 0-100% of LRU buffers
>> scanned/round
>> bgwriter_lru_maxpages = 25 # 0-1000 buffers max
>> written/round
>> bgwriter_all_percent = 0.333 # 0-100% of all buffers
>> scanned/round
>> bgwriter_all_maxpages = 50 # 0-1000 buffers max
>> written/round
>>
>> wal_buffers = 16 # min 4, 8KB each
>> commit_delay = 500 # range 0-100000, in microseconds
>> commit_siblings = 50 # range 1-1000
>>
>> # - Checkpoints -
>>
>> checkpoint_segments = 50 # in logfile segments, min 1,
>> 16MB each
>> checkpoint_timeout = 1800 # range 30-3600, in seconds
>> checkpoint_warning = 180
>> effective_cache_size = 2048 # typically 8KB each
>> random_page_cost = 3
>>
>> mémoire partagé
>> echo /proc/sys/kernel/shmmax = 256000000
>>
>> POurriez vous me donner des conseils pour l'optimisation car la je rame.
>>
> La ram est justement super importante :p
>
> essayer de faire en sorte que la configuration permette a PostgreSQL
> d'utiliser un maximum de RAM (ce qui ne veut pas dire de mettre un
> shared_buffer énorme). Avec 8 giga de ram, vous devriez avoir au moins
> 5GB de effective_cache_size (vérifiez le volume mis en cache par l'OS),
> les shared_buffer se règlent via des tests de performances de l'appli
> qui se sert de PostgreSQL; le volume pris en shared_buffer n'est pas
> utilisé en cache disque (forcement) et le cache disque de l'OS peut être
> plus intéressante que le shared_buffer.... Donc vous pouvez jouer entre
> 500Mo et 1,5Go pour vous faire une idée de l'impact.
>
> Vos valeur pour fsm sont clairement trop basses, mais c'est un point a
> voir avec plus d'info, de même que le reste des paramètres...
>
>
>> Merci
>>
>> David
>>
>>
>>
>>
>>
>>
>>
>
>