Vous n'êtes pas identifié(e).
Effectivement, c'est une appli cliente .....
Merci.
Pas un process postgres ? Cf ci-dessous.
En tout cas ces process, puisqu'il y a en ici 3, sont fils du process postmaster et ils sont toujours présents à cette heure.
prompt> ps -ef | grep postgres
postgres 7729 1 0 Sep26 ? 00:01:37 /usr/pgsql-9.1/bin/postmaster -p 5432 -D /pgdata/data
postgres 7808 7729 0 Sep26 ? 00:00:40 postgres: logger process
postgres 7810 7729 0 Sep26 ? 00:05:00 postgres: writer process
postgres 7811 7729 0 Sep26 ? 00:02:52 postgres: wal writer process
postgres 7812 7729 0 Sep26 ? 00:03:10 postgres: autovacuum launcher process
postgres 7813 7729 0 Sep26 ? 00:04:18 postgres: stats collector process
postgres 7815 7729 7 Sep26 ? 01:19:04 postgres: auditdb auditdb 127.0.0.1(60984) idle
postgres 7821 7729 0 Sep26 ? 00:00:09 postgres: auditdb auditdb 127.0.0.1(60986) idle
postgres 8905 7729 0 Sep26 ? 00:00:02 postgres: archi archi [local] idle
postgres 29070 7729 0 00:00 ? 00:00:00 postgres: auditdb auditdb 127.0.0.1(40788) idle
Un "lsof" montre des accès sur les fichiers de la base.
Pour info: CentOS release 6.2 (Final)
J'ai regardé sur tous mes autres serveurs, je n'ai jamais vu de tels process.
Cordialement.
Bonjour à tous.
Nous venons de migrer une première base de 9.1.3 vers du 9.1.6.
Un process "auditdb" est présent depuis le redémarrage de la base.
Quel est son rôle ? Etait-ce un process présent avec les autres distribs ?
Merci par avance.
Bonjour.
je viens de m'apercevoir en montant un serveur 9.1.4 (sur une distribution Linux) que le fichier /etc/init.d/postgresql-9.1 livré ne gère plus par défaut les installations de plusieurs instances de base sur la même machine ce qui n'était pas le cas sur mes 8.4.x.
Ce n'est pas très grave, mais en l'état, la commande 'service postgresql-9.1 status ' retourne le status de la dernière instance démarrée.
En effet, le fichier qui sert de référence à la commande (pidfile) a un nom unique.
En 8.4.x, on avait un fichier suffixé par le port de chaque instance
au start : /var/run/postmaster.${PGPORT}.pid
au stop : rm -f "/var/run/postmaster.${PGPORT}.pid"
status : status -p /var/run/postmaster.${PGPORT}.pid
Pour la 9.1.4, le pid file est constant:
root@ccc #vi /etc/init.d/postgresql.9-1
#!/bin/sh
#
# postgresql This is the init script for starting up the PostgreSQL
# server.
#
# chkconfig: - 64 36
# description: PostgreSQL database server.
# processname: postmaster
# pidfile: /var/run/postmaster-9.1.pid
....
....
Pour palier ce problème, j'ai modifié le fichier livré en nommant "$pidfile" avec le nom du service
pidfile="/var/run/${NAME}.pid" (on peut aussi surcharger sa définition dans les fichiers spécifiques /etc/sysconfig/pgsql/${NAME}).
Cordialement.
Bonjour Guillaume.
Le redémarrage de la base a été efficace. Fichiers nettoyés !
Bon WE
Bonjour à tous.
J'ai cherché qqs infos sur ces fichiers qui trainent sous les répertoires pgsql_tm.
J'ai bien noté qu'ils sont créés suite à une activité anormale (tris énormes).
Dans mon cas, environ 25 Go végètent dans le FS qui héberge ma base à priori depuis 1 mois selon la date des fichiers.
Est-ce que seul le démarrage de la base est préconisé comme solution de nettoyage OU peut-on tenter un rm sur les fichiers en s'assurant que les process, dont les PID servent de suffixes dans le nom des fichiers sous-jacents, ne sont plus actifs ?
Dans ce dernier cas, risque-t-on d'être confronté à des références restantes au niveau de l'instance et donc d'avoir des soucis de fonctionnement ?
Merci pour vos réponses.
David.
PS : je suis sur une 8.4.5, en développement (d'où le phénomène certainement -> requête douteuse ?), volume 500Go
Bonjour Guillaume.
J'ai des nouveaux serveurs en 9.1 à installer.
Ces serveurs de prod seront accédés par de nouvelles machines clientes, installées par défaut avec une version 8.4.
Les accès qui seront faits depuis ces machines clientes sont principalement réalisés par des API "maison", écrites en C (compilation ecpg) ou bien des connexions JDBC, voire de manière plus exotique par des qqs sessions 'psql'.
Pour le démarrage du projet, je pense qu'il est préférable de passer directement sur la même version entre clients et serveurs.
Mon soucis est de peser quel est le risque que l'on prend en ne faisant pas les montées de niveau sur les clients au même rythme que sur les serveurs (tout en prenant en compte le nombre de clients à migrer).
Il y-a-t-il eu jusqu'à présent des incompatibilités notées entre certaines versions de serveurs et de clients ? De quel type ?
Merci.
Bonjour à tous.
Je dispose actuellement de serveurs en version 9.1.3
Par ailleurs, des machines distantes doivent accéder à ces bases via des connexions de type JDBC, ecpg, etc ...
Ces machines disposent par défaut à l'install (RHEL6) de la version Postgres 8.4.9
Ma question est de savoir quelles sont les recommandations en terme de migration des versions de clients en fonction des versions de serveurs.
Ai-je un intérêt à mettre à jour les RPM ? Existe-t-il une matrice de compatibilité ?
Merci.
Hello, non pas facile, du bash quoi, mais à la (b)hâche on arrive à faire qq chose !
Pour compter le nombre de lignes et tester le code retour on peut tenter ce qu'il y a ci-dessous.
>> "récupérer le résultat de la commande sql " ?
D'autre part, pour obtenir le résultat du listing, il faut employer l'option -o (output) de psql.
David.
$>echo "Nombre tuples : " ; psql -Ubd bd -t -c "select count(*) from matab" ; err=$?; echo "Code retour commande :" ; echo $err
Nombre tuples :
18994554170
Code retour commande :
0
$>echo "Nombre tuples : " ; psql -Ubd bd -t -c "select count(*) from matab where 1=2" ; err=$?; echo "Code retour commande :" ; echo $err
Nombre tuples :
0
Code retour commande :
0
$>echo "Nombre tuples : " ; psql -Ubd bd -t -c "SSSS count(*) from matab" ; err=$?; echo "Code retour commande :" ; echo $err
Nombre tuples :
ERROR: syntax error at or near "SSSS"
LINE 1: SSSS count(*) from matab
^
Code retour commande :
1
Bonjour.
Pour l'interprétation, c'est bien ce que je pensais en parlant d'une certaine logique. Je l'avais comprise et je trouve ceci très dangereux, notamment pour ceux qui viennent de "l'autre monde" et qui utilisent le SGBD comment élément de validation en entrée (et oui on a eu cette année des collègues européens qui nous ont envoyé des données datées du 00-MARS-2011 et sur nos plateformes Postgres, on a du les entrer sans soucis à la date du 01/03 !!!!! Gloupsss ).
D'ailleurs un gros warning dans la doc serait intéressante, juste pour signaler les différences de comportement, sensibiliser aux résultats et peut-être plus orienter vers le cast explicite.
De notre côté, nous allons devoir reporter toutes les vérifications de format lors d'insertions de données au niveau des exécutables (ou surcharger la fonction ?) à moins que nous arrivions à utiliser le cast '::to_timestamp' avec nos multiples formats en entrée. A voir. Bref, du bouleau sur la planche ...
Merci pour vos réponses, David.
***********************************************************
C'est vrai que le cast est plus blindé !
syn=> select '2011-03-00 12:01:00+00'::timestamp;
ERROR: date/time field value out of range: "2011-03-00 12:01:00+00"
LINE 1: select '2011-03-00 12:01:00+00'::timestamp;
^
HINT: Perhaps you need a different "datestyle" setting.
Bonjour à tous.
J'ai un soucis sur la compréhension du comportement de la fonction to_timestamp.
Si la variable proposée au formatage est erronée, d'une part la fonction ne retourne pas d'erreur mais elle retourne une valeur qui peut sembler aléatoire (mais qui correspondrait tout de même à une certaine logique ...).
En tout cas ceci est assez pénalisant dans le cadre du portage de nos applications car les fonctions analogues sous Oracle génèrent obligatoirement une erreur.
Avons-nous oublié un paramètre de configuration niveau serveur ?
David.
***********************************************************************************************************
Exemple 1 : test de formatage sur 3 versions PG différentes avec la même date suffixée par des '00' parasites
psql (8.4.5)
bdcp=> select to_timestamp('2011070500','YYYYMMDD');
to_timestamp
------------------------
2012-11-11 00:00:00+00
(1 row)
Welcome to psql 8.2.6, the PostgreSQL interactive terminal.
syn=> select to_timestamp('2011070500','YYYYMMDD');
to_timestamp
------------------------
2011-07-05 00:00:00+00
psql (9.0.2)
syn=> select to_timestamp('2011070500','YYYYMMDD');
to_timestamp
------------------------
2012-11-11 00:00:00+00
(1 row)
***********************************************************************************************************
Exemple 2 : test de formatage avec un mois erroné (mois=13)
bdcp=> select to_timestamp('20111302','YYYYMMDD');
to_timestamp
------------------------
2012-01-02 00:00:00+00
(1 row)
***********************************************************************************************************
Exemple 3 : test de formatage avec date tronquée
bdcp=> select to_timestamp('200015','YYYYMMDD');
to_timestamp
------------------------
2001-03-03 00:00:00+00
(1 row)
Bref pas mal de combinaisons possibles ....
Merci pour vos éclaircissements.
Voici qqs paramètres.
J'aimerai avoir un peu plus d'infos sur le calibrage du paramètre cost_limit ?
postgres=# show vacuum_cost_delay;
vacuum_cost_delay
-------------------
0
postgres=# show autovacuum_vacuum_cost_delay ;
autovacuum_vacuum_cost_delay
------------------------------
20ms
postgres=# show autovacuum_vacuum_cost_limit
postgres-# ;
autovacuum_vacuum_cost_limit
------------------------------
-1
(1 row)
postgres=# show vacuum_cost_limit
;
vacuum_cost_limit
-------------------
200
(1 row)
Bonjour à tous.
J'ai quelques problèmes avec le process autovacuum sur une de mes tables. Je m'explique ...
Depuis une semaine, j'ai reconstruit la totalité de ma base de données.
En effet, j'avais jusque là laissé les paramètres par défaut concernant les paramètres autovacuum.
Or vu le volume de certaines d'entre elles (3 culminent à 600, 300 et 120 millions de lignes) et la quantité de lignes modifiées quotidiennement, le process autovaccum n'était jamais passé !
Au bout de qqs semaines d'utilisation j'ai noté des dégradations sur les performances, notamment en écriture.
Ainsi, j'ai fait des stats quotidiennes (en scrutant la table pg_stats_user_tables) et ai modifié en conséquence, pour les 3 tables citées, les paramètres autovacuum_vacuum_scale_factor et autovacuum_analyze_scale_factor afin d'obtenir un passage quasi-quotidien des process de nettoyage et d'analyse.
Depuis une semaine, 2 des 3 trois tables ont été analysées puis nettoyées. Sur la dernière H_V1, le quota vacuum fixé (scale_factor modifié, threshold laissé par défaut) a bien été dépassé (n_tup_upd +n_tup_del =728.538 contre 140.000 pour le seuil) , le process autovaccum est lancé mais semble être inactif depuis qqs jours (cf listing).
LISTING1 : table H_V1 - 280M lignes - autovaccum réglé pour 140.000 lignes env.
=============================================================
postgres=# select * from pg_stat_activity ;
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
-------+----------+---------+----------+----------+----------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+-------------+-------------
16385 | bdcp | 3018 | 10 | postgres | autovacuum: VACUUM obs.h_v1 | f | 2010-05-06 10:33:27.627509+00 | 2010-05-06 10:33:27.627509+00 | 2010-05-06 .........
11564 | postgres | 24920 | 10 | postgres | select * from pg_stat_activity ; | f | 2010-05-12 13:01:04.16843+00 | 2010-05-12 13:01:04.16843+00 | 2010-05-12 .......
bdcp=> select schemaname,relname,n_tup_ins,n_tup_upd,n_tup_del,n_dead_tup,last_vacuum,last_autovacuum,last_analyze,last_autoanalyze
from pg_stat_user_tables where relname like 'h_v%';
schemaname | relname | n_tup_ins | n_tup_upd | n_tup_del | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
-------------------------+-----------+-----------+-----------+------------+-------------+-----------------+--------------+-------------------------------
obs | h_v1 | 288157136 | 0 | 728538 | 686634 | | | | 2010-05-06 10:29:51.321024+00
(1 row)
bdcp=> select relname,reltype,relpages,reltuples,relacl,reloptions from pg_class where relname like 'h_v%';
relname | reltype | relpages | reltuples | reloptions
-----------+---------+----------+-------------+---------------------------------------------------+--------------------------------------------------------------------------------
h_v1 | 326354 | 5774704 | 2.86477e+08 | {autovacuum_vacuum_scale_factor=0.0005,autovacuum_analyze_scale_factor=0.0005}
(2 rows)
Il y-a-t-il un moyen de savoir l'état de progression du process ?
Je n'ai aucun retour dans la log pour savoir si le process a été endormi par le postmaster ? A-t-il dépassé un seuil ?
Merci de m'éclairer sur le sujet si vous avez des infos.
David.
OK message reçu Marc.
Merci pour le support.
Effectivement, cela parait correct pour le SELECT:
bdcp=> show constraint_exclusion;
constraint_exclusion
----------------------
partition
(1 row)
bdcp=> explain
select * from mn_v1 where num_poste=31069001;
QUERY PLAN
--------------------------------------------------------------------------------------------------
Result (cost=2.27..40157.05 rows=422678 width=41)
-> Append (cost=2.27..40157.05 rows=422678 width=41)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=148)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Bitmap Heap Scan on mn_v1_dep31 mn_v1 (cost=6552.20..40151.65 rows=422676 width=41)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on pk_mn_v1_dep31 (cost=0.00..6446.53 rows=422676 width=0)
Index Cond: (num_poste = 31069001)
(10 rows)
Bonjour à tous.
J'ai qqs soucis de performances avec une table partitionnée.
J'avais, à l'époque de la 8.3.3, positionné le paramètre constraint_exlusion=on pour forcer l'analyseur.
Par contre j'ai qqs doutes sur ce qui est décrit dans la doc 8.4 par rapport à ce que l'explain montre:
"La valeur par défaut (et donc recommandée) de constraint_exclusion n'est ni on ni off, mais un état intermédiaire appelé partition, qui fait que la technique est appliquée seulement aux requêtes qui semblent fonctionner avec des tables partitionnées.")
Voici ma config par défaut donc:
bdcp => show constraint_exclusion ;
constraint_exclusion
----------------------
partition
(1 row)
bdcp=> explain
delete * from mn_v1 where num_poste=31069001;
QUERY PLAN
----------------------------------------------------------------------------------------------
Append (cost=2.27..373978.79 rows=737150 width=6)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep01 on mn_v1_dep01 mn_v1 (cost=0.00..4.62 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep02 on mn_v1_dep02 mn_v1 (cost=0.00..4.53 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep03 on mn_v1_dep03 mn_v1 (cost=0.00..4.82 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep04 on mn_v1_dep04 mn_v1 (cost=0.00..4.60 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep05 on mn_v1_dep05 mn_v1 (cost=0.00..4.73 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep06 on mn_v1_dep06 mn_v1 (cost=0.00..5.30 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep07 on mn_v1_dep07 mn_v1 (cost=0.00..5.19 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep08 on mn_v1_dep08 mn_v1 (cost=0.00..4.49 rows=1 width=6)
Index Cond: (num_poste = 31069001)
-> Index Scan using pk_mn_v1_dep09 on mn_v1_dep09 mn_v1 (cost=0.00..4.46 rows=1 width=6)
Index Cond: (num_poste = 31069001)
..........
..........
ETC ETC jusqu'à 100 partitions.
Par contre si je force constraint_exclusion à la main ...
bdcp=> SET constraint_exclusion = on;
SET
bdcp=> show constraint_exclusion
;
constraint_exclusion
----------------------
on
(1 row)
bdcp=> explain
delete from mn_v1 where num_poste=31069001;
QUERY PLAN
-------------------------------------------------------------------------------------------
Append (cost=2.27..40136.12 rows=422484 width=6)
-> Bitmap Heap Scan on mn_v1 (cost=2.27..5.40 rows=2 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on mn_v1_pkey (cost=0.00..2.27 rows=2 width=0)
Index Cond: (num_poste = 31069001)
-> Bitmap Heap Scan on mn_v1_dep31 mn_v1 (cost=6546.70..40130.72 rows=422482 width=6)
Recheck Cond: (num_poste = 31069001)
-> Bitmap Index Scan on pk_mn_v1_dep31 (cost=0.00..6441.08 rows=422482 width=0)
Index Cond: (num_poste = 31069001)
(9 rows)
Beaucoup mieux, on se limite à la partition cible.
Ai-je mal interprété la documentation ? Ai-je qq part une surcharge du paramètre "constraint_exlusion" ? Un comportement modififié par des mauvaises stats ?
Merci par avance.
David.
Ok bien reçu. On va donc essayer de tronçonner au plus juste pour économiser de la RAM.
Merci pour vos interventions.
David.
Bonjour Marc.
Question patch, cela concerne-t-il la dernière version ou la version que j'ai utilisée pour ces tests (8.3.3) ?
Puis-je espérer mieux avec la version 8.4 sur laquelle je vais reconstruire ma base aujourd'hui ?
Bonjour à tous
Suite des infos.
Il apparait effectivement que la mémoire augmente durant le COPY.
Pour la création de la table temporaire, j'ai noté votre conseil. Quel est l'apport de cette commande ?
Sinon, je vous communique l'ordre de création de la table et des objets associés.
1 - L'ordre de création de la table "mère"
CREATE TABLE mastertab (
id_client integer not null,
"dat" timestamp NOT NULL,
"datrecu" timestamp NOT NULL,
puis
............
200 colonnes composées principalement de smallint er real
............
);
2 - L'ordre de création des partitions (1 par département administratif)
CREATE TABLE tab_part01 (CHECK (id_client >= 01000000 and id_client <= 01999999)) INHERITS (mastertab);
CREATE TABLE tab_part02 (CHECK (id_client >= 02000000 and id_client <= 02999999)) INHERITS (mastertab);
CREATE TABLE tab_part03 (CHECK (id_client >= 03000000 and id_client <= 03999999)) INHERITS (mastertab);
CREATE TABLE tab_part04 (CHECK (id_client >= 04000000 and id_client <= 04999999)) INHERITS (mastertab);
.............
.............
.............
CREATE TABLE tab_part97 (CHECK (id_client >= 97000000 and id_client <= 97999999)) INHERITS (mastertab);
CREATE TABLE tab_part98 (CHECK (id_client >= 98000000 and id_client <= 98999999)) INHERITS (mastertab);
CREATE TABLE tab_part99 (CHECK (id_client >= 99000000 and id_client <= 400999999)) INHERITS (mastertab);
3 - L'ordre de création de la fonction appelée par le trigger d'insert créé sur la table mère (voir l'ordre de création du trigger au N°4)
CREATE OR REPLACE FUNCTION insert_master_tab()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.id_client >= 01000000 AND NEW.id_client <=01999999 ) THEN INSERT INTO prod.tab_part01 VALUES (NEW.*);
ELSIF ( NEW.id_client >= 02000000 AND NEW.id_client <=02999999 ) THEN INSERT INTO prod.tab_part02 VALUES (NEW.*);
ELSIF ( NEW.id_client >= 03000000 AND NEW.id_client <=03999999 ) THEN INSERT INTO prod.tab_part03 VALUES (NEW.*);
.............
.............
.............
ELSIF ( NEW.id_client >= 98000000 AND NEW.id_client <=98999999 ) THEN INSERT INTO prod.tab_part98 VALUES (NEW.*);
ELSIF ( NEW.id_client >= 99000000 ) THEN INSERT INTO prod.tab_part99 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Impossible d inserer une donnee dans MASTERTAB';
END IF;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
4 - L'ordre de création du trigger
CREATE TRIGGER trg_insert_mastertab
BEFORE INSERT ON mastertab
FOR EACH ROW
EXECUTE PROCEDURE insert_master_tab();
5 - Création des PK et index (3 par partitions)
ALTER TABLE tab_part01 add constraint pk_tab_part01 primary key (id_client,dat);
CREATE INDEX i_tab_part01_dat on tab_part01(dat);
CREATE INDEX i_tab_part01_datrecu on tab_part01(datrecu);
ALTER TABLE tab_part02 add constraint pk_tab_part02 primary key (id_client,dat);
CREATE INDEX i_tab_part02_dat on tab_part02(dat);
CREATE INDEX i_tab_part02_datrecu on tab_part02(datrecu);
.............
.............
.............
ALTER TABLE tab_part99 add constraint pk_tab_part99 primary key (id_client,dat);
CREATE INDEX i_tab_part99_dat on tab_part99(dat);
CREATE INDEX i_tab_part99_datrecu on tab_part99(datrecu);
Bonne journée, David.
Bonjour Marc.
Pour être plus précis, en fait l'admin système m'a indiqué qu'un process postmaster a occupé la quasi totalité de la mémoire du serveur juste avant le blocage (environ 10 Go et non 16 comme j'ai pu noter).
Pour valider le fait que cette commande a pu conduire au crash du serveur, j'ai recommencé l'opération mais en scrutant régulièrement la mémoire occupée par le postmaster.
Après 5 minutes de traitement, j'ai arrêté le chargement car la consommation mémoire était bien en train d'augmenter et de façon linéaire. Ci-dessous, la commande top (4.8Go occupée avant mon CTRL+C).
top - 14:19:10 up 5 days, 4:10, 12 users, load average: 1.47, 1.75, 1.60
Tasks: 348 total, 1 running, 347 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.5% us, 0.8% sy, 0.0% ni, 73.8% id, 23.7% wa, 0.0% hi, 0.2% si
Mem: 16413588k total, 16391264k used, 22324k free, 105404k buffers
Swap: 8388472k total, 428k used, 8388044k free, 11368332k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29965 postgres 15 0 5304m 4.8g 971m D 6 30.8 3:05.00 postmaster
17776 bd 15 0 37488 2012 1216 S 2 0.0 1:26.45 sshd
17777 bd 15 0 82348 16m 11m S 1 0.1 0:32.80 konsole
17850 root 16 0 6416 1224 752 S 1 0.0 1:16.84 top
[postgres log]$ ps -ef |grep 29965
postgres 29965 6214 2 13:50 ? 00:00:37 postgres: client bd [local] COPY
Pour rappel, cette table de données contient environ 200millions de lignes. Pour les raisons de performances évoquées précédemment, je l'ai donc partitionnée. J'ai créé 100 tables héritées d'une table primaire sur laquelle j'ai posé un trigger pour l'insert des données en fonction des clés de partitionnement. Pour les besoins applicatifs, j'ai créé une PK et 2 index sur chacune des partitions.
Le script utilisé fait :
1 - CREATE TEMPORARY TABLE tmp as select * from BIG_TABLE where 1=2; => pour récupérer la structure de la table de 200Mlignes
2 - copie ensuite le contenu d'un fichier de données dans cette table temporaire via la commande COPY
3 - efface le contenu de la table de 200Ml avec les lignes contenues dans la table temporaire (DELETE)
4 - insére les lignes de la table temporaire dans BIG_TABLE
Pour finir, la valeur du paramètre work_mem=100MB
Bonjour.
Je suis nouvel utilisateur PG ce qui fait que je maitrise pas les aspects noyaux de Postgres.
J'espère donc que vous pourrez m'aider.
Je suis confronté à un problème durant le chargement d'une table de données d'environ 200 millions de lignes.
J'ai lancé la semaine dernière un ordre DELETE+COPY sur cette table pour environ 1 million de lignes. Cette opération a été assez longue ce qui a pénalisé la suite des ordres de chargement (batchs en exécution séquentielle obligatoire).
Suite à ces problèmes de performances, j'ai donc pris l'option de recréer cette table avec des partitions (une centaine).
Les performances ont été très significatives.
Cette semaine, durant le chargement d'un fichier plus volumineux (10 millions de lignes à effacer puis à insérer), l'opération a conduit à un hang du serveur. Pour debug, j'ai réitéré l'opération avec le même fichier et il est apparu que la taille mémoire utilisée par le process postmaster croit jusqu'à monopoliser la taille max du serveur (16Go) ce qui conduit à une indisponibilité !
Je précise que le fichier de données est tout d'abord inséré dans une table temporaire pour traitement partiel (COPY dans TEMPORARY TABLE), puis suivi d'un delete dans la table cible en fonction de clés de cette table temporaire, et ensuite un insert as select ... pour transvaser les données.
Existe-t-il un moyen de limiter la consommation mémoire ? Au niveau transaction puis au niveau global du postmaster (notamment pour éviter le hang serveur) ?
Ma config système:
RHEL 2.6.9
Postgres 8.3.3
RAM 16Go
Quelques paramètres PG:
bd=> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)
bd=> show maintenance_work_mem ;
maintenance_work_mem
----------------------
1GB
(1 row)
bd=> show temp_buffers ;
temp_buffers
--------------
1024
(1 row)
