Skip site navigation (1) Skip section navigation (2)

Re: Optimisation

From: Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>
To: dforums <dforums(at)vieonet(dot)com>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Optimisation
Date: 2008-03-05 10:17:13
Message-ID: 47CE7329.6050705@dalibo.com (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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
>
>
>
>
>
>
>   


-- 
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org


In response to

Responses

pgsql-fr-generale by date

Next:From: dforumsDate: 2008-03-06 18:25:39
Subject: Re: Optimisation
Previous:From: Jean-Paul ArgudoDate: 2008-03-05 09:40:29
Subject: Re: Question PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group