mémoire & oom_killer

Le
Tanguy
Bonjour à tous,

Cette nuit un serveur de base de données (postgresql) ici a visiblement
interrompu son service

c'est un serveur redhat, 2Go de mémoire, noyau 2.6.9 (SMP x86_64)
J'ai configuré le swap sur une partition de 2 Go

Pour info le serveur tourne depuis plusieurs mois sans souci
particulier.

Actuellement en occupation mémoire j'ai ça:

$ free
total used free shared buffers cached
Mem: 2056372 1539680 516692 0 21944 1425496
-/+ buffers/cache: 92240 1964132
Swap: 2048248 11520 2036728



Avant le plantage j'avais plutôt 160ko de swap utilisés.

Apparemment c'est le noyau qui a tué le processus
postmaster, j'ai vu ça ce matin quand j'ai voulu voir
ce qui s'est passé:
(j'ai gardé ce qui me semblait pertinent)

<- extrait de la sortie de dmesg -

oom-killer: gfp_mask=0x1d2
Node 0 DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
cpu 2 hot: low 2, high 6, batch 1
cpu 2 cold: low 0, high 2, batch 1
cpu 3 hot: low 2, high 6, batch 1
cpu 3 cold: low 0, high 2, batch 1
cpu 4 hot: low 2, high 6, batch 1
cpu 4 cold: low 0, high 2, batch 1
cpu 5 hot: low 2, high 6, batch 1
cpu 5 cold: low 0, high 2, batch 1
cpu 6 hot: low 2, high 6, batch 1
cpu 6 cold: low 0, high 2, batch 1
cpu 7 hot: low 2, high 6, batch 1
cpu 7 cold: low 0, high 2, batch 1
Node 0 Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16
cpu 4 hot: low 32, high 96, batch 16
cpu 4 cold: low 0, high 32, batch 16
cpu 5 hot: low 32, high 96, batch 16
cpu 5 cold: low 0, high 32, batch 16
cpu 6 hot: low 32, high 96, batch 16
cpu 6 cold: low 0, high 32, batch 16
cpu 7 hot: low 32, high 96, batch 16
cpu 7 cold: low 0, high 32, batch 16
Node 0 HighMem per-cpu: empty

Free pages: 1488kB (0kB HighMem)
Active:130888 inactive:370295 dirty:0 writeback:0 unstable:0 free:372
slab:4600 mapped:493147 pagetables:3545
Node 0 DMA free:8kB min:8kB low:16kB high:24kB active:6208kB
inactive:5336kB present:16384kB
protections[]: 0 0 0
Node 0 Normal free:1480kB min:1436kB low:2872kB high:4308kB
active:517280kB inactive:1475844kB present:2080512kB
protections[]: 0 0 0
Node 0 HighMem free:0kB min:128kB low:256kB high:384kB active:0kB
inactive:0kB present:0kB
protections[]: 0 0 0
Node 0 DMA: 0*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 8kB
Node 0 Normal: 16*4kB 9*8kB 4*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB
1*1024kB 0*2048kB 0*4096kB = 1480kB
Node 0 HighMem: empty
Swap cache: add 542229, delete 542229, find 159166/162591, race 0+150
Out of Memory: Killed process 19759 (postmaster).
-->

J'ai regardé ce qu'était oom_killer, et je suis tombé là dessus:
http://linux-mm.org/OOM_Killer
on y dit:
«Any particular process leader may be immunized against the oom killer
if the value of it's /proc/<pid>/oomadj is set to the constant
OOM_DISABLE (currently defined as -17)»

Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)

Comment puis je m'assurer que ce comportement ne va pas se reproduire?
Vu que le problème semble venir d'un manque de mémoire, j'ai pensé
rajouter de l'espace de swap, mais comme le disque est occupé
je vais devoir rajouter du swap sous forme d'un fichier et pas
comme partition de swap est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?

Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)



ps: je *pense* avoir trouvé la source du problème
au niveau de la base de données, mais je voudrais bien
comprendre ces histoires de oom_killer ;)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #1903469
Tanguy wrote in message
Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)


Chez moi, c'est oom_adj.

est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?


Se dégradent... par rapport à quoi ? Toute la question est là. Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances
seront tout à fait identiques tant que le fichier n'est pas sollicité. Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement
pas.

Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)


Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la
mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce
processus de sévir, donc il se trouve un moment où le noyau n'a plus de
mémoire à attribuer : un programme voit une allocation échouer. S'il est
très bien écrit, il va essayer de recompacter ses structures de données ou
de libérer des caches, mais c'est rare. En pratique, il y a de bonnes
chances qu'il se termine sur « Out of memory, aborting. » ou sur une
segfault un peu plus loin parce qu'il n'a pas vérifié l'allocation.

De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la
mémoire que quand il est certain de pouvoir la fournir. Ça interdit un
certain nombre d'opérations tout à fait légitimes et sans risque, par
exemple un très gros processus qui forke pour exécuter une petite commande
shell.

Ce ne sont pas des questions faciles.

Tanguy
Le #1903468
Le 03/10/2007 12:08, Nicolas George ecrivait :
Tanguy wrote in message
Or le process postmaster est 9928 et je ne trouve pas de fichier
/proc/9928/oomadj
(où me goure-je?)


Chez moi, c'est oom_adj.


hmm... chez moi je n'ai rien du tout...
il y a une option à spécifier, peut être? (lors de la config du noyau,
ou ailleurs?)



est ce que je peux activer
un swap (partition)+un swap (fichier) sans que ça pose de problèmes
ou que les performances se dégradent?


Se dégradent... par rapport à quoi ? Toute la question est là.


par rapport à l'existant. C'est un serveur de base de données, il
est moyennement sollicité, mais c'est mieux s'il est réactif ;)
Il me semble bien que le swap sur un fichier est plus lent que
le swap sur partition. Ma question était plutôt dans le sens
«est ce que la différence est sensible?»

Si tu mets le
fichier avec une priorité inférieure à la partition, alors les performances
seront tout à fait identiques tant que le fichier n'est pas sollicité.


je ne savais pas qu'on pouvait spécifier des priorités. Je vais regarder
ça, ça répond en grande partie à ma question. (ça donnera une petite
rallonge pour le swap... j'ai peut être prévu un peu court avec
2Go de swap pour 2Go de RAM)

Et
dès qu'il commence à l'être... Eh bien avant il n'y en avait tout simplement
pas.

Est ce que je peux désactiver le oom_killer? (ou est ce
une très très mauvaise idée?)


Si l'OOM-killer s'est réveillé, c'est qu'un programme a bouffé toute la
mémoire. Si tu t'arranges pour désactiver l'OOM-killer, ça n'empêche pas ce
processus de sévir, donc il se trouve un moment où le noyau n'a plus de
mémoire à attribuer : un programme voit une allocation échouer.


oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.


De plus, désactiver l'OOM-killer, ça suppose que le noyau ne promette de la
mémoire que quand il est certain de pouvoir la fournir. Ça interdit un
certain nombre d'opérations tout à fait légitimes et sans risque, par
exemple un très gros processus qui forke pour exécuter une petite commande
shell.



ok. Mais pour le coup je voudrais bien “protéger” certains processus,
si c'est possible, pour m'assurer qu'ils ne soient pas tués
arbitrairement. Par exemple, sur ce cas il a visiblement tué une
connexion à un client qui ne s'arrête jamais, alors que le processus qui
à causé le souci, et que j'aurais préféré voir disparaitre, était le
compactage d'une base problématique (opération qui peut attendre
que je sois revenu au boulot )


Ce ne sont pas des questions faciles.


oui je pense bien ;)

Merci pour ta réponse.


Nicolas George
Le #1903467
Tanguy wrote in message
hmm... chez moi je n'ai rien du tout...
il y a une option à spécifier, peut être? (lors de la config du noyau,
ou ailleurs?)


Rien de particulier. Ton noyau est peut-être trop vieux.

Par exemple, sur ce cas il a visiblement tué une
connexion à un client qui ne s'arrête jamais, alors que le processus qui
à causé le souci, et que j'aurais préféré voir disparaitre, était le
compactage d'une base problématique (opération qui peut attendre
que je sois revenu au boulot )


Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de
choses. Les heuristiques du noyau essaient de trouver le processus
responsable, mais c'est une notion assez vague, et très difficile à évaluer.
Désactiver l'OOM-killer serait probablement pire. Utiliser les options de
priorité que tu as trouvées peut peut-être aider.

Tanguy
Le #1903465
Le 03/10/2007 13:57, Nicolas George ecrivait :

Je ne pense pas qu'il y ait réellement moyen de garantir ce genre de
choses. Les heuristiques du noyau essaient de trouver le processus
responsable, mais c'est une notion assez vague, et très difficile à évaluer.


en plus je ne pense pas maitriser suffisamment la gestion de la mémoire
sur linux pour me lancer là dedans. Statu quo, donc; j'ai rajouté
du swap en attendant.

Désactiver l'OOM-killer serait probablement pire. Utiliser les options de
priorité que tu as trouvées peut peut-être aider.


oui je viens de faire ça...
# swapon -s
Filename Type Size Used Priority
/dev/sda6 partition 2048248 11508 -1
/data/swapfile file 999992 0 -4

d'après ce que j'ai compris les zones de swap ajoutées prennent une
priorité inférieure. C'est ce que je veux.

Thierry B.
Le #1903461
--{ Tanguy a plopé ceci: }--


oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.

Attention, de mémoire, c'est peut-être approximatif... Lors du

traitement de certaines requètes contenant des ORDER BY, Psql
peut manger beaucoup de mémoire. Il est possible de lui demander
de travailler avec des fichiers intermédiaires sur disque. Bon,
d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc
sous la main, mais ça doit se trouver au chapitre "tuning"...

A regarder, peut-être une piste pour traiter un cas particulier.


--
Ya pas pire vieux con, qu'un vieux con qui s'y connais, car non
seulement il râle, mais en plus il a raison.
--{ LC (connaisseur) in f.m.b.l }--

Tanguy
Le #1903441
Le 03/10/2007 15:43, Thierry B. ecrivait :
--{ Tanguy a plopé ceci: }--

oui oui, mais ce qui m'ennuie dans l'histoire c'est qu'il a tué le
processus postmaster.

Attention, de mémoire, c'est peut-être approximatif... Lors du

traitement de certaines requètes contenant des ORDER BY, Psql
peut manger beaucoup de mémoire. Il est possible de lui demander
de travailler avec des fichiers intermédiaires sur disque. Bon,
d'accord, ça être bien plus lent, mais ça passe. J'ai pas la doc
sous la main, mais ça doit se trouver au chapitre "tuning"...

A regarder, peut-être une piste pour traiter un cas particulier.




En fait je ne pense pas qu'un tel traitement (requete couteuse) soit en
cause.
C'est arrivé la nuit, normalement il n'y a que très peu d'accès à ce
moment là. Je pense avoir trouvé ce qui n'allait pas, sans pouvoir en
être sûr malheureusement; je pense que le compactage que je fais toutes
les nuits a coincé à un moment donné (Le coupable était une base de test
que j'avais créée. C'est rentré dans l'ordre quand je l'ai supprimée.)

Ceci dit je garde ta remarque sous le coude, ça peut servir... ;)


Publicité
Poster une réponse
Anonyme