Vous n'êtes pas identifié(e).
Pages : 1
Ok, merci pour l'aide Julien!
Merci pour la réponse, je ne pense pas que ce soit des fonctions que nous ayons mis nous même en place, ce peut être des scories de vieilles versions de postgres? (on a commencé sur du pg7.4).
Bonjour,
j'ai précédemment fait une demande pour un problème avec la lib pltcl, j'ai refait mon install avec apt-get plutôt qu'une compilation manuelle, tout va bien.
J'ai quelques erreurs qui subsistent (ou avertissements).
psql:/opt/infocentre.dat:556: ATTENTION: la fonction en entrée du type chkpass_in ne doit pas être volatile
psql:/opt/infocentre.dat:556: ATTENTION: la fonction en entrée du type chkpass_out ne doit pas être volatile
psql:/opt/infocentre.dat:658: ATTENTION: la fonction en entrée du type gbtreekey16_in ne doit pas être volatile
psql:/opt/infocentre.dat:658: ATTENTION: la fonction en entrée du type gbtreekey16_out ne doit pas être volatile
psql:/opt/infocentre.dat:702: ATTENTION: la fonction en entrée du type gbtreekey32_in ne doit pas être volatile
psql:/opt/infocentre.dat:702: ATTENTION: la fonction en entrée du type gbtreekey32_out ne doit pas être volatile
psql:/opt/infocentre.dat:746: ATTENTION: la fonction en entrée du type gbtreekey4_in ne doit pas être volatile
psql:/opt/infocentre.dat:746: ATTENTION: la fonction en entrée du type gbtreekey4_out ne doit pas être volatile
psql:/opt/infocentre.dat:790: ATTENTION: la fonction en entrée du type gbtreekey8_in ne doit pas être volatile
psql:/opt/infocentre.dat:790: ATTENTION: la fonction en entrée du type gbtreekey8_out ne doit pas être volatile
psql:/opt/infocentre.dat:834: ATTENTION: la fonction en entrée du type gbtreekey_var_in ne doit pas être volatile
psql:/opt/infocentre.dat:834: ATTENTION: la fonction en entrée du type gbtreekey_var_out ne doit pas être volatile
psql:/opt/infocentre.dat:878: ATTENTION: la fonction en entrée du type ghstore_in ne doit pas être volatile
psql:/opt/infocentre.dat:878: ATTENTION: la fonction en entrée du type ghstore_out ne doit pas être volatile
psql:/opt/infocentre.dat:922: ATTENTION: la fonction en entrée du type gtrgm_in ne doit pas être volatile
psql:/opt/infocentre.dat:922: ATTENTION: la fonction en entrée du type gtrgm_out ne doit pas être volatile
psql:/opt/infocentre.dat:996: ATTENTION: la fonction en entrée du type hstore_in ne doit pas être volatile
psql:/opt/infocentre.dat:996: ATTENTION: la fonction en entrée du type hstore_out ne doit pas être volatile
psql:/opt/infocentre.dat:1093: ATTENTION: la fonction en entrée du type lquery_in ne doit pas être volatile
psql:/opt/infocentre.dat:1093: ATTENTION: la fonction en entrée du type lquery_out ne doit pas être volatile
psql:/opt/infocentre.dat:1137: ATTENTION: la fonction en entrée du type ltree_in ne doit pas être volatile
psql:/opt/infocentre.dat:1137: ATTENTION: la fonction en entrée du type ltree_out ne doit pas être volatile
psql:/opt/infocentre.dat:1181: ATTENTION: la fonction en entrée du type ltree_gist_in ne doit pas être volatile
psql:/opt/infocentre.dat:1181: ATTENTION: la fonction en entrée du type ltree_gist_out ne doit pas être volatile
psql:/opt/infocentre.dat:1225: ATTENTION: la fonction en entrée du type ltxtq_in ne doit pas être volatile
psql:/opt/infocentre.dat:1225: ATTENTION: la fonction en entrée du type ltxtq_out ne doit pas être volatile
psql:/opt/infocentre.dat:25109: ERREUR: erreur de syntaxe sur ou près de « => »
LIGNE 1 : CREATE OPERATOR => (
^
psql:/opt/infocentre.dat:25112: ERREUR: erreur de syntaxe sur ou près de « => »
LIGNE 1 : ALTER OPERATOR public.=> (text, text) OWNER TO postgres;Je vous donne le code de la fonction create:
CREATE OPERATOR => (
PROCEDURE = tconvert,
LEFTARG = text,
RIGHTARG = text
);Une idée? et que penser des alertes au dessus concernant le "volatile"?
Le code par exemple pour ltxtq_out:
CREATE FUNCTION ltxtq_out(ltxtquery) RETURNS cstring
LANGUAGE c STRICT
AS '$libdir/ltree', 'ltxtq_out';
ALTER FUNCTION public.ltxtq_out(ltxtquery) OWNER TO postgres;Merci par avance.
Olivier
Merci pour vos réponses.
Effectivement je n'avais pas ajouté l'option --with-tcl, mais si je peux faire un apt-get c'est encore mieux, merci Julien.
Bonjour,
J'ai installé postgres9.6 pour faire quelques tests sur cette version (installation via code source sous debian car pas de packets dispo).
J'ai ces erreurs lors d'un psql -f avec un de mes dumps :
psql:/opt/infocentre.dat:345: ERROR: could not open extension control file "/usr/local/pgsql/share/extension/pltcl.control": Aucun fichier ou dossier de ce type
psql:/opt/infocentre.dat:352: ERROR: extension "pltcl" does not exist
...Or si je liste les extensions dispo dans le repertoire contrib de mes sources j'ai:
adminpack btree_gin contrib-global.mk dict_xsyn hstore intarray ltree_plpython passwordcheck pg_prewarm pgstattuple README sslinfo test_decoding unaccent
auth_delay btree_gist cube earthdistance hstore_plperl isn Makefile pg_buffercache pgrowlocks pg_trgm seg start-scripts tsearch2 uuid-ossp
auto_explain chkpass dblink file_fdw hstore_plpython lo oid2name pgcrypto pg_standby pg_visibility sepgsql tablefunc tsm_system_rows vacuumlo
bloom citext dict_int fuzzystrmatch intagg ltree pageinspect pg_freespacemap pg_stat_statements postgres_fdw spi tcn tsm_system_time xml2Pas de pltcl à l'horizon...
Quelle extension dois-je utiliser svp?
Merci par avance,
Olivier Bouiron
Surtout que l'écart de temps est probablement du au contenu des données (transit réseau, affichage dans pgAdmin) plutôt qu'au traitement de la requête par le serveur.
Ce sont les mêmes datas qui sont renvoyées, j'ai ajouté un order by pour prendre les mêmes lignes.
Aprés, c'est vrai que ce n'est pas trés important mais c'était par curiosité.
Effectivement, mais c'est justement ça qui me surprends, c'est que l'execution est quasi la même sur les deux serveurs, mais que le rappatriement des datas via pgadmin prends 2x plus de temps sur le serveur 9.3.
Désolé je viens de voir que je ne suis pas dans la partie pgadmin...
Bonjour,
Notre base de prod étant en 9.3, nous planifions une mise à jour en fin d'année vers la 9.6 si la roadmap est tenue...
On a donc préparé un serveur de tests en 9.6: les conditions sont similaires au niveau du postgresql.conf, les deux serveurs sont sous debian (mais versions de debian différentes).
Par contre grosse différence: la 9.6 tourne sur des disques 7k tours en raid 5 alors que la 9.3 est sur du ssd.
J’exécute une même requête:
select * from premio_presc_v2 a inner join dsi_presc_cycle b on a.id=b.idpres inner join premio_presc_jour_produit c on c.idcycle=b.id where a.nip=200903667 and b.cycle=2 limit 10;Sous 9.6 ça prends 13ms pour afficher le resultat dans pg_admin
Sous 9.3 ça prends 22ms pour afficher le resultat dans pg_admin
Le explain analyze en 9.6 donne:
Limit (cost=1.14..18.45 rows=5 width=1439) (actual time=0.059..0.085 rows=10 loops=1)
-> Nested Loop (cost=1.14..18.45 rows=5 width=1439) (actual time=0.057..0.083 rows=10 loops=1)
-> Nested Loop (cost=0.71..13.53 rows=1 width=986) (actual time=0.042..0.042 rows=1 loops=1)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a (cost=0.29..5.41 rows=2 width=577) (actual time=0.017..0.017 rows=1 loops=1)
Index Cond: (nip = 200903667)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b (cost=0.42..4.05 rows=1 width=409) (actual time=0.019..0.019 rows=1 loops=1)
Index Cond: (idpres = a.id)
Filter: (cycle = 2)
Rows Removed by Filter: 2
-> Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c (cost=0.43..4.58 rows=34 width=453) (actual time=0.011..0.022 rows=10 loops=1)
Index Cond: (idcycle = b.id)
Planning time: 1.645 ms
Execution time: 0.480 mset le explain analyze en 9.3 donne:
Limit (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.055 rows=10 loops=1)
-> Nested Loop (cost=1.14..13.53 rows=5 width=1447) (actual time=0.040..0.054 rows=10 loops=1)
-> Nested Loop (cost=0.71..9.79 rows=1 width=994) (actual time=0.027..0.027 rows=1 loops=1)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a (cost=0.29..3.91 rows=2 width=577) (actual time=0.012..0.012 rows=1 loops=1)
Index Cond: (nip = 200903667)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b (cost=0.42..2.93 rows=1 width=417) (actual time=0.013..0.013 rows=1 loops=1)
Index Cond: (idpres = a.id)
Filter: (cycle = 2)
Rows Removed by Filter: 2
-> Index Scan using idx_presc_jour_premio1 on premio_presc_jour_produit c (cost=0.43..3.48 rows=26 width=453) (actual time=0.010..0.020 rows=10 loops=1)
Index Cond: (idcycle = b.id)
Total runtime: 0.178 msSauriez-vous pourquoi pgadmin prends plus de temps à afficher le résultat depuis la 9.3 alors que normalement, les requêtes devraient être plus rapide sur la 9.3 (cf explain), ce qui d'ailleurs se vérifie par exemple via une connexion jdbc: la requête en 9.3 prends 3ms, tandis qu'en 9.6, c'est 4ms.
Question annexe: est-on censé gagner sérieusement en perf en passant de la 9.3 à la 9.6?
Bonjour Guillaume,
Je comprends mieux, c'est bien ce qui s'est passé.
Au final mes colonnes à null ne prennent donc qu'une place insignifiante alors si je comprends bien.
Merci pour votre aide!
Cordialement
Déjà une table avec une cinquantaine de colonnes il y a très probablement un problème de modélisation.
Merci pour votre commentaire, mais en toute franchise je ne pense pas qu'il soit pertinent.
Il vous faudrait un minimum de connaissance de la fonction de cette table pour formuler un avis...
Je vous remercie quand même de vouloir etre utile.
-------------
Pour en revenir au problème initial:
Une chose m'étonne concernant la taille de la table :
Je crée une table avec 10 millions d'enregistrements: sa taille est T1
Je lui ajoute 10 colonnes de type bigint, sa taille reste T1, j'aurais pensé que ça gonfle pourtant.
Enfin, je fait un update de ces 10 colonnes en mettant tout à null et là la taille explose ...
Quand on ajoute des colonnes, la valeur de ces cellules créées n'est donc pas null, qu'est-ce alors?
Merci pour la réponse, c'est intéressant mais complexe pour les non initiés...
En fait ma réflexion portait sur une table que j'ai contenant 18 millions d'enregistrements (4,1G de table et 3.9G d'index).
Il y a une cinquantaine de colonnes dont une trentaine de type int, text ou timestamp la plupart du temps à null (95% des lignes ont ces colonnes à null).
Si je comprends bien, je gagnerai de l'espace à créer une table annexe pointant par id la première table et sur laquelle je mettrai la trentaine de colonnes ?
Bonjour,
Une question: si je crée une table :
CREATE TABLE test.table1
(
c1 double precision,
c2 bigint,
c3 double precision
)WITH ( OIDS=FALSE );
ALTER TABLE test.table1 OWNER TO postgres;
Et que j'insere 18 400 000 de lignes en mettant tout à null, ma table fait : 989MB.
Je pensais que si les valeurs étaient nulles on ne perdait pas de place...
Plus étrange, si j'enleve les colonnes c2 et c3, la taille passe à 495MB, soit la moitié, alors que j'ai retiré deux colonnes sur trois.
Enfin, j'ai tenté des calculs, si il y avait des infos dans ces colonnes au lieu de null:
18 400 000 * ( 8 bits + 8 bits + 8 bits, soit 24 bits ) = 421Mo de datas
Au lieu des 421Mo j'ai 989Mo et en plus c'est tout null...
Quelqu'un saurait m'expliquer svp?
Merci!
Olivier B.
Il s'agit de clients java lourds (swing) donc pas de pool.
Je vais lire la doc que vous m'avez donnez en lien, merci.
Bonjour,
Je connecte des clients à postgres depuis une appli java via JDBC.
Une connection par client, la connection reste toujours active.
Cependant par moment je ne vois pas certains clients dans pg_stat_activity puis ils réapparaissent.
Il me semblait que cette vue permettait d'avoir la liste des backend avec leur pid.
Est-il possible qu'un client garde une connection acteve via jdbc mais n'apparaisse pas dans pg_stat_activity? (par exemple s'il ne fait pas de requetes pendant quelques secondes)?
De plus imaginons que j'ai des coupures réseaux, quelle durée faut il pour que le client n'apparaisse plus dans pg_stat_activity? c'est immédiat des que la personne n'est plus sur le reseau ou il y a un temps défini?
Merci pour votre aide.
Olivier Bouiron
C'est donc assez complexe...
Je vais travailler à une simulation pg_bench assez proche de la réalité et régler mes parametres à taton alors.
Merci pour votre aide !
Dommage...
Du coups, pour info, si j'ai par exemple:
select * from a inner join b on a.id=b.id inner join c on c.id_a=a.id and c.num>2 where a.code='mon code' and c.code='autre code' order by a.id
Je compterai :
=> 2 inner join=2 work_mem
=> 2 conditions dans le where = 2 work_mem
=> 1 order by = 1 work_mem
Soit 5 work_mem au total?
Je comprends.
Merci pour votre aide, je pense que ça va résoudre le problème!
Par contre deux questions:
si je veux correctement estimer ma conso max, c'est bien:
shared_mem+ (nb de workers*maintenance_mem) + (max_connexions*work_mem*nb_max de work_mem par requete) ? Sachant que le nombre de work_mem par requete est dur à estimer pour faire une estimation max... ?
ça m'amène à la question 2: est-il possible d'afficher un graphe de l'utilisation des work_mem, un graphe de la shared, et un des maintenance dans un outil du genre pg_badger par exemple?
C'est utile du coups de le laisser à 2?
C'est pas mieux de repasser sur un overcommit par défaut à 0 finalement?
J'ai ceci:
vm.overcommit_memory = 2
vm.overcommit_ratio = 50
Je rajoute une info: j'ai fais un petit test: repasser à 8GB de shared, je plante dans les 30 secondes.
Donc augmenter le shared fait empirer les choses... Ca rejoint ce que disait Julien.
Je stoppe pgcluu au moment du plantage et j'ai ceci dans la vue memory:
15.34 GB Total memory
4.25 GB Free memory
113.46 MB Buffers
10.54 GB Cached
1.95 GB Total swap
1.95 GB Free swap
1.75 GB Shared memory
9.62 GB Commit limit
8.58 GB Committed
On a là 4.25GB libre et un cache à 10.54 donc on semble pas à la rue coté ram...
pgbadger me donne un pic de 17query/s (je trace uniquement les >20ms).
C'est postgres 9.3.6.
En fait ce n'est pas toujours la même requete, par contre du moment ou on en a une qui passe en out of memory, dans la foulée le fichier logs se rempli à vitesse grand V de nouvelles requetes différentes passant en out of memory et sur des clients distincts. (8000 out of memory sur 90 minutes !)
J'ai lancé un free -m quand se produisait le out of memory: pas de swap et pres de 10GB free.
à moins que ponctuellement sur quelques millisecondes toute la ram soit full puis libérée et que mon free -m passe donc à coté...
cependant je verrais du swap non?
C'est ça qui est étonnant, pas de swap et de la ram dispo alors que out of memory...
Je fournis quand même le explain de cette requete:
QUERY PLAN
Sort (cost=321.47..321.48 rows=3 width=186) (actual time=0.028..0.028 rows=0 loops=1)
Sort Key: a.nip, a.depart
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=2
-> Nested Loop Left Join (cost=19.75..321.45 rows=3 width=186) (actual time=0.019..0.019 rows=0 loops=1)
Buffers: shared hit=2
-> Nested Loop Left Join (cost=19.33..70.65 rows=3 width=168) (actual time=0.018..0.018 rows=0 loops=1)
Buffers: shared hit=2
-> Bitmap Heap Scan on dsi_planning_salle_attente_secteur a (cost=2.48..8.02 rows=3 width=152) (actual time=0.018..0.018 rows=0 loops=1)
Recheck Cond: ((idsecteur = 2) AND (depart <= 1435355999999::bigint))
Filter: ((fin > 1435269600000::bigint) OR (fin IS NULL))
Buffers: shared hit=2
-> Bitmap Index Scan on idx_planning_sa_secteur_id_dates (cost=0.00..2.48 rows=4 width=0) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: ((idsecteur = 2) AND (depart <= 1435355999999::bigint))
Buffers: shared hit=2
-> Index Scan using idx_agenda_planning_lit_id on dsi_agenda_planning_lit d (cost=16.85..20.87 rows=1 width=24) (never executed)
Index Cond: (id = (SubPlan 6))
Filter: (nip = a.nip)
SubPlan 6
-> Aggregate (cost=16.55..16.56 rows=1 width=4) (never executed)
-> Index Scan using index_dsi_agenda_planning_lit_nip on dsi_agenda_planning_lit f (cost=0.29..16.54 rows=1 width=4) (never executed)
Index Cond: (nip = a.nip)
Filter: ((depart < 1435355999999::bigint) AND ((depart > 1435269600000::bigint) OR (depart IS NULL)))
SubPlan 6
-> Aggregate (cost=16.55..16.56 rows=1 width=4) (never executed)
-> Index Scan using index_dsi_agenda_planning_lit_nip on dsi_agenda_planning_lit f (cost=0.29..16.54 rows=1 width=4) (never executed)
Index Cond: (nip = a.nip)
Filter: ((depart < 1435355999999::bigint) AND ((depart > 1435269600000::bigint) OR (depart IS NULL)))
-> Index Scan using agenda_agenda_pk on agenda_agenda e (cost=0.42..1.61 rows=1 width=18) (never executed)
Index Cond: (id = d.id)
SubPlan 1
-> Aggregate (cost=18.98..18.99 rows=1 width=248) (never executed)
-> Bitmap Heap Scan on dsi_planning_lit z (cost=4.97..18.98 rows=1 width=248) (never executed)
Recheck Cond: (((nip = a.nip) AND (depart >= a.fin)) OR ((nip = a.nip) AND (depart < a.fin) AND (fin > 0) AND (fin > a.fin)))
Filter: ((('1970-01-01 01:00:00+01'::timestamp with time zone + (((depart / 1000))::double precision * '00:00:01'::interval)))::date = (('1970-01-01 01:00:00+01'::timestamp with time zone + (((a.fin / 1000))::double precision * '00:00:01'::interval)))::date)
-> BitmapOr (cost=4.97..4.97 rows=7 width=0) (never executed)
-> Bitmap Index Scan on idx_planning_lit_4 (cost=0.00..2.47 rows=5 width=0) (never executed)
Index Cond: ((nip = a.nip) AND (depart >= a.fin))
-> Bitmap Index Scan on idx_planning_lit_4 (cost=0.00..2.50 rows=2 width=0) (never executed)
Index Cond: ((nip = a.nip) AND (depart < a.fin) AND (fin > 0) AND (fin > a.fin))
SubPlan 2
-> Aggregate (cost=12.06..12.07 rows=1 width=248) (never executed)
-> Index Scan using idx_planning_lit_4 on dsi_planning_lit z_1 (cost=0.42..12.05 rows=1 width=248) (never executed)
Index Cond: ((nip = a.nip) AND (depart < a.depart))
Filter: ((('1970-01-01 01:00:00+01'::timestamp with time zone + (((fin / 1000))::double precision * '00:00:01'::interval)))::date = (('1970-01-01 01:00:00+01'::timestamp with time zone + (((a.depart / 1000))::double precision * '00:00:01'::interval)))::date)
SubPlan 3
-> Aggregate (cost=21.69..21.70 rows=1 width=377) (never executed)
-> Nested Loop Left Join (cost=1.42..21.69 rows=1 width=377) (never executed)
-> Nested Loop (cost=1.28..21.52 rows=1 width=368) (never executed)
-> Nested Loop (cost=1.14..21.35 rows=1 width=358) (never executed)
Join Filter: ((a_1.dateko IS NULL) OR (a_1.dateko > CASE WHEN (c.datereelle IS NULL) THEN c.datetheo ELSE c.datereelle END))
-> Nested Loop (cost=0.71..15.62 rows=5 width=293) (never executed)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a_1 (cost=0.29..6.01 rows=2 width=273) (never executed)
Index Cond: (nip = a.nip)
Filter: (dateko IS NULL)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b (cost=0.42..4.78 rows=3 width=24) (never executed)
Index Cond: (idpres = a_1.id)
Filter: (etat = 2)
-> Index Scan using idx_premio_jour_5 on premio_presc_jour_produit c (cost=0.43..1.13 rows=1 width=73) (never executed)
Index Cond: (idcycle = b.id)
Filter: (CASE WHEN (datereelle IS NULL) THEN datetheo ELSE datereelle END = (('1970-01-01 01:00:00+01'::timestamp with time zone + (((a.depart / 1000))::double precision * '00:00:01'::interval)))::date)
-> Index Scan using pk_id_voieadm on dsi_med_code_voieadmin d_1 (cost=0.14..0.16 rows=1 width=18) (never executed)
Index Cond: (id = c.idvoieadm)
-> Index Scan using pk_id_voieabord on dsi_med_code_voieadmin_abord e_1 (cost=0.14..0.16 rows=1 width=17) (never executed)
Index Cond: (id = c.idvoieabord)
SubPlan 4
-> Aggregate (cost=7.47..7.48 rows=1 width=220) (never executed)
-> Bitmap Heap Scan on agenda_agenda z_2 (cost=5.45..7.46 rows=1 width=220) (never executed)
Recheck Cond: ((depart = d.date_rdz) AND (nip = a.nip))
Filter: (idress = d.id_ressource)
-> BitmapAnd (cost=5.45..5.45 rows=1 width=0) (never executed)
-> Bitmap Index Scan on agenda_idx_date (cost=0.00..2.49 rows=9 width=0) (never executed)
Index Cond: (depart = d.date_rdz)
-> Bitmap Index Scan on index_agenda_nip (cost=0.00..2.70 rows=37 width=0) (never executed)
Index Cond: (nip = a.nip)
SubPlan 5
-> Aggregate (cost=21.69..21.70 rows=1 width=377) (never executed)
-> Nested Loop Left Join (cost=1.42..21.69 rows=1 width=377) (never executed)
-> Nested Loop (cost=1.28..21.52 rows=1 width=368) (never executed)
-> Nested Loop (cost=1.14..21.35 rows=1 width=358) (never executed)
Join Filter: ((a_2.dateko IS NULL) OR (a_2.dateko > CASE WHEN (c_1.datereelle IS NULL) THEN c_1.datetheo ELSE c_1.datereelle END))
-> Nested Loop (cost=0.71..15.62 rows=5 width=293) (never executed)
-> Index Scan using idx_presc_premio_nip on premio_presc_v2 a_2 (cost=0.29..6.01 rows=2 width=273) (never executed)
Index Cond: (nip = a.nip)
Filter: (dateko IS NULL)
-> Index Scan using idx_dsi_cycle on dsi_presc_cycle b_1 (cost=0.42..4.78 rows=3 width=24) (never executed)
Index Cond: (idpres = a_2.id)
Filter: (etat = 2)
-> Index Scan using idx_premio_jour_5 on premio_presc_jour_produit c_1 (cost=0.43..1.13 rows=1 width=73) (never executed)
Index Cond: (idcycle = b_1.id)
Filter: (CASE WHEN (datereelle IS NULL) THEN datetheo ELSE datereelle END = (('1970-01-01 01:00:00+01'::timestamp with time zone + (((a.depart / 1000))::double precision * '00:00:01'::interval)))::date)
-> Index Scan using pk_id_voieadm on dsi_med_code_voieadmin d_2 (cost=0.14..0.16 rows=1 width=18) (never executed)
Index Cond: (id = c_1.idvoieadm)
-> Index Scan using pk_id_voieabord on dsi_med_code_voieadmin_abord e_2 (cost=0.14..0.16 rows=1 width=17) (never executed)
Index Cond: (id = c_1.idvoieabord)
Total runtime: 0.803 ms
Bonjour, je fais face régulièrement à des TopMemoryContext sur mon serveur postgres , obligé à chaque fois de faire un restart pour que tout rentre dans l'ordre.
J'ai beau chercher, je ne comprends pas le pourquoi du problème.
C'est aléatoire... par contre à ma grande surprise hier j'ai changé le shared_buffers à 7GB au lieu des 4GB habituels, et ce matin, 3 plantages similaires, cette fois-ci le restart ne corrigeait le problème que quelques minutes puis ça recommençait... jusqu’à ce que je repasse à 4GB, et là c'est revenu à la normale.
Pourtant free -m montrait aucun swap et plusieurs GB encore free.
Je précise que à 4GB de sharred j'ai environ un plantage par semaine de ce type.
Ma config:
Postgresql 9.3.6 64bits sur debian wheezy virtualisé sous vmware, dédié à postgres.
Ram : 16GB
Taille de la base: 35GB
config postgres:
shared_buffers = 4GB
work_mem=4MB
maintenance_WM=256MB
max_stack_depth=4MB
J'ai analysé les logs du jour du plantage: pas de pics de requêtes, ou de connexions au moment des plantages.
Que veut dire topmemorycontext? le passage à 7GB de shared_buffers peut-il réellement avoir une incidence négative??
Voici une des traces d'erreur:
Date: 2015-06-26 08:53:01
Detail: Failed on request of size 4240.
Statement: select a.log_user_cre, a.oid, a.provenance, a.type_entree_planification, a.type_prevision_sortie,a.nip,a.depart,a.fin,if('dsi_planning_salle_attente_secteur'='dsi_planning_salle_attente_secteur' and ((select count(z.*)>0 from dsi_planning_lit z where z.nip = a.nip and (z.depart >= a.fin or (z.depart<a.fin and z.fin>0 and z.fin >a.fin) ) and cast(gc2pg(z.depart) AS date) = cast(gc2pg(a.fin) as date))or (a.etat = 0 and (select count(z.*)>0 from dsi_planning_lit z where z.nip = a.nip and (z.depart < a.depart ) and cast(gc2pg(z.fin) AS date) = cast(gc2pg(a.depart) as date)))),3,a.etat) AS etat,a.commentaire,a.motif,a.demande,a.motif2,a.motif3, a.degre_autonomie, a.idsecteur, frenchtime(a.date_creation_planif) AS fdDateCreation, a.liste_permission, a.destination, a.chambre_particuliere ,d.id AS idOriginePlanning ,if((select count(z.*)=0 from vue_premio_presc_detail_toppe z where z.nip = a.nip and z.dateadm = cast(gc2pg(a.depart) as date) and z.dateko is null) and (cast(e.depart as date)!=cast(gc2pg(a.depart) as date) or (d.date_rdz is not null and e.id is null and (select count(z.*)=0 from agenda_agenda z where z.idress= d.id_ressource and z.nip = a.nip and z.depart = d.date_rdz))),-1,if((select count(z.*)=0 from vue_premio_presc_detail_toppe z where z.nip = a.nip and z.dateadm = cast(gc2pg(a.depart) as date) and z.dateko is null) ,null,e.etat)) AS etatRdz from dsi_planning_salle_attente_secteur a left join dsi_agenda_planning_lit d ON d.nip = a.nip and d.id=(select min(f.id) from dsi_agenda_planning_lit f where f.nip = a.nip and if(1435355999999 is null, true, f.depart< 1435355999999) and (f.depart > 1435269600000 or f.depart is null ) ) left join agenda_agenda e on e.id = d.id where if(1435355999999 is null, true, a.depart<= 1435355999999) and (a.fin > 1435269600000 or a.fin is null ) and a.idsecteur in (2) order by a.nip,a.depart
TopMemoryContext: 221952 total in 17 blocks; 18952 free (56 chunks); 203000 used
TopTransactionContext: 8192 total in 1 blocks; 7392 free (0 chunks); 800 used
Type information cache: 24240 total in 2 blocks; 3744 free (0 chunks); 20496 used
Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used
TableSpace cache: 8192 total in 1 blocks; 3216 free (0 chunks); 4976 used
MessageContext: 16544 total in 2 blocks; 2328 free (3 chunks); 14216 used
Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
smgr relation table: 24576 total in 2 blocks; 5696 free (4 chunks); 18880 used
TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used
Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
PortalMemory: 8192 total in 1 blocks; 7888 free (0 chunks); 304 used
PortalHeapMemory: 1024 total in 1 blocks; 848 free (0 chunks); 176 used
Relcache by OID: 24576 total in 2 blocks; 11792 free (3 chunks); 12784 used
CacheMemoryContext: 1342128 total in 21 blocks; 4256 free (3 chunks); 1337872 used
CachedPlanSource: 3072 total in 2 blocks; 352 free (0 chunks); 2720 used
unnamed prepared statement: 24576 total in 2 blocks; 15904 free (2 chunks); 8672 used
idx_planning_salleattente_1: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_dsi_planning_secteur_idsecteur_depart_fin: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
idx_planning_secteur_1: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
idx_planning_secteur_0: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_idx_planning_chambre_0_idchambre_deb_fin: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
index_dsi_planning_chambre_depart_fin: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
idx_planning_chambre_0: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_dsi_code_lit_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_dsi_code_chambre_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_dsi_code_secteur_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pk_bugzilla_utilisateur: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_adm_param_type: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_adm_param_param: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
EventTriggerCache: 8192 total in 1 blocks; 8160 free (2 chunks); 32 used
Event Trigger Cache: 8192 total in 1 blocks; 3744 free (0 chunks); 4448 used
dextr_date_extraction_pkey: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
idx_quicklinks: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
idx_util_work_mem: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
index_prog_connexion_logs_users_connexion: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
index_prog_connexion_pid: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
prog_connexion_pkey: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_prog_utilisateur_preference_cle_login: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
index_prog_group_utilisateur_utilisateur: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_prog_appli_group_groupe: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pk_prog_appli_group_groupe: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_toast_2619_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
index_prog_utilisateur_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
prog_utilisateur_password_index_for_ldap: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_prog_utilisateur_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
unik_prog_util_login: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
unik_prog_util_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pk_prog_utilisateur_initiales: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pk_pro_util_id: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
index_adm_code_entite_code: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pkeycode: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_index_indrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_attrdef_adrelid_adnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_db_role_setting_databaseid_rol_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_foreign_data_wrapper_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_enum_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_class_relname_nsp_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_foreign_server_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_statistic_relid_att_inh_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_cast_source_target_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_language_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_collation_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_amop_fam_strat_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_ts_template_tmplname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_ts_config_map_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
pg_opclass_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_foreign_data_wrapper_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_event_trigger_evtname_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_ts_dict_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_event_trigger_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_conversion_default_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_enum_typid_label_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_ts_config_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_user_mapping_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_opfamily_am_name_nsp_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
pg_foreign_table_relid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_type_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_aggregate_fnoid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_constraint_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_ts_parser_prsname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_ts_config_cfgname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_ts_parser_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_operator_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_namespace_nspname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_ts_template_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_amop_opr_fam_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_default_acl_role_nsp_obj_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
pg_collation_name_enc_nsp_index: 3072 total in 2 blocks; 1784 free (2 chunks); 1288 used
pg_range_rngtypid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_ts_dict_dictname_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_type_typname_nsp_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_opfamily_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_class_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_proc_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_language_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_namespace_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1736 free (2 chunks); 1336 used
pg_foreign_server_name_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_conversion_oid_index: 1024 total in 1 blocks; 200 free (0 chunks); 824 used
pg_user_mapping_user_server_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_conversion_name_nsp_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_authid_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_auth_members_member_role_index: 1024 total in 1 blocks; 16 free (0 chunks); 1008 used
pg_tablespace_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_database_datname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_auth_members_role_member_index: 1024 total in 1 blocks; 64 free (0 chunks); 960 used
pg_database_oid_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
pg_authid_rolname_index: 1024 total in 1 blocks; 152 free (0 chunks); 872 used
MdSmgr: 8192 total in 1 blocks; 6176 free (0 chunks); 2016 used
ident parser context: 0 total in 0 blocks; 0 free (0 chunks); 0 used
hba parser context: 15360 total in 4 blocks; 6544 free (2 chunks); 8816 used
LOCALLOCK hash: 24576 total in 2 blocks; 13920 free (4 chunks); 10656 used
Timezones: 83472 total in 2 blocks; 3744 free (0 chunks); 79728 used
ErrorContext: 8192 total in 1 blocks; 8160 free (0 chunks); 32 used
Database: infocentre User: amedic Remote:
J'étais à la journée workshop dalibo la semaine derniere, j'ai tenté d'analyser les logs avec pg_badger mais rien ne me choque... quand à pgcluu il n'était pas lancé à ce moment là.
Auriez-vous une idée?
Cordialement
Olivier Bouiron
Pages : 1