Vous n'êtes pas identifié(e).
Merci, ça fonctionne désormais.
Bonjour,
L'installation de PgAdmin3 1.20 sur W7 se déroule correctement. Mais je ne peux pas l'exécuter car il manque MSVCP120.dll. J'ai lu ça et là qu'en installant visual C++ ou PostgreSQL ça fonctionne. Est-il possible de faire fonctionner PgAdmin sans installer les deux éléments précédents?
Merci
Je relance encore ce topic...
Après avoir mis en doute le matériel, je remets en doute la partie logiciels. Afin de bien comparer, j'ai installé une base de données Oracle 11g sur le même type de machine que celle sur laquelle j'ai fait mes tests avec PostgreSQL: machine virtuelle hébergée sur le même datastore, exécutée par le même ESX, avec le même OS Debian et la même quantité de ressources. Je fais les tests sur les mêmes tables (export avec oracle_fdw). La requête passe par défaut par un HashAggregate et met 23s. En forçant le group by à passer par un GroupAggregate à l'aide d'un hint la requête met 41s (contre 10min avec PostgreSQL). Étant donné que le GroupAggregate fait aussi son tri sur disque (le tablespace temporaire est utilisé pour la requête), on peut dire que le matériel peut supporter la charge d'un GroupAggregate ce qui n'est pas le cas avec PostgreSQL. Ceci me fait dire que je dois avoir un problème de configuration quelque part. Les tests sont faits avec une installation à partir du paquet postgresql-9.3 et avec des clusters créés à partir de pg_createcluster ou initdb.
Les résultats de vmstat ci-dessous (intervalle de 5s) montre que Oracle écrit fortement pendant une trentaine de secondes en même temps qu'il utilise la CPU. Sous PostgreSQL, il n'écrit fortement que toutes les 35s environ et consomme de la CPU pendant toute la durée de la requête. Que fait-il entre 2 séances d'écritures? A priori c'est pendant les périodes de non écriture qu'il perd du temps. De plus, après la dernière "écriture", il passe près de 4 min à travailler sur CPU. Sur la machine physique, le phénomène est le même; ça ne doit donc pas être lié à la virtualisation. Comprenez-vous ce type de comportement? Faut-il des infos supplémentaires sur ma configuration?
vmstat Oracle
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 997376 14984 2897928 0 0 1262 3023 1072 2093 17 12 69 2
1 0 0 931888 15000 2897920 0 0 0 30 1095 1990 34 4 62 0
1 0 0 847328 15016 2898272 0 0 0 19289 1289 2068 82 12 0 6
0 1 0 847328 15024 2898272 0 0 0 21202 1319 2118 85 9 0 6
1 0 0 847328 15048 2898272 0 0 0 21706 1303 2091 86 8 0 6
1 0 0 847204 15056 2898272 0 0 0 19804 1301 2081 85 9 0 6
1 0 0 847204 15080 2898272 0 0 0 19626 1309 2102 87 8 0 5
1 0 0 847204 15088 2898272 0 0 0 22246 1309 2108 86 7 0 6
1 0 0 996624 15104 2898280 0 0 0 18555 1284 2075 84 10 1 6
0 0 0 996500 15120 2898272 0 0 0 29 1012 1984 0 0 99 0
0 0 0 996500 15128 2898284 0 0 0 25 1007 1989 0 0 100 0
0 0 0 996500 15144 2898284 0 0 0 18 1011 1986 0 0 99 0vmstat PostgreSQL
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104 3588416 62172 315624 0 0 30 42 37 44 1 0 99 0
2 0 104 3565460 62180 315812 0 0 0 10 91 42 23 1 76 0
1 0 104 3559500 62196 321360 0 0 0 28 277 41 100 0 0 0
1 0 104 3554424 62204 326580 0 0 0 7 282 33 99 1 0 0
1 0 104 3549340 62220 331628 0 0 0 18 279 38 100 0 0 0
1 0 104 3544000 62228 336620 0 0 0 10 283 38 100 0 0 0
1 0 104 3539296 62244 341664 0 0 0 10 277 35 100 0 0 0
1 0 104 3534088 62252 346692 0 0 0 11 281 37 100 0 0 0
1 0 104 3528624 62268 351676 0 0 0 6442 289 39 100 0 0 0
1 0 104 3523920 62276 356668 0 0 0 15 277 36 100 0 0 0
1 0 104 3518836 62292 361780 0 0 0 6 279 36 99 1 0 0
1 0 104 3513620 62304 366892 0 0 0 16 279 40 100 0 0 0
1 0 104 3508916 62320 371952 0 0 0 10 279 34 100 0 0 0
1 0 104 3503708 62328 376900 0 0 0 8 274 36 100 0 0 0
1 0 104 3498492 62348 382076 0 0 0 22 276 40 100 0 0 0
1 0 104 3493292 62356 387200 0 0 0 7098 297 35 99 1 0 0
1 0 104 3488208 62372 392272 0 0 0 11 279 37 99 0 0 0
1 0 104 3482868 62380 397456 0 0 0 10 281 39 100 0 0 0
1 0 104 3478164 62396 402524 0 0 0 10 278 34 99 1 0 0
1 0 104 3473080 62404 407532 0 0 0 9 284 36 100 0 0 0
1 0 104 3467864 62420 412572 0 0 0 14 282 39 100 0 0 0
2 0 104 3462540 62428 417800 0 0 0 6118 290 36 99 1 0 0
1 0 104 3457580 62444 422804 0 0 0 14 279 35 100 0 0 0
1 0 104 3452488 62452 427828 0 0 0 10 283 39 100 0 0 0
1 0 104 3447784 62468 432880 0 0 0 16 280 36 100 0 0 0
1 0 104 3442452 62476 438016 0 0 0 2 281 37 99 1 0 0
1 0 104 3437360 62492 443060 0 0 0 20 280 39 100 0 0 0
1 0 104 3432532 62500 448112 0 0 0 7 280 35 100 0 0 0
1 0 104 3427076 62520 453256 0 0 1 7118 296 39 99 0 0 0
1 0 104 3421736 62528 458388 0 0 0 10 281 39 99 1 0 0
1 0 104 3417032 62544 463420 0 0 0 11 284 35 99 1 0 0
1 0 104 3411948 62552 468524 0 0 0 14 284 36 100 0 0 0
1 0 104 3406608 62568 473620 0 0 0 14 282 39 100 0 0 0
...J'avais fait des tests avec sysbench sans savoir à quels chiffres les comparer. Le test avec dd me renvoie 290MB/s. Couplé avec un processeur de faible fréquence, ceci doit expliquer cela!
Merci pour votre aide!
La CPU est bien à 100% pendant l'exécution de la requête. Mon vCPU est cadencé à 1.6GHz, le tri sur disque met 652s. Ce même tri met 26s sur le portable de gleu. La vitesse de tri ne doit pas être proportionnelle à la fréquence du processeur, car si on omet l'utilisation du disque gleu doit avoir un processeur à 40GHz!! Peut-être exponentielle?
Concernant l'écriture sur disque, il n'y a jamais que 350Mo à écrire. Il ne faut pas plus de quelques seconde au pire pour le faire. Par contre je n'ai pas compris le "écrire pour lire". Quel est le mécanisme mis en œuvre? Mon disque virtuel est sur un datastore du SAN.
Je dois avoir une mauvaise combinaison CPU+disque.
Je relance cette conversation car après avoir testé plusieurs types de matériels, je reproduis toujours le même problème: le tri sur disque lors du GroupAggregate est très lent. Étant en environnement virtuel, et ayant toujours entendu dire que le virtuel et les SGBD ne faisaient pas bon ménage, j'ai cru que la virtualisation était la source de mon problème. Or sur un PC la lenteur se reproduit (même configuration logicielle, postgresql.conf par défaut). Peut-être est-ce dû là à la lenteur des disques durs classiques. Mais sur votre portable ça fonctionne. Est-ce dû à la fréquence de mes processeurs (1.6GHz en virtuel et 1Ghz sur le PC)? Sur un serveur AiX sur Power6 avec SAN: idem.
Quelqu'un arrive-t-il à reproduire mon problème? Je suis sur Debian Wheezy avec PostgreSQL 9.3.4. La configuration de mes paramètres système est:
kernel.shmall = 134217728
kernel.shmmax = 549755813888
vm.dirty_background_ratio = 1
vm.dirty_ratio = 2
vm.swappiness = 10
vm.zone_reclaim_mode = 0
vm.overcommit_memory = 2
vm.overcommit_ratio = 90Les disques sont formatés en ext4 et montés avec les options defaults,noatime,nodiratime.
Merci pour cette réécriture de la requête qui améliore grandement les choses de mon côté: je suis tombé à 32s (même plan d'exécution). La plus grande partie de l'amélioration se situe dans l'utilisation du HashAggregate final (comme avec des stats fausses). Avec la table de 14M de lignes, la requête ne met plus que 14min au lieu de plusieurs heures.
Cette solution nous dépanne temporairement, tant il semble que nous ayons un problème de matériel qui nous faut régler...
J'ai fait le test avec le postgresql.conf.sample et le résultat est toujours lent. J'en déduit que j'ai surtout un problème de matériel. Pendant les 10 min de l'exécution, ma cpu est à 100%, je vais creuser par là.
J'ai critiqué un peu vite l'optimiseur avant de mettre en cause mon matériel 
Merci pour avoir pris le temps de tester tout ceci 
Au temps pour moi... J'ai édité la requête et la création de la première table dans le message précédent. Ça devrait fonctionner cette fois-ci.
Pour pouvoir faire ses propres tests, je propose les 2 scripts de création de tables suivants qui permettent d'obtenir une approximation de mes tables. Pour la 2ème table, il est possible de faire varier sa taille en remplaçant 1235 par une valeur allant jusqu'à 36726.
create table t1 as select 'COM'::text nivgeo_zone, *, md5(generate_series(floor(3*random())::int,(4*random()+7)::int)::text) nivgeo_englobe, ceil(3550*exp(random())) codgeo_englobe from generate_series(1,36726) codgeo_zone;create table t2 as select 'COM'::text as nivgeo, *, random() as valeur from (((generate_series(1,1235) codgeo inner join generate_series(1,9) iranr on 1=1) inner join generate_series(1,3) inatc on 1=1) inner join generate_series(1,5) age4 on 1=1) inner join generate_series(1,3) sexe on 1=1;La requête que j'exécute est:
SELECT
SUM(valeur) AS valeur, inatc, sexe, age4, iranr, nivgeo, codgeo
FROM (
SELECT
data.valeur, data.inatc, data.sexe, data.age4, data.iranr, zone.nivgeo_englobe AS nivgeo, zone.codgeo_englobe AS codgeo
FROM
t2 data
INNER JOIN t1 zone
ON data.nivgeo = zone.nivgeo_zone AND data.codgeo = zone.codgeo_zone
) agrege
GROUP BY
nivgeo, codgeo, inatc, sexe, age4, iranr
;Si on exécute cette requête directement à la suite de la création de la table t2 (c'est-à-dire avec des stats non calculées) la requête passe par un HashAggregate et est rapide. Si on calcule les stats, la requête fait un tri sur disque si work_mem n'est pas assez grand et est beaucoup plus lente.
En fait, j'avais remis des index sur les tables entre temps, d'où les parcours d'index. Sans les index et avec enable_sort à off, il fait un HashJoin et ne met que 7s au lieu des 26s avec parcours d'index!! Donc on gagne bien avec enable_sort à off sur la jointure en retombant sur ce qui se fait lorsque les stats ne sont pas à jour ou lorsqu'on est en 9.2 (je suis bien en 9.3.4).
GroupAggregate (cost=10000765934.81..10000960295.97 rows=4859029 width=124) (actual time=561800.172..589355.040 rows=114615 loops=1)
Buffers: shared hit=15100, temp read=80436 written=80436
-> Sort (cost=10000765934.81..10000778082.38 rows=4859029 width=124) (actual time=561799.122..578854.863 rows=4857975 loops=1)
Sort Key: zone.nivgeo_englobe, zone.codgeo_englobe, data.inatc, data.sexe, data.age4, data.iranr
Sort Method: external merge Disk: 643472kB
Buffers: shared hit=15100, temp read=80436 written=80436
-> Hash Join (cost=13480.20..226285.30 rows=4859029 width=124) (actual time=637.942..7134.940 rows=4857975 loops=1)
Hash Cond: ((data.nivgeo = zone.nivgeo_zone) AND (data.codgeo = zone.codgeo_zone))
Buffers: shared hit=15100
-> Seq Scan on test_rp2006_541_2 data (cost=0.00..15412.75 rows=500175 width=124) (actual time=0.101..252.521 rows=500175 loops=1)
Buffers: shared hit=10411
-> Hash (cost=8205.48..8205.48 rows=351648 width=64) (actual time=636.881..636.881 rows=351648 loops=1)
Buckets: 65536 Batches: 1 Memory Usage: 32967kB
Buffers: shared hit=4689
-> Seq Scan on test_emboitement_2008 zone (cost=0.00..8205.48 rows=351648 width=64) (actual time=0.041..209.633 rows=351648 loops=1)
Buffers: shared hit=4689
Total runtime: 590458.096 msJ'ai remarqué qu'avec un work_mem au double de ce dont il a besoin pour écrire le sort (ici, 643472kB), il effectue un HashAggregate et est rapide (comme lorsque les stats ne sont pas à jour). Par exemple avec work_mem='1300MB', il ne met plus que 24s en tout (contre 10min). Ces tests sont faits sur un extrait de la table cible de 14M de lignes. Il faudrait alors un work_mem à 37GB pour faire un HashAggregate à partir de la table cible, ce qui n'est pas une solution sachant qu'il est "capable" de le faire sans cette taille de work_mem avec des stats "fausses".
Existe-t-il une solution temporaire ou doit-on attendre la 9.4 ou plus pour ce type de requête?
avec enable_sort = 'off':
GroupAggregate (cost=10000649295.98..10000844337.42 rows=4876036 width=124) (actual time=586089.874..610259.810 rows=114615 loops=1)
Buffers: shared hit=5310492, temp read=80436 written=80436
-> Sort (cost=10000649295.98..10000661486.07 rows=4876036 width=124) (actual time=586089.059..599872.303 rows=4857975 loops=1)
Sort Key: zone.nivgeo_englobe, zone.codgeo_englobe, data.inatc, data.sexe, data.age4, data.iranr
Sort Method: external merge Disk: 643472kB
Buffers: shared hit=5310492, temp read=80436 written=80436
-> Merge Join (cost=31.58..107634.76 rows=4876036 width=124) (actual time=0.052..26496.616 rows=4857975 loops=1)
Merge Cond: ((data.codgeo = zone.codgeo_zone) AND (data.nivgeo = zone.nivgeo_zone))
Buffers: shared hit=5310492
-> Index Scan using index_test_rp2006_541_2_1 on test_rp2006_541_2 data (cost=0.42..47741.97 rows=500175 width=124) (actual time=0.011..1594.075 rows=500175 loops=1)
Buffers: shared hit=493245
-> Index Scan using index_test_emboitement_2008_1 on test_emboitement_2008 zone (cost=0.42..25750.73 rows=351648 width=64) (actual time=0.008..5622.723 rows=4857976 loops=1)
Buffers: shared hit=4817247
Total runtime: 611316.395 msDésactiver le tri (enable_sort à off) puis regarder le plan généré, avec des stats à jours. Il devrait changer son plan, ce qui nous donnera plus d'informations.
J'avais fait le test avec enable_sort à off, mais le résultat était le même.
Pouvez vous récrire votre requête en isolant les parties agrégées/clef des données non clef et en rajoutant les données non clef en liant avec la clef en final ?
Si vous ne me comprenez pas, donnez le DDL de vos tables / vues et on vous la récrira.
A +
Comme je n'ai pas tout compris: 
CREATE TABLE test_rp2006_541_2
(
valeur numeric,
maximum numeric,
inatc character(20),
sexe character(20),
age4 character(20),
iranr character(20),
nivgeo character(10),
codgeo character(20),
secret smallint,
est_englobante smallint
)
WITH (
OIDS=FALSE
);CREATE TABLE test_emboitement_2008
(
annee numeric,
id_zone integer,
nivgeo_zone character(10),
codgeo_zone character(20),
id_englobe integer,
nivgeo_englobe character(10),
codgeo_englobe character(20)
)
WITH (
OIDS=FALSE
);J'ajoute qu'en 9.2 avec les stats à jour il n'effectue pas le MergeJoin mais fait un HashJoin. L'optimiseur serait sur ce point là meilleur en 9.2 qu'en 9.3!
Bonjour,
Je tiens à signaler ce qui me semble être un problème de l'optimiseur en 9.3. Veuillez m'excuser si le forum n'est pas le bon endroit pour cela.
Dans l'exemple qui suit, j'ai pris un extrait de la table cible (0.5M lignes sur 14M).
La requête que j'exécute est la suivante:
CREATE TABLE test_RP2006_541_aggrege AS
SELECT
SUM(valeur) AS valeur, inatc, sexe, age4, iranr, nivgeo, codgeo, SUM(secret) AS nombre_secret, CASE SUM(CASE secret WHEN 0 THEN 0 ELSE 1 END) WHEN 1 THEN 3 ELSE 0 END AS secret
FROM (
SELECT
data.valeur, data.inatc, data.sexe, data.age4, data.iranr, zone.nivgeo_englobe AS nivgeo, zone.codgeo_englobe AS codgeo, data.secret
FROM
test_RP2006_541_2 data
INNER JOIN test_emboitement_2008 zone
ON data.nivgeo = zone.nivgeo_zone AND data.codgeo = zone.codgeo_zone
) agrege
GROUP BY
nivgeo, codgeo, inatc, sexe, age4, iranr
;La requête effectue d'abord une jointure entre 2 tables et fait un group by sur le résultat.
Avec les stats à jour sur les 2 tables, le plan d'exécution est le suivant:
GroupAggregate (cost=698358.79..893400.23 rows=4876036 width=124) (actual time=592732.807..616866.907 rows=114615 loops=1)
Buffers: shared hit=6833 read=8267, temp read=80436 written=80436
-> Sort (cost=698358.79..710548.88 rows=4876036 width=124) (actual time=592732.097..606417.498 rows=4857975 loops=1)
Sort Key: zone.nivgeo_englobe, zone.codgeo_englobe, data.inatc, data.sexe, data.age4, data.iranr
Sort Method: external merge Disk: 643472kB
Buffers: shared hit=6833 read=8267, temp read=80436 written=80436
-> Merge Join (cost=103360.69..156697.57 rows=4876036 width=124) (actual time=10588.579..30326.928 rows=4857975 loops=1)
Merge Cond: ((data.codgeo = zone.codgeo_zone) AND (data.nivgeo = zone.nivgeo_zone))
Buffers: shared hit=6833 read=8267
-> Sort (cost=62759.50..64009.94 rows=500175 width=124) (actual time=6186.175..6741.332 rows=500175 loops=1)
Sort Key: data.codgeo, data.nivgeo
Sort Method: quicksort Memory: 145147kB
Buffers: shared hit=2144 read=8267
-> Seq Scan on test_rp2006_541_2 data (cost=0.00..15412.75 rows=500175 width=124) (actual time=0.225..337.494 rows=500175 loops=1)
Buffers: shared hit=2144 read=8267
-> Sort (cost=40598.89..41478.01 rows=351648 width=64) (actual time=4402.378..5298.424 rows=4857976 loops=1)
Sort Key: zone.codgeo_zone, zone.nivgeo_zone
Sort Method: quicksort Memory: 61739kB
Buffers: shared hit=4689
-> Seq Scan on test_emboitement_2008 zone (cost=0.00..8205.48 rows=351648 width=64) (actual time=0.058..197.162 rows=351648 loops=1)
Buffers: shared hit=4689
Total runtime: 618033.066 msL'exécution de la requête passe le plus clair de sont temps à trier les données de la jointure des 2 tables. work_mem étant à 1GB et considérant avoir 4.8M de lignes à traiter (ce qui est vrai), il choisit le tri/groupe et écrit donc sur disque provoquant une durée d'exécution très longue. La jointure se fait par MergeJoin et dure 30s. Avec un index à chaque table sur la condition de jointure il utilise les index pour le tri et dure 26s.
Lorsque j'exécute la même requête sur les mêmes données mais avec des stats non calculées (juste après la création de l'intégralité de la table test_RP2006_541_2, donc avant le calcul des stats), le plan d'exécution est le suivant:
HashAggregate (cost=68959.37..69048.23 rows=7109 width=402) (actual time=23688.391..23837.439 rows=114615 loops=1)
Buffers: shared hit=6737 read=8363 written=8331
-> Hash Join (cost=13480.20..68781.64 rows=7109 width=402) (actual time=564.889..6729.138 rows=4857975 loops=1)
Hash Cond: ((data.nivgeo = zone.nivgeo_zone) AND (data.codgeo = zone.codgeo_zone))
Buffers: shared hit=6737 read=8363 written=8331
-> Seq Scan on test_rp2006_541_2 data (cost=0.00..11868.54 rows=145754 width=498) (actual time=0.276..490.542 rows=500175 loops=1)
Buffers: shared hit=2048 read=8363 written=8331
-> Hash (cost=8205.48..8205.48 rows=351648 width=64) (actual time=564.190..564.190 rows=351648 loops=1)
Buckets: 65536 Batches: 1 Memory Usage: 32967kB
Buffers: shared hit=4689
-> Seq Scan on test_emboitement_2008 zone (cost=0.00..8205.48 rows=351648 width=64) (actual time=0.025..204.801 rows=351648 loops=1)
Buffers: shared hit=4689
Total runtime: 23854.337 msLe group by se fait alors par HashAggregate et prend beaucoup moins de temps (17s contre 586s). Je suppose que ceci vient du fait qu'il estime mal le nombre de ligne à traiter dans le group by: 7109 au lieu de 4.8M. Mais le fait est qu'il fait un HashAggregate et l'exécution est plus rapide. Techniquement ça semble possible de passer par un HashAggregate plutôt que par un SortAggregate. Il me semble qu'il n'est pas possible de "forcer" le HashAggregate car ce n'est pas dans l'idéologie de PostgreSQL.
Pour la jointure, il fait un HashJoin plutôt qu'un MergeJoin et est là aussi plus rapide: 7s contre 30s. On passe quand même en tout de 23s à 10min16s; ramené à la taille cible, on perd des heures! Les développeurs font donc actuellement leurs traitements en Oracle qui lui doit bien optimiser son plan d'exécution...
Il semble alors que l'optimiseur ne soit pas adapter à ce type de requête, somme toute banale. Est-il possible néanmoins de jouer sur certains paramètres pour faire changer d'avis à l'optimiseur? Faut-il attendre la 9.4? Sans ça le passage à PostgreSQL va être dur à faire accepter.
François
Merci pour cette réponse claire et rapide. Mes archives sont déjà sur un serveur tiers, ça va faciliter le travail!
Bonjour,
J'ai configuré une base maître à partir de laquelle j'ai créé une base esclave en streaming replication. Dans recovery.conf, j'ai renseigné les 2 paramètres primary_connifo et restore_command (dans le cas où la streaming n'arrive pas à suivre le rythme du maître, le log shipping prend le relais). La base maître archive correctement.
Mon problème est que l'esclave n'archive pas. Pourtant le fichier postgresql.conf est exactement le même car il est une copie du maître. Est-ce un comportement normal? En fait je souhaite que l'esclave produise ses archives en vue de créer des esclaves de l'esclave qui pourront eux aussi activer le log shipping.
Bonjour,
Je suppose que cette discution devrait être dans la catégorie logiciel, mais il n'y a pas de fil général dans cette catégorie.
J'ai installé le logiciel de supervision pgwatch pour l'essayer. Ce logiciel s'appuie sur une base de données PostgreSQL comme référentiel. J'ai configuré une base en surveillance. Les infos sont remontées toutes les heures via un cron. La taille du référentiel semble croître à la vitesse de 10Mo/jour/base. Cela me semble énorme si je souhaite surveiller de nombreuses bases. D'autant plus que les résultats remontés ne sont pas extraordinaires!
Ma question est la suivante:
Pgwatch est-il largement utilisé dans la communauté? Et quelles sont les retours le concernant?
Merci d'avance pour vos réponses.
Je pense que c'est en utilisant
LC_COLLATE = 'en_CA.UTF-8'
LC_CTYPE = 'en_CA.UTF-8'
que la création a marché, pas grâce à l'utilisation de template0.
Essayez:
CREATE DATABASE db_test
WITH OWNER = sinfra
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
CONNECTION LIMIT = -1 TEMPLATE template0;et je pense que ça ne marchera pas.
Soit 200*4MB, autrement 800MB.
200*18 plutôt = 3,6 GB aussi.
Mon serveur fait 4Go de RAM mais j'ai passé en paramètre à pgtune -M 4294967296, d'où la petite différence.
Je vais suivre le conseil de diviser par 2 work_mem, d'autant que le site rencontre des pics de fréquentation à la "clôture des inscriptions".
Ou alors le risque est que la mémoire swap, ce qui n'est finalement pas si méchant que ça.
En fait work_mem=13MB et max_connections=300, c'est pour une base OLTP.
Pour une base Web, pgtune donne work_mem=20MB et max_connections=200.
work_mem * max_connections = 4000MB : c'est encore pire!!!
Si je cromprend bien, il vaut mieux baisser un des deux paramètres?
Bonjour,
je configure une base de données de type Web en utilisant pgtune. Pour un serveur avec 4Go de RAM, pgtune me donne:
maintenance_work_mem = 256MB
work_mem = 13MB
shared_buffers = 1GB
max_connections = 300work_mem * max_connections = 3900MB
alors work_mem * max_connections + maintenance_work_mem + shared_buffers >>> 4GB
Même si work_mem n'est qu'un maximum de ressource utilisable par un utilisateur, n'y a-t-il pas un risque d'explosion de la RAM et donc de la base de données?
Merci pour vos éclaircissements!
Bonjour,
Je cherche à régler le paramètre effective_cache_size dans le cas d'un serveur à plusieurs clusters. Dans le cas d'un seul cluster, grossièrement je positionne shared_buffer à 1/4 de la RAM et effective_cache_size à 2/3 de la RAM (shared_buffer + cache disk). D'après ce que je comprends, shared_buffer est "inclus" dans effective_cache_size.
Par exemple sur un serveur avec 36Go de RAM, je souhaite faire cohabiter 2 clusters avec le premier 2 fois plus "gros" que le deuxième. Je fixe:
shared_buffer(1): 1/4*2/3*36 = 6Go
shared_buffer(2): 1/4*1/3*36 = 3Go
La question que je me pose est: dois-je fixer effective_cache_size à:
les 2 effective_cache_size disjoints:
effective_cache_size(1): 2/3 * (2/3 * RAM) = 2/3*2/3*36 = 16Go
effective_cache_size(2): 1/3 * (2/3 * RAM) = 2/3*1/3*36 = 8Go
ou
effective_cache_size avec une partie commune (cache disk):
effective_cache_size(1): 2/3*1*36 - shared_buffer(2) = 21Go
effective_cache_size(2): 2/3*1*36 - shared_buffer(1) = 18Go
En résumé, le cache disk doit-il être définit comme commun à tous les clusters?