Messages de saigamp

saigamp · PgAdmin3

Merci, ça fonctionne désormais.

saigamp · PgAdmin3

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

saigamp · Optimisation

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  0

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

saigamp · Optimisation

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!

saigamp · Optimisation

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.

saigamp · Optimisation

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

Les disques sont formatés en ext4 et montés avec les options defaults,noatime,nodiratime.

saigamp · Optimisation

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

saigamp · Optimisation

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

saigamp · Optimisation

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.

saigamp · Optimisation

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.

saigamp · Optimisation

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 ms

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

saigamp · Optimisation

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 ms

saigamp · Optimisation

gleu a écrit :

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

saigamp · Optimisation

SQLpro a écrit :

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

saigamp · Optimisation

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!

saigamp · Optimisation

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 ms

L'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 ms

Le 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

saigamp · Réplication

Merci pour cette réponse claire et rapide. Mes archives sont déjà sur un serveur tiers, ça va faciliter le travail!

saigamp · Réplication

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.

saigamp · Général

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.

saigamp · Installation

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.

saigamp · Optimisation

gleu a écrit :

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

saigamp · Optimisation

Ou alors le risque est que la mémoire swap, ce qui n'est finalement pas si méchant que ça.

saigamp · Optimisation

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?

saigamp · Optimisation

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

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

saigamp · Optimisation

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?

#1 Re : PgAdmin3 » installation sur W7 » 29/04/2015 13:03:51

#2 PgAdmin3 » installation sur W7 » 28/04/2015 16:32:16

#3 Re : Optimisation » mauvais choix de l'optimiseur » 13/05/2014 16:06:07

#4 Re : Optimisation » mauvais choix de l'optimiseur » 12/05/2014 11:26:25

#5 Re : Optimisation » mauvais choix de l'optimiseur » 07/05/2014 17:04:56

#6 Re : Optimisation » mauvais choix de l'optimiseur » 07/05/2014 16:08:58

#7 Re : Optimisation » mauvais choix de l'optimiseur » 05/05/2014 13:20:26

#8 Re : Optimisation » mauvais choix de l'optimiseur » 30/04/2014 14:44:12

#9 Re : Optimisation » mauvais choix de l'optimiseur » 29/04/2014 10:12:46

#10 Re : Optimisation » mauvais choix de l'optimiseur » 28/04/2014 17:35:32

#11 Re : Optimisation » mauvais choix de l'optimiseur » 28/04/2014 11:10:31

#12 Re : Optimisation » mauvais choix de l'optimiseur » 25/04/2014 17:42:08

#13 Re : Optimisation » mauvais choix de l'optimiseur » 25/04/2014 16:59:41

#14 Re : Optimisation » mauvais choix de l'optimiseur » 25/04/2014 16:58:36

#15 Re : Optimisation » mauvais choix de l'optimiseur » 25/04/2014 14:34:53

#16 Optimisation » mauvais choix de l'optimiseur » 25/04/2014 14:33:13

#17 Re : Réplication » l'esclave n'archive pas » 26/07/2013 16:12:43

#18 Réplication » l'esclave n'archive pas » 26/07/2013 14:45:07

#19 Général » pgwatch » 31/08/2012 15:31:58

#20 Re : Installation » Installation postgresql-9.1 sur ubuntu hebergant postgresql-8.4 » 25/04/2012 08:57:47

#21 Re : Optimisation » work_mem pgtune » 25/04/2012 08:39:56

#22 Re : Optimisation » work_mem pgtune » 24/04/2012 10:22:01

#23 Re : Optimisation » work_mem pgtune » 24/04/2012 08:12:27

#24 Optimisation » work_mem pgtune » 23/04/2012 18:19:32

#25 Optimisation » effective_cache_size et multi-cluster » 19/04/2012 13:25:36

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux