Vous n'êtes pas identifié(e).
Pages : 1
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
Hors ligne
Bonjour,
Il manque ici le vrai message d'erreur, qui devrait être "ERROR: out of memory". Le détail ("Detail: Failed on request of size 4240.") indique que la demande de 4240 octets de mémoire pour la connexion n'ont pu être alloués. Le reste du message (TopMemoryContext etc) donne l'état de tous les contextes mémoires de cette connexion. Tout simplement, votre requête à consommé la totalité de la mémoire vive restante. En général c'est du à un trop grand nombre de connexion avec trop de work_mem. Au vu du nom de votre base (infocentre), il est possible que vous tombiez sur le problème de "Hash Aggregate", qui peut utiliser plus que la quantité de work_mem définie en cas de statistiques non à jour ou erronnées. Quoi qu'il en soit, le fait d'augmenter le shared_buffers diminue la quantité de mémoire utilisable par les connexions, et donc augmente la probabilité d'erreurs de type "ouf of memory".
S'il s'agit toujours de cette requêtes qui finit en erreur, pourriez-vous fournir un EXPLAIN (idéalement EXPLAIN (ANALYZE, BUFFERS) ) de l'exécution de cette requête ? De plus, quelle est la version exacte de PostgreSQL que vous utilisez ?
Dans ce genre de cas, pgbadger pourra vous donner l'information de savoir s'il s'agit toujours de la même requête qui finit en erreur ou non, ce qui peut donner une indication sur un problème de work_mem mal dimensionné. pgCluu pourrait vous permettre de constater et surtout voir à quelle vitesse la consommation de la RAM est effectuée.
Julien.
https://rjuju.github.io/
Hors ligne
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
Dernière modification par olivier.bouiron (26/06/2015 14:21:02)
Hors ligne
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).
Hors ligne
Comme c'est une VM, qu'avez vous comme valeur pour vm.overcommit_memory & vm.overcommit_ratio ?
Hors ligne
J'ai ceci:
vm.overcommit_memory = 2
vm.overcommit_ratio = 50
Hors ligne
ça doit donner qque chose comme 8Go+swap utilisable par les applications dans la vm. Vous pouvez essayer de monter le ratio de 50 à 75.
Dernière modification par uruvela (29/06/2015 11:21:25)
Hors ligne
C'est utile du coups de le laisser à 2?
C'est pas mieux de repasser sur un overcommit par défaut à 0 finalement?
Hors ligne
Il est plus intéressant de positionner correctement l'overcommit, car il est préférable d'avoir un out of memory sur quelques requêtes plutôt qu'un OOM qui se déclenche. Le tout est donc de bien positionner l'overcommit, ainsi que les différentes paramètres sur postgresql pouvant consommer de la mémoire (work_mem, maintenance_work_mem ...).
Julien.
https://rjuju.github.io/
Hors ligne
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?
Hors ligne
Effectivement, la consommation mémoire est un peu compiquée à bien estimer.
Il peut y avoir ( autovacuum_max_worker * maintenance_work_mem ) utilisée par l'autovacuum, mais il faut aussi prendre en compte les potentielles commande de maintenance passée à la main. À vous de voir le nombre maximum qui peuvent être effectuées par des DBA et/ou des scripts de maintenance.
Pour le work_mem, il peut être utilisé plusieurs fois par requête. En général, on part d'une première estimation avec work_mem * max_connections, en supposant que des sessions l'utiliseront plusieurs fois mais que des sessions ne l'utiliseront pas. Si vous savez que la majorité de vos requêtes auront plusieurs nœuds qui potentiellement utiliseront plusieurs fois le work_mem, il vous faut adapter cette estimation.
Il n'est malheureusement pas possible de suivre l'utilisation du work_mem ou maintenance_work_mem, cet indicateur n'étant pas disponible dans postgres. On peut uniquement regarder l'évolution de la consommation de mémoire côté système.
Julien.
https://rjuju.github.io/
Hors ligne
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?
Hors ligne
Les conditions dans where ne prendront pas de work_mem, du moins pas ce genre de cas. Pour le reste, ça dépend des données, et donc du plan d'exécution choisi. Le order by utilisera du work_mem s'il n'y a pas d'index pour trier les données par exemple, ou les jointures n'utiliseront pas de work_mem si un nested loop est utilisé. De plus, sans utilisation de curseur, la totalité des lignes doit se trouver en mémoire avant d'être renvoyé au client, ce qui peut aussi consommer beaucoup de mémoire et n'est pas borné par le work_mem.
Julien.
https://rjuju.github.io/
Hors ligne
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 !
Hors ligne
Pages : 1
