Quick Links

Optimisation

Lists:	pgsql-fr-generale

From:	Sébastien Lardière <sebastien(at)lardiere(dot)net>
To:	pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-04 21:14:08
Message-ID:	47CDBBA0.4050704@lardiere.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

dforums a écrit :
> Bonjour,
>
> J'ai des requetes sur des tables qui sont beaucoup updaté et qui
> prenne beaucoup de temps (0.3300 ms).

330 µ sec, c'est beaucoup de temps ? sérieusement ? sur quelle requête,
à partir de quelle référence ?

Bon, pour commencer :

1°/ Activer le collecteur de statistiques,

2°/ Etudier le résultat de explain

3°/ Etudier les informations du catalogue systeme,

4°/ Revenir avec des choses un peu plus précises, car, avec les
informations présentées, je ne crois pas qu'il soit possible d'en
déduire quoi que ce soit.

--
Sébastien

From:	dforums <dforums(at)vieonet(dot)com>
To:	pgsql-fr-generale(at)postgresql(dot)org
Subject:	Optimisation
Date:	2008-03-04 22:06:19
Message-ID:	47CDC7DB.3020907@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000099">
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). 
 
Je pense que j'ai un souci sur l'optimisation des paramétres de la base
de donnée 
 
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. 
 
Merci 
 
David 
 
 
 
 
 
 
</body>
</html>

Attachment	Content-Type	Size
unknown_filename	text/html	4.1 KB

From:	Sébastien Lardière <sebastien(at)lardiere(dot)net>
To:	pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-04 22:22:10
Message-ID:	47CDCB92.70402@lardiere.net
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

dforums a écrit :
> OK donc d'après vous il faut que je laisse les stats en permanence,
> pourtant j'avais cru comprendre que geco fonctionne malgré tous, et
> les explain avait l'air cohérent.

Geco ne se déclenche qu'à partir de 12 jointures par défaut. Est-ce le
cas ?

Je ne peux pas vous dire si les sorties d'explain sont cohérentes, mais
c'est là qu'on arrivera à comprendre ce que veut faire le planner.

> Je croyais que les stats collector été juste la pour collecter les
> stats lorsque nécessaire pour de l'analyse.
>
>
> Bon en tous cas je les ai activé, et j'ai pas vu de modification dans
> els perfs
>

Il faut sans doute laisser le serveur fonctionner quelque temps avant
d'en tirer des conclusions .

Postez des résultats d'explain ensuite pour avoir un peu plus de matière.

--
Sébastien

From:	dforums <dforums(at)vieonet(dot)com>
To:	Sébastien Lardière <sebastien(at)lardiere(dot)net>, pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-04 23:39:52
Message-ID:	47CDDDC8.3000909@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

OK donc d'après vous il faut que je laisse les stats en permanence,
pourtant j'avais cru comprendre que geco fonctionne malgré tous, et les
explain avait l'air cohérent.
Je croyais que les stats collector été juste la pour collecter les stats
lorsque nécessaire pour de l'analyse.

Bon en tous cas je les ai activé, et j'ai pas vu de modification dans
els perfs

Voila à chaud les premiers retour :
indexrelname | idx_scan | idx_tup_read | idx_tup_fetch |
heap_blks_read | heap_blks_hit | idx_blks_read | idx_blks_hit |
toast_blks_read | toast_blks_hit | tidx_blks_read | tidx_blks_hit
-----------------+----------+--------------+---------------+----------------+---------------+---------------+--------------+-----------------+----------------+----------------+---------------
pk_dailydisplay | 7772 | 8169 | 7772 |
6059811 | 57152 | 3388223 | 75149 |
| | |
dd2ia_fk | 0 | 0 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |
dd2s_fk | 0 | 0 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |
fastupdate | 3496 | 24327 | 3415 |
6059811 | 57152 | 3388223 | 75149 |
| | |
g2dd_fk | 0 | 0 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |
iaf2dd_fk | 0 | 0 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |
p2dd_fk | 3353 | 585273284 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |
u2dd_fk | 3353 | 81900694 | 0 |
6059811 | 57152 | 3388223 | 75149 |
| | |

Sébastien Lardière a écrit :
> dforums a écrit :
>> j'ai toujours hésité à activé le colleteur de stats.
>>
>> Qu'est ce que je vais perdre en perf avec le collecteur ? Et combien
>> de temps est il nécessaire de l'utiliser
>
> Il ne faut pas hésiter, sans cela, le planner n'a pas les bonnes
> informations sur vos données, et fait tres probablement de mauvais choix
> pour aller chercher les données.
>
> explain permet de mettre cela en évidence ...
>
>

From:	dforums <dforums(at)vieonet(dot)com>
To:	Sébastien Lardière <sebastien(at)lardiere(dot)net>, pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-04 23:48:39
Message-ID:	47CDDFD7.3080606@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

Euh peut etre plus utile

indexrelname | idx_scan | idx_tup_read | idx_tup_fetch |
idx_blks_read | idx_blks_hit
-----------------+----------+--------------+---------------+---------------+--------------
pk_dailydisplay | 11826 | 12575 | 11826 |
304780 | 46726
dd2ia_fk | 0 | 0 | 0 |
22495 | 19
dd2s_fk | 0 | 0 | 0 |
22443 | 18
fastupdate | 5311 | 36349 | 5192 |
25773 | 23807
g2dd_fk | 0 | 0 | 0 |
22376 | 18
iaf2dd_fk | 0 | 0 | 0 |
22229 | 18
p2dd_fk | 5144 | 901438700 | 0 |
4252983 | 22657
u2dd_fk | 5156 | 130307191 | 0 |
548147 | 22500

Je sais pas si j'ai récup les bonnes infos, merci de me tuyauté.

J'espère que cela vous donnera plus d'information pour l'optimisation
possible

ce que fais la requete sinon c simple, elle cherche une valeur de
char(15) dans la table et si elle existe il y a certaines contrainte
pour la mise à jour ou la suppression, ou l'insertion

cordialement

David

dforums a écrit :
> OK donc d'après vous il faut que je laisse les stats en permanence,
> pourtant j'avais cru comprendre que geco fonctionne malgré tous, et les
> explain avait l'air cohérent.
> Je croyais que les stats collector été juste la pour collecter les stats
> lorsque nécessaire pour de l'analyse.
>
>
> Bon en tous cas je les ai activé, et j'ai pas vu de modification dans
> els perfs
>
> Voila à chaud les premiers retour :
> indexrelname | idx_scan | idx_tup_read | idx_tup_fetch |
> heap_blks_read | heap_blks_hit | idx_blks_read | idx_blks_hit |
> toast_blks_read | toast_blks_hit | tidx_blks_read | tidx_blks_hit
> -----------------+----------+--------------+---------------+----------------+---------------+---------------+--------------+-----------------+----------------+----------------+---------------
>
> pk_dailydisplay | 7772 | 8169 | 7772 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> dd2ia_fk | 0 | 0 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> dd2s_fk | 0 | 0 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> fastupdate | 3496 | 24327 | 3415 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> g2dd_fk | 0 | 0 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> iaf2dd_fk | 0 | 0 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> p2dd_fk | 3353 | 585273284 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
> u2dd_fk | 3353 | 81900694 | 0 | 6059811
> | 57152 | 3388223 | 75149 | |
> | |
>
>
>
> Sébastien Lardière a écrit :
>> dforums a écrit :
>>> j'ai toujours hésité à activé le colleteur de stats.
>>>
>>> Qu'est ce que je vais perdre en perf avec le collecteur ? Et combien
>>> de temps est il nécessaire de l'utiliser
>>
>> Il ne faut pas hésiter, sans cela, le planner n'a pas les bonnes
>> informations sur vos données, et fait tres probablement de mauvais
>> choix pour aller chercher les données.
>>
>> explain permet de mettre cela en évidence ...
>>
>>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your Subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-fr-generale
>
>
>

From:	dforums <dforums(at)vieonet(dot)com>
To:	Sébastien Lardière <sebastien(at)lardiere(dot)net>
Cc:	pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-04 23:58:49
Message-ID:	47CDE239.3040506@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

Voila le résultat de explain analyse
QUERY PLAN
--------------------------------------------------------------------------------------
Result (cost=0.00..0.01 rows=1 width=0) (actual time=65.870..65.871
rows=1 loops=1)
Total runtime: 65.883 ms

la je pige pas trop car il y a pas grand chose

cdtl

David

Sébastien Lardière a écrit :
> dforums a écrit :
>> OK donc d'après vous il faut que je laisse les stats en permanence,
>> pourtant j'avais cru comprendre que geco fonctionne malgré tous, et
>> les explain avait l'air cohérent.
>
> Geco ne se déclenche qu'à partir de 12 jointures par défaut. Est-ce le
> cas ?
>
> Je ne peux pas vous dire si les sorties d'explain sont cohérentes, mais
> c'est là qu'on arrivera à comprendre ce que veut faire le planner.
>
>> Je croyais que les stats collector été juste la pour collecter les
>> stats lorsque nécessaire pour de l'analyse.
>>
>>
>> Bon en tous cas je les ai activé, et j'ai pas vu de modification dans
>> els perfs
>>
>
> Il faut sans doute laisser le serveur fonctionner quelque temps avant
> d'en tirer des conclusions .
>
> Postez des résultats d'explain ensuite pour avoir un peu plus de matière.
>

From:	Hervé Piedvache <herve(at)elma(dot)fr>
To:	pgsql-fr-generale(at)postgresql(dot)org
Cc:	dforums <dforums(at)vieonet(dot)com>
Subject:	Re: Optimisation
Date:	2008-03-05 09:06:36
Message-ID:	200803051006.36374.herve@elma.fr
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

hum ... tu peux mettre la requête et l'explain associé parce que là tu ne fais
rien dans ta requête ... il n'y a pas le moindre filtre ... si tu veux
vraiment de l'aide de la communauté il faut donner tous les éléments comme un
\d des tables utilisées, la requête et l'explain ...
Indique aussi quelle version de PostgreSQL tu utilises ...

Merci

Le mercredi 5 mars 2008, dforums a écrit :
> Voila le résultat de explain analyse
> QUERY PLAN
> ---------------------------------------------------------------------------
>----------- Result (cost=0.00..0.01 rows=1 width=0) (actual
> time=65.870..65.871 rows=1 loops=1)
> Total runtime: 65.883 ms
>
> la je pige pas trop car il y a pas grand chose
>
> cdtl
>
> David
>
> Sébastien Lardière a écrit :
> > dforums a écrit :
> >> OK donc d'après vous il faut que je laisse les stats en permanence,
> >> pourtant j'avais cru comprendre que geco fonctionne malgré tous, et
> >> les explain avait l'air cohérent.
> >
> > Geco ne se déclenche qu'à partir de 12 jointures par défaut. Est-ce le
> > cas ?
> >
> > Je ne peux pas vous dire si les sorties d'explain sont cohérentes, mais
> > c'est là qu'on arrivera à comprendre ce que veut faire le planner.
> >
> >> Je croyais que les stats collector été juste la pour collecter les
> >> stats lorsque nécessaire pour de l'analyse.
> >>
> >>
> >> Bon en tous cas je les ai activé, et j'ai pas vu de modification dans
> >> els perfs
> >
> > Il faut sans doute laisser le serveur fonctionner quelque temps avant
> > d'en tirer des conclusions .
> >
> > Postez des résultats d'explain ensuite pour avoir un peu plus de matière.
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your Subscription:
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-f
>r-generale

--
Hervé Piedvache

Elma Ingénierie Informatique
Groupe Maximiles S.A.
3 rue d'Uzès
F-75002 - Paris - France
Pho. 33-144949901
Fax. 33-144882747

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
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
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

From:	dforums <dforums(at)vieonet(dot)com>
To:	Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>
Cc:	pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-06 18:25:39
Message-ID:	47D03723.5030500@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

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

From:	Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To:	dforums <dforums(at)vieonet(dot)com>
Cc:	Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>, pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-08 20:43:51
Message-ID:	47D2FA87.2060804@lelarge.info
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

dforums a écrit :
> [...]
> J'aimerais plus de détail sur la notion de fsm, qu'elle valeur me
> suggéreriez vous.
>

FSM est une structure en mémoire qui trace les pages disque
réutilisables dans les fichiers qui stockent les données de vos tables
et index. Si la structure est trop petite, peu importe le nombre de
VACUUM que vous faites, vos tables et index risquent de grossir
démesurément.

Cette structure dépend donc du nombre de pages de vos bases, autrement
dit de la taille de ces dernières.

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

Le nombre de lignes n'indique pas la taille sur disque. Seule la taille
sur disque nous intéresse.

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

PostgreSQL ne disposant pas de la fonctionnalité des vues matérialisées,
vous ne gagnerez rien à utiliser les vues standards de PostgreSQL.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

From:	Christophe Garault <christophe(at)garault(dot)org>
To:	Liste PostgreSQL Fr <pgsql-fr-generale(at)postgresql(dot)org>
Subject:	Re: Optimisation
Date:	2008-03-11 20:53:16
Message-ID:	47D6F13C.6080709@garault.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

dforums a écrit :

[...]
> les disques font 750 Go (RAID 1), la base de donnée fait 10 Go mais
> grossie rapidement d'ici juin elle aura sûrement doublé, et sûrement
> atteindra les 50 Go d'ici la fin de l'année.
>
>
Le RAID 1 c'est quand même pas la panacée même pour de petites bases.
Je suis toujours horrifié de voir les architectures matérielles choisies
pour l'exploitation de BDD.
Si vous en avez la possibilité, l'idéal est de mettre le WAL sur une
pile en RAID 1 et les données sur une autre en RAID 0+1 (ou RAID 10). Le
RAID 5 est à proscrire car bien trop lent.
Mais bon, je m'écarte sans doute du sujet initial..

--
Christophe Garault

From:	dforums <dforums(at)vieonet(dot)com>
To:	Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc:	Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>, pgsql-fr-generale(at)postgresql(dot)org
Subject:	Re: Optimisation
Date:	2008-03-11 21:16:35
Message-ID:	47D6F6B3.1030403@vieonet.com
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

Bonjour,

J'étais absent ces derniers jours, je reprend donc la discussion.

Et vous remercie pour ces informations

les disques font 750 Go (RAID 1), la base de donnée fait 10 Go mais
grossie rapidement d'ici juin elle aura sûrement doublé, et sûrement
atteindra les 50 Go d'ici la fin de l'année.

Bien cordialement

David

Guillaume Lelarge a écrit :
> dforums a écrit :
>> [...]
>> J'aimerais plus de détail sur la notion de fsm, qu'elle valeur me
>> suggéreriez vous.
>>
>
> FSM est une structure en mémoire qui trace les pages disque
> réutilisables dans les fichiers qui stockent les données de vos tables
> et index. Si la structure est trop petite, peu importe le nombre de
> VACUUM que vous faites, vos tables et index risquent de grossir
> démesurément.
>
> Cette structure dépend donc du nombre de pages de vos bases, autrement
> dit de la taille de ces dernières.
>
>> 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
>>
>
> Le nombre de lignes n'indique pas la taille sur disque. Seule la taille
> sur disque nous intéresse.
>
>> 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 ?
>>
>
> PostgreSQL ne disposant pas de la fonctionnalité des vues matérialisées,
> vous ne gagnerez rien à utiliser les vues standards de PostgreSQL.
>
>

From:	Mathieu Arnold <mat(at)mat(dot)cc>
To:	Liste PostgreSQL Fr <pgsql-fr-generale(at)postgresql(dot)org>
Subject:	Re: Optimisation
Date:	2008-03-12 08:58:44
Message-ID:	CAD13F9F138481EF7CD34FA1@atuin.in.mat.cc
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

+-Le 11/03/08 21:53 +0100, Christophe Garault a dit :
| dforums a écrit :
|
| [...]
|> les disques font 750 Go (RAID 1), la base de donnée fait 10 Go mais
|> grossie rapidement d'ici juin elle aura sûrement doublé, et sûrement
|> atteindra les 50 Go d'ici la fin de l'année.
|>
|>
| Le RAID 1 c'est quand même pas la panacée même pour de petites bases.
| Je suis toujours horrifié de voir les architectures matérielles
| choisies pour l'exploitation de BDD.
| Si vous en avez la possibilité, l'idéal est de mettre le WAL sur une
| pile en RAID 1 et les données sur une autre en RAID 0+1 (ou RAID 10). Le
| RAID 5 est à proscrire car bien trop lent.
| Mais bon, je m'écarte sans doute du sujet initial..

Et mettre des disques plus petits, mais plus.

--
Mathieu Arnold

From:	Stéphane BUNEL <stephane+pgfr(at)bpf(dot)st>
To:	Mathieu Arnold <mat(at)mat(dot)cc>
Cc:	Liste PostgreSQL Fr <pgsql-fr-generale(at)postgresql(dot)org>
Subject:	Re: Optimisation
Date:	2008-03-12 09:59:18
Message-ID:	47D7A976.4060404@bpf.st
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-fr-generale

Bonjour,

Mathieu Arnold a écrit :
>
> +-Le 11/03/08 21:53 +0100, Christophe Garault a dit :
> | dforums a écrit :
> |
> | [...]
> |> les disques font 750 Go (RAID 1), la base de donnée fait 10 Go mais
> |> grossie rapidement d'ici juin elle aura sûrement doublé, et sûrement
> |> atteindra les 50 Go d'ici la fin de l'année.
> |>
> |>
> | Le RAID 1 c'est quand même pas la panacée même pour de petites bases.
> | Je suis toujours horrifié de voir les architectures matérielles
> | choisies pour l'exploitation de BDD.
> | Si vous en avez la possibilité, l'idéal est de mettre le WAL sur une
> | pile en RAID 1 et les données sur une autre en RAID 0+1 (ou RAID 10). Le
> | RAID 5 est à proscrire car bien trop lent.
> | Mais bon, je m'écarte sans doute du sujet initial..
>
> Et mettre des disques plus petits, mais plus.
>

PG, depuis la version 8.x, permet également de répartir les données
sur des axes (disques) différent. Par exemple cela permet de ventiler
les indexes et les données sur des disques aux caractéristiques
appropriées. C'est l'équivalent des TABLESPACEs d'Oracle.

Stéphane.