Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai eu un crash de la base de données la semaine dernière. Je l'ai relancé sans trop de problème.
Seulement aujourd'hui ça a recommencé
Dans le fichier de log j'ai :
Sep 30 10:57:08 bdserv postgres[21304]: [3-1] FATAL: the database system is in recovery mode
si je regarde la dernière erreur j'ai :
Sep 30 10:56:25 bdserv postgres[4008]: [1-1] LOG: server process (PID 20083) was terminated by signal 9
Sep 30 10:56:28 bdserv postgres[4008]: [2-1] LOG: terminating any other active server processes
Et si je remonte encore le fichier de log en recherchant le PID 20083 j'ai :
Sep 30 09:13:23 bdsrv postgres[20083]: [1-1] LOG: duration: 2.632 ms statement: SET DateStyle=ISO;SELECT oid, pg_encoding_to_char(encoding) AS encoding, datlastsysoid
Sep 30 09:13:23 bdsrv postgres[20083]: [1-2] FROM pg_database WHERE oid = 1280235
Sep 30 09:13:23 bdsrv postgres[20083]: [2-1] LOG: duration: 0.527 ms statement: set client_encoding to 'UNICODE'
Sep 30 09:13:23 bdsrv postgres[20083]: [3-1] LOG: duration: 0.167 ms statement: SELECT version();
Sep 30 09:13:23 bdsrv postgres[20083]: [4-1] LOG: duration: 0.680 ms statement: SELECT description FROM pg_description WHERE objoid=1280235::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [5-1] LOG: duration: 0.487 ms statement: SELECT proname FROM pg_proc WHERE proname='pg_get_viewdef' AND proargtypes[1]=16
Sep 30 09:13:23 bdsrv postgres[20083]: [6-1] LOG: duration: 0.074 ms statement: SHOW search_path
Sep 30 09:13:23 bdsrv postgres[20083]: [7-1] LOG: duration: 0.597 ms statement: SELECT nspname, session_user=nspname AS isuser FROM pg_namespace
Sep 30 09:13:23 bdsrv postgres[20083]: [8-1] LOG: duration: 3.569 ms statement: SELECT 2 AS nsptyp,
Sep 30 09:13:23 bdsrv postgres[20083]: [8-2] nsp.nspname, nsp.oid, pg_get_userbyid(nspowner) AS namespaceowner, nspacl, description, FALSE as cancreate
Sep 30 09:13:23 bdsrv postgres[20083]: [8-3] FROM pg_namespace nsp
Sep 30 09:13:23 bdsrv postgres[20083]: [8-4] LEFT OUTER JOIN pg_description des ON des.objoid=nsp.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [8-5] WHERE ((nspname = 'pg_catalog' and (SELECT count(*) FROM pg_class WHERE relname = 'pg_class' AND relnamespace = nsp.oid) > 0)
Sep 30 09:13:23 bdsrv postgres[20083]: [8-6] OR
Sep 30 09:13:23 bdsrv postgres[20083]: [8-7] (nspname = 'pgagent' and (SELECT count(*) FROM pg_class WHERE relname = 'pga_job' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [8-8] (nspname = 'information_schema' and (SELECT count(*) FROM pg_class WHERE relname = 'tables' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [8-9] (nspname = 'dbo' and (SELECT count(*) FROM pg_class WHERE relname = 'systables' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [8-10] (nspname = 'sys' and (SELECT count(*) FROM pg_class WHERE relname = 'all_tables' AND relnamespace = nsp.oid) > 0))
Sep 30 09:13:23 bdsrv postgres[20083]: [8-11] ORDER BY 1, nspname
Sep 30 09:13:23 bdsrv postgres[20083]: [9-1] LOG: duration: 4.814 ms statement: SELECT CASE WHEN nspname LIKE E'pg\\_temp\\_%' THEN 1
Sep 30 09:13:23 bdsrv postgres[20083]: [9-2] WHEN (nspname LIKE E'pg\\_%') THEN 0
Sep 30 09:13:23 bdsrv postgres[20083]: [9-3] ELSE 3 END AS nsptyp,
Sep 30 09:13:23 bdsrv postgres[20083]: [9-4] nsp.nspname, nsp.oid, pg_get_userbyid(nspowner) AS namespaceowner, nspacl, description,
Sep 30 09:13:23 bdsrv postgres[20083]: [9-5] has_schema_privilege(nsp.oid, 'CREATE') as cancreate
Sep 30 09:13:23 bdsrv postgres[20083]: [9-6] FROM pg_namespace nsp
Sep 30 09:13:23 bdsrv postgres[20083]: [9-7] LEFT OUTER JOIN pg_description des ON des.objoid=nsp.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [9-8] WHERE NOT ((nspname = 'pg_catalog' and (SELECT count(*) FROM pg_class WHERE relname = 'pg_class' AND relnamespace = nsp.oid) >
Sep 30 09:13:23 bdsrv postgres[20083]: [9-9] 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [9-10] (nspname = 'pgagent' and (SELECT count(*) FROM pg_class WHERE relname = 'pga_job' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [9-11] (nspname = 'information_schema' and (SELECT count(*) FROM pg_class WHERE relname = 'tables' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [9-12] (nspname = 'dbo' and (SELECT count(*) FROM pg_class WHERE relname = 'systables' AND relnamespace = nsp.oid) > 0) OR
Sep 30 09:13:23 bdsrv postgres[20083]: [9-13] (nspname = 'sys' and (SELECT count(*) FROM pg_class WHERE relname = 'all_tables' AND relnamespace = nsp.oid) > 0))
Sep 30 09:13:23 bdsrv postgres[20083]: [9-14] ORDER BY 1, nspname
Sep 30 09:13:23 bdsrv postgres[20083]: [10-1] LOG: duration: 0.765 ms statement: SELECT nsp.oid, substr(nspname, 2) as clustername, nspname, pg_get_userbyid(nspowner) AS
Sep 30 09:13:23 bdsrv postgres[20083]: [10-2] namespaceowner, description
Sep 30 09:13:23 bdsrv postgres[20083]: [10-3] FROM pg_namespace nsp
Sep 30 09:13:23 bdsrv postgres[20083]: [10-4] LEFT OUTER JOIN pg_description des ON des.objoid=nsp.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [10-5] JOIN pg_proc pro ON pronamespace=nsp.oid AND proname = 'slonyversion'
Sep 30 09:13:23 bdsrv postgres[20083]: [10-6] ORDER BY nspname
Sep 30 09:13:23 bdsrv postgres[20083]: [11-1] LOG: duration: 38.737 ms statement: SELECT COUNT(*) FROM
Sep 30 09:13:23 bdsrv postgres[20083]: [11-2] (SELECT tgargs from pg_trigger tr
Sep 30 09:13:23 bdsrv postgres[20083]: [11-3] LEFT JOIN pg_depend dep ON dep.objid=tr.oid AND deptype = 'i'
Sep 30 09:13:23 bdsrv postgres[20083]: [11-4] LEFT JOIN pg_constraint co ON refobjid = co.oid AND contype = 'f'
Sep 30 09:13:23 bdsrv postgres[20083]: [11-5] WHERE tgisconstraint AND co.oid IS NULL
Sep 30 09:13:23 bdsrv postgres[20083]: [11-6] GROUP BY tgargs
Sep 30 09:13:23 bdsrv postgres[20083]: [11-7] HAVING count(1) = 3) AS foo
Sep 30 09:13:23 bdsrv postgres[20083]: [12-1] LOG: duration: 7.346 ms statement: SELECT d.oid, d.typname as domname, d.typbasetype, format_type(b.oid,NULL) as basetype,
Sep 30 09:13:23 bdsrv postgres[20083]: [12-2] pg_get_userbyid(d.typowner) as domainowner,
Sep 30 09:13:23 bdsrv postgres[20083]: [12-3] d.typlen, d.typtypmod, d.typnotnull, d.typdefault, d.typndims, d.typdelim, bn.nspname as basensp,
Sep 30 09:13:23 bdsrv postgres[20083]: [12-4] description, (SELECT COUNT(1) FROM pg_type t2 WHERE t2.typname=d.typname) > 1 AS domisdup,
Sep 30 09:13:23 bdsrv postgres[20083]: [12-5] (SELECT COUNT(1) FROM pg_type t3 WHERE t3.typname=b.typname) > 1 AS baseisdup
Sep 30 09:13:23 bdsrv postgres[20083]: [12-6] FROM pg_type d
Sep 30 09:13:23 bdsrv postgres[20083]: [12-7] JOIN pg_type b ON b.oid = CASE WHEN d.typndims>0 then d.typelem ELSE d.typbasetype END
Sep 30 09:13:23 bdsrv postgres[20083]: [12-8] JOIN pg_namespace bn ON bn.oid=b.typnamespace
Sep 30 09:13:23 bdsrv postgres[20083]: [12-9] LEFT OUTER JOIN pg_description des ON des.objoid=d.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [12-10] WHERE d.typtype = 'd' AND d.typnamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [12-11] ORDER BY d.typname
Sep 30 09:13:23 bdsrv postgres[20083]: [13-1] LOG: duration: 3.741 ms statement: SELECT pr.oid, pr.xmin, pr.*, format_type(TYP.oid, NULL) AS typname, typns.nspname AS
Sep 30 09:13:23 bdsrv postgres[20083]: [13-2] typnsp, lanname, proargnames, pg_get_userbyid(proowner) as funcowner, description
Sep 30 09:13:23 bdsrv postgres[20083]: [13-3] FROM pg_proc pr
Sep 30 09:13:23 bdsrv postgres[20083]: [13-4] JOIN pg_type typ ON typ.oid=prorettype
Sep 30 09:13:23 bdsrv postgres[20083]: [13-5] JOIN pg_namespace typns ON typns.oid=typ.typnamespace
Sep 30 09:13:23 bdsrv postgres[20083]: [13-6] JOIN pg_language lng ON lng.oid=prolang
Sep 30 09:13:23 bdsrv postgres[20083]: [13-7] LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [13-8] WHERE proisagg = FALSE AND pronamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [13-9] AND typname <> 'trigger'
Sep 30 09:13:23 bdsrv postgres[20083]: [13-10] ORDER BY proname
Sep 30 09:13:23 bdsrv postgres[20083]: [14-1] LOG: duration: 83.379 ms statement: SELECT oid, format_type(oid, NULL) AS typname FROM pg_type
Sep 30 09:13:23 bdsrv postgres[20083]: [15-1] LOG: duration: 3.796 ms statement: SELECT cl.oid, relname, pg_get_userbyid(relowner) AS seqowner, relacl, description
Sep 30 09:13:23 bdsrv postgres[20083]: [15-2] FROM pg_class cl
Sep 30 09:13:23 bdsrv postgres[20083]: [15-3] LEFT OUTER JOIN pg_description des ON des.objoid=cl.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [15-4] WHERE relkind = 'S' AND relnamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [15-5] ORDER BY relname
Sep 30 09:13:23 bdsrv postgres[20083]: [16-1] LOG: duration: 3.620 ms statement: SELECT rel.oid, relname, rel.reltablespace AS spcoid, spcname, pg_get_userbyid(relowner) AS
Sep 30 09:13:23 bdsrv postgres[20083]: [16-2] relowner, relacl, relhasoids, relhassubclass, reltuples, description, conname, conkey,
Sep 30 09:13:23 bdsrv postgres[20083]: [16-3] EXISTS(select 1 FROM pg_trigger
Sep 30 09:13:23 bdsrv postgres[20083]: [16-4] JOIN pg_proc pt ON pt.oid=tgfoid AND pt.proname='logtrigger'
Sep 30 09:13:23 bdsrv postgres[20083]: [16-5] JOIN pg_proc pc ON pc.pronamespace=pt.pronamespace AND pc.proname='slonyversion'
Sep 30 09:13:23 bdsrv postgres[20083]: [16-6] WHERE tgrelid=rel.oid) AS isrepl
Sep 30 09:13:23 bdsrv postgres[20083]: [16-7] FROM pg_class rel
Sep 30 09:13:23 bdsrv postgres[20083]: [16-8] LEFT OUTER JOIN pg_tablespace ta on ta.oid=rel.reltablespace
Sep 30 09:13:23 bdsrv postgres[20083]: [16-9] LEFT OUTER JOIN pg_description des ON (des.objoid=rel.oid AND des.objsubid=0)
Sep 30 09:13:23 bdsrv postgres[20083]: [16-10] LEFT OUTER JOIN pg_constraint c ON c.conrelid=rel.oid AND c.contype='p'
Sep 30 09:13:23 bdsrv postgres[20083]: [16-11] WHERE relkind IN ('r','s','t') AND relnamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [16-12] ORDER BY relname
Sep 30 09:13:23 bdsrv postgres[20083]: [17-1] LOG: duration: 2.340 ms statement: SELECT pr.oid, pr.xmin, pr.*, format_type(TYP.oid, NULL) AS typname, typns.nspname AS
Sep 30 09:13:23 bdsrv postgres[20083]: [17-2] typnsp, lanname, proargnames, pg_get_userbyid(proowner) as funcowner, description
Sep 30 09:13:23 bdsrv postgres[20083]: [17-3] FROM pg_proc pr
Sep 30 09:13:23 bdsrv postgres[20083]: [17-4] JOIN pg_type typ ON typ.oid=prorettype
Sep 30 09:13:23 bdsrv postgres[20083]: [17-5] JOIN pg_namespace typns ON typns.oid=typ.typnamespace
Sep 30 09:13:23 bdsrv postgres[20083]: [17-6] JOIN pg_language lng ON lng.oid=prolang
Sep 30 09:13:23 bdsrv postgres[20083]: [17-7] LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
Sep 30 09:13:23 bdsrv postgres[20083]: [17-8] WHERE proisagg = FALSE AND pronamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [17-9] AND typname = 'trigger'
Sep 30 09:13:23 bdsrv postgres[20083]: [17-10] AND lanname != 'edbspl'
Sep 30 09:13:23 bdsrv postgres[20083]: [17-11] ORDER BY proname
Sep 30 09:13:23 bdsrv postgres[20083]: [18-1] LOG: duration: 32.731 ms statement: SELECT oid, format_type(oid, NULL) AS typname FROM pg_type
Sep 30 09:13:23 bdsrv postgres[20083]: [19-1] LOG: duration: 61.151 ms statement: SELECT c.oid, c.xmin, c.relname, pg_get_userbyid(c.relowner) AS viewowner, c.relacl,
Sep 30 09:13:23 bdsrv postgres[20083]: [19-2] description, pg_get_viewdef(c.oid, true) AS definition
Sep 30 09:13:23 bdsrv postgres[20083]: [19-3] FROM pg_class c
Sep 30 09:13:23 bdsrv postgres[20083]: [19-4] LEFT OUTER JOIN pg_description des ON (des.objoid=c.oid and des.objsubid=0)
Sep 30 09:13:23 bdsrv postgres[20083]: [19-5] WHERE ((c.relhasrules AND (EXISTS (
Sep 30 09:13:23 bdsrv postgres[20083]: [19-6] SELECT r.rulename FROM pg_rewrite r
Sep 30 09:13:23 bdsrv postgres[20083]: [19-7] WHERE ((r.ev_class = c.oid)
Sep 30 09:13:23 bdsrv postgres[20083]: [19-8] AND (bpchar(r.ev_type) = '1'::bpchar)) ))) OR (c.relkind = 'v'::char))
Sep 30 09:13:23 bdsrv postgres[20083]: [19-9] AND relnamespace = 72454238::oid
Sep 30 09:13:23 bdsrv postgres[20083]: [19-10] ORDER BY relname
J'ai peur de ne pas comprendre ce qu'il se passe ^^"
Si vous avez une idée je suis preneur...
En vous remerciant par avance.
Hors ligne
Le processus a été tué par un kill -9. Donc soit un administrateur, soit un outil. Le noyau Linux pourrait avoir fait ça (si vous êtes sous Linux) à cause d'une méthode appelé oom killer. Il serait bon de vérifier dans syslog si ce n'est pas lui qui a dégagé un processus postgres.
Quant au log que vous fournissez, il ne nous renseigne pas tellement. Des requêtes SQL sont exécutées, rien de bien méchant.
Quelle version de PostgreSQL au fait ?
Guillaume.
Hors ligne
Quant au log que vous fournissez, il ne nous renseigne pas tellement. Des requêtes SQL sont exécutées, rien de bien méchant.
Oui je me doute, mais je pensais que c'était lié.
Quelle version de PostgreSQL au fait ?
Version 8.1
Le processus a été tué par un kill -9. Donc soit un administrateur, soit un outil. Le noyau Linux pourrait avoir fait ça (si vous êtes sous Linux) à cause d'une méthode appelé oom killer. Il serait bon de vérifier dans syslog si ce n'est pas lui qui a dégagé un processus postgres.
Ça ne peut pas être l'admin 
.
Je viens de vérifier dans syslog et en effet j'ai :
Sep 30 10:56:27 bdserv kernel: oom-killer: gfp_mask=0xd0
Sep 30 10:56:27 bdserv kernel: DMA per-cpu:
Sep 30 10:56:27 bdserv kernel: cpu 0 hot: low 2, high 6, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 0 cold: low 0, high 2, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 1 hot: low 2, high 6, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 1 cold: low 0, high 2, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 2 hot: low 2, high 6, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 2 cold: low 0, high 2, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 3 hot: low 2, high 6, batch 1
Sep 30 10:56:27 bdserv kernel: cpu 3 cold: low 0, high 2, batch 1
Sep 30 10:56:27 bdserv kernel: Normal per-cpu:
Sep 30 10:56:27 bdserv kernel: cpu 0 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 0 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 1 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 1 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 2 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 2 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 3 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 3 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: HighMem per-cpu:
Sep 30 10:56:28 bdserv kernel: cpu 0 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 0 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 1 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 1 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 2 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 2 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 3 hot: low 32, high 96, batch 16
Sep 30 10:56:28 bdserv kernel: cpu 3 cold: low 0, high 32, batch 16
Sep 30 10:56:28 bdserv kernel:
Sep 30 10:56:28 bdserv kernel: Free pages: 2008kB (1088kB HighMem)
Sep 30 10:56:28 bdserv kernel: Active:746072 inactive:272597 dirty:0 writeback:0 unstable:0 free:502 slab:6031 mapped:892074 pagetables:8656
Sep 30 10:56:28 bdserv kernel: DMA free:16kB min:16kB low:32kB high:48kB active:7096kB inactive:4956kB present:16384kB
Sep 30 10:56:28 bdserv kernel: protections[]: 0 0 0
Sep 30 10:56:28 bdserv kernel: Normal free:904kB min:936kB low:1872kB high:2808kB active:517664kB inactive:300944kB present:901120kB
Sep 30 10:56:28 bdserv kernel: protections[]: 0 0 0
Sep 30 10:56:28 bdserv kernel: HighMem free:1088kB min:512kB low:1024kB high:1536kB active:2459584kB inactive:784488kB present:3801088kB
Sep 30 10:56:28 bdserv kernel: protections[]: 0 0 0
Sep 30 10:56:28 bdserv kernel: DMA: 0*4kB 2*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 16kB
Sep 30 10:56:28 bdserv kernel: Normal: 0*4kB 1*8kB 0*16kB 0*32kB 8*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 904kB
Sep 30 10:56:28 bdserv kernel: HighMem: 134*4kB 5*8kB 0*16kB 0*32kB 0*64kB 0*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1088kB
Sep 30 10:56:28 bdserv kernel: Swap cache: add 2215664, delete 2215191, find 350742/524077, race 0+0
Sep 30 10:56:28 bdserv kernel: Out of Memory: Killed process 20741 (postmaster).
Donc si je comprends bien, j'ai un problème de mémoire. Mais est ce postgres qui prend de trop ?
J'ai modifié les paramètres de postgres au mois de juin pour optimiser les performances. Le problème peut-il venir de ces réglages?
Hors ligne
Le noyau Linux dispose d'un mécanisme qui fait que, s'il estime qu'un processus prend « trop » de mémoire, il peut le tuer (ou un tuer un autre). Tout ça pour récupérer de la mémoire.
Aucune idée si c'est dû à une mauvaise configuration de votre serveur PostgreSQL. Pour le dire, il faudrait avoir accès à ladite configuration ainsi qu'au profil matériel du serveur.
Par contre, ce que vous pouvez faire dès maintenant, c'est désactiver le oom killer. Pour cela, le mieux est de lire le chapitre « 17.4.3. Linux memory overcommit » dans http://docs.postgresql.fr/8.4/kernel-resources.html.
Guillaume.
Hors ligne
Merci pour toutes ces explications
J'ai décidé de modifier ma config de postgresql.
Je vous remercie encore de votre aide.
Hors ligne
Ton lien n'a pas l'air de marcher gleu : http://docs.postgresql.fr/8.4/kernel-resources.html (y a un point de trop au tien 
)
L'overcommit permet pour beaucoup de programmes, les jvm par exemple, de ne pas allouer réellement la mémoire qu'ils demandent (java a la facheuse tendance de faire un malloc géant au démarrage, même s'il n'utilise pas toute la mémoire qu'il a demandé).
Le problème, c'est quand un programme veut réellement utiliser de la mémoire qu'il a obtenu par malloc, que le noyau lui a assigné en overcommit (pas une vraie allocation, juste une pré-réservation), et qu'il n'y a plus de mémoire disponible à ce moment là. Le système est obligé de choisir un programme à supprimer, et c'est le plus souvent celui qui vient d'essayer d'accéder à une page mémoire pas vraiment allouée. C'est là que se déclenche l'OOM killer.
La solution est effectivement d'interdire l'overcommit (contrôler la mémoire allouée et vérifier que le système ne promet pas plus que ce qu'il a), mais on se retrouve avec un système qui tient moins la charge puisqu'il gaspille potentiellement de la mémoire (overcommit_memory=2). On peut ensuite régler soit même la limite de mémoire à allouer avec overcommit_ratio, suivant la formule : mémoire allouable = swap + ram * overcommit_ratio/100.
La valeur par défaut du ratio est 50, ce qui fait qu'on reste loin d'overcommiter et qu'on garde de la mémoire dispo pour éviter que le système ne s'effondre. Le reste n'est qu'une question de stratégie
Marc.
Hors ligne
merci pour ces précisions.
Hors ligne
Bonjour,
je fais référence à un autre moteur SGDB,
serait-il possible de connaitre 2 valeurs:
shmmax
taille du file system swap
une aide man sysctl
puis sysctl -a|grep shm
à une certaine époque (retraite), le calcul de la taille du swap était en rapport avec le nombre d'utilisateurs connectés et parfois restant connectés sans activité
le shmmax pouvait atteindre la taille maxi de la RAM toujours avec le swap en conséquense sur une machine dédiée SGBD
A+
JB
Hors ligne
Alors
la swap = 2Go
shmmax = 512 Mo
shmmax est une des valeurs que j'avais modifié pour optimiser le fonctionnement de postgres.
Dernière modification par j-pere (05/10/2009 10:54:35)
Hors ligne
Les valeurs par défaut contenues dans le fichier postgresql.conf ont étè altérées?
les valeurs pour les différents debug sont à ?
la dernière valeur un peu dure à avaler le panic!
dans le désordre, l'OS ?
la machine ne sert que pour le SGBD?
la taille mémoire?
un job accounting est en service?
A+
JB
Hors ligne
Les valeurs dans postgresql.conf ont bien été modifié.
OS : Red Hat
Non il n'y a pas que le SGBD
4 Go de RAM
Hors ligne
4GB de RAM, je pense que l'administrateur système pourrait en préter beaucoup plus!
vous serait-il possible d'observer l'occupation mémoire par:
man vmstat
vmstat 5
ainsi que la variation du swap
référence:
Sep 30 10:56:28 bdserv kernel: Swap cache: add 2215664, delete 2215191, find 350742/524077, race 0+0
Sep 30 10:56:28 bdserv kernel: Out of Memory: Killed process 20741 (postmaster).
une paranthèse, le fichier /var/log/messages fait référence au kill -9
comme c'est une version REDHAT le noyau est bien en 2.6.2x
je ne maitrise pas postgresql mais j'espère que celui-ci gére correctement les derniers blocs mémoire disponible,
je trouve qu'il ne devrait pas se saborder mais tuer le process trés gourmant
A+
JB
Hors ligne
Pas sûr de bien comprendre ce que vous dites. PostgreSQL ne se saborde pas, c'est le noyau Linux qui le dégage.
Guillaume.
Hors ligne
Par contre, il serait intéressant de savoir qui est le méchant qui a pris toute la RAM. Ça peut être postgres à cause de work_mem couplé à beaucoup de sessions, ou un programme autre sur la machine.
Pour se prémunir de ça, on peut mettre des ulimit (sauf pour les processus de root, c'est d'ailleurs une des 50 bonnes raisons pour n'avoir que le strict minimum s'exécutant en tant que root, hormis les contraintes de sécurité). L'OOM ne se déclenche pas pour rien, il a fallu que la machine soit complètement à court de RAM et de swap pour en arriver là.
Quelle valeur pour work_mem au fait ? (histoire de vraiment mettre postgres hors de cause).
Marc.
Hors ligne
Bonsoir,
-le noyau Linux ne se saborde pas, tout à fait d'accord car on a obligatoirement un panic system
-je voudrais savoir si aprés le kill -9 postgresql fonctionne encore,
c'est à dire que le process en cause du kill n'arrète pas le SGBD
-avez-vous évalué la taille mémoire nécessaire pour tous les process du SGBD,
-avez-vous hypotéqué une valeur de shmmax plus grande
les valeurs suivantes dans le noyau Redhat sont-elles changées:
shmmax, shmmin, shmmni, shmseg, semmni, semmsl, semmns, semopm, semvmx,
oui pour shmmax,
A+
JB
Hors ligne
Tout backend postgresql éteint salement (kill -9) entraîne l'arrêt d'urgence et le redémarrage automatique du cluster postgresql (donc extinction de tous les autres backends): après un arrêt brutal de backend, on ne peut plus garantir la cohérence des données en mémoire partagée.
C'est d'ailleurs bien ce qui se passe :
Sep 30 10:56:25 bdserv postgres[4008]: [1-1] LOG: server process (PID 20083) was terminated by signal 9
Sep 30 10:56:28 bdserv postgres[4008]: [2-1] LOG: terminating any other active server processes
puis la base part en recovery…
Marc.
Hors ligne
Bonjour,
Marc merci pour l'information ci-dessus,
la surveillance de la mémoire occupée donne-t-elle des résultats?
un espace swap a-t-il étè rajouté?
avec cette surveillance, serait-il possible de connaitre le nombre de requétes en cours?
un utilisateur du SGBD a-t-il des privilèges systèmes élevés? exemple sur un autre moteur SGBDR, il était possible de faire :! une commande unix
A+
JB
Hors ligne
Pages : 1
