[linux] out of memory avec +sieurs valgrind en parallèle, mais plein de mémoire libre..

Le
Gugus
Bonjour à tous,

sur un système Linux Server RHEL6 (déjà, ça commence bien :D) 24 coeurs
avec 12Go de RAM, lorsque je lance une dizaine de process, gourmands en
mémoire, avec valgrind, je me ramasse une quantité incroyable de OOM
alors que la RAM n’est pas complètement remplie, et la swap n’est même
pas touchée

Auriez-vous des pistes pour m’aider à comprendre d’où vient le souci ?

Les process sont lancés en tant que root.
J’ai ceci :
[root@intel-rd ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 94636
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited



En particulier, virtual memory est à unlimited.

J’ai également SELinux, mais qu’il soit activé ou non (setenforce 0/1),
ça ne change rien.


Ce qui m’étonne, ce sont les OOM alors que je ne lance que 10 processes
en parallèle (shellscriptés.. c’est une horreur, mais je fais avec pour
l’instant), alors que je dispose de 24 coeurs.
D’ailleurs la charge CPU ne dépasse pas le 50%.
De plus, l’occupation mémoire (vérifiée avec 'free' et via munin)
n’atteint même pas les 100% Mais je suis quand même bloqué !?

Pour info, la ligne de commande exacte est du style :
bash > timeout > valgrind > [process à la con, travaillant sur des gros
fichiers situés sur un partage NFS]

J’ai testé en lançant une dizaine de process sur un même fichier, de
taille « raisonnable » (~100Mo en moyenne), j’ai le même problème



Où devrais-je chercher ?



N’hésitez pas à me demander plus d’infos si elles peuvent aider


--
Gugus [http://what.dafuq.it/]
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
Gugus
Le #25047372
Ce cher Gugus
Bonjour à tous,

sur un système Linux Server RHEL6 (déjà, ça commence bien :D) 24 coeurs
avec 12Go de RAM, lorsque je lance une dizaine de process, gourmands en
mémoire, avec valgrind, je me ramasse une quantité incroyable de OOM
alors que la RAM n’est pas complètement remplie, et la swap n’est même
pas touchée ...



Plus exactement, le problème d’OOM vient bien de valgrind lui-même, et
non du process lancé :

F3== Valgrind's memory management: out of memory:
F3== memcheck:allocate new SecMap's request for 16384 bytes failed.
F3== 710709248 bytes have already been allocated.
F3== Valgrind cannot continue. Sorry.
F3= F3== There are several possible reasons for this.
F3== - You have some kind of memory limit in place. Look at the
F3== output of 'ulimit -a'. Is there a limit on the size of
F3== virtual memory or address space?
F3== - You have run out of swap space.
F3== - Valgrind has a bug. If you think this is the case or you are
F3== not sure, please let us know and we'll try to fix it.
F3== Please note that programs can take substantially more memory
than
F3== normal when running under Valgrind tools, eg. up to twice or
F3== more, depending on the tool. On a 64-bit machine, Valgrind
F3== should be able to make use of up 32GB memory. On a 32-bit
F3== machine, Valgrind should be able to use all the memory
available
F3== to a single process, up to 4GB if that's how you have your
F3== kernel configured. Most 32-bit Linux setups allow a maximum of
F3== 3GB per process.
F3= F3== Whatever the reason, Valgrind cannot continue. Sorry.



--
Gugus [http://what.dafuq.it/]
JKB
Le #25047622
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus

Ce cher Gugus


Bonsoir,

Bonjour à tous,

sur un système Linux Server RHEL6 (déjà, ça commence bien :D) 24 coeurs
avec 12Go de RAM, lorsque je lance une dizaine de process, gourmands en
mémoire, avec valgrind, je me ramasse une quantité incroyable de OOM
alors que la RAM n’est pas complètement remplie, et la swap n’est même
pas touchée ...



Plus exactement, le problème d’OOM vient bien de valgrind lui-même, et
non du process lancé :

F3== Valgrind's memory management: out of memory:
F3== memcheck:allocate new SecMap's request for 16384 bytes failed.
F3== 710709248 bytes have already been allocated.
F3== Valgrind cannot continue. Sorry.
F3= >F3== There are several possible reasons for this.
F3== - You have some kind of memory limit in place. Look at the
F3== output of 'ulimit -a'. Is there a limit on the size of
F3== virtual memory or address space?
F3== - You have run out of swap space.
F3== - Valgrind has a bug. If you think this is the case or you are
F3== not sure, please let us know and we'll try to fix it.
F3== Please note that programs can take substantially more memory
than
F3== normal when running under Valgrind tools, eg. up to twice or
F3== more, depending on the tool. On a 64-bit machine, Valgrind
F3== should be able to make use of up 32GB memory. On a 32-bit
F3== machine, Valgrind should be able to use all the memory
available
F3== to a single process, up to 4GB if that's how you have your
F3== kernel configured. Most 32-bit Linux setups allow a maximum of
F3== 3GB per process.
F3= >F3== Whatever the reason, Valgrind cannot continue. Sorry.



Que donne uname -a ? Et file $(which valgrind) ? Ne serait-ce pas par
le plus grand des hasards une machine avec un userland 32 bits ? Ce
qui fait que valgrind se prend un coup de pied aux fesses dès qu'il
consomme un peu plus de 3 Go (le noyau est quelque part entre 3Go et
4Go en adressage virtuel).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Gugus
Le #25049572
Coucou,

Ce cher JKB
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus

Ce cher Gugus


Bonsoir,

Bonjour à tous,

sur un système Linux Server RHEL6 (déjà, ça commence bien :D) 24 coeurs
avec 12Go de RAM, lorsque je lance une dizaine de process, gourmands en
mémoire, avec valgrind, je me ramasse une quantité incroyable de OOM
alors que la RAM n’est pas complètement remplie, et la swap n’est même
pas touchée ...



Plus exactement, le problème d’OOM vient bien de valgrind lui-même, et
non du process lancé :

F3== Valgrind's memory management: out of memory:
F3== memcheck:allocate new SecMap's request for 16384 bytes failed.
F3== 710709248 bytes have already been allocated.



Que donne uname -a ? Et file $(which valgrind) ? Ne serait-ce pas par
le plus grand des hasards une machine avec un userland 32 bits ? Ce
qui fait que valgrind se prend un coup de pied aux fesses dès qu'il
consomme un peu plus de 3 Go (le noyau est quelque part entre 3Go et
4Go en adressage virtuel).



Bien essayé, mais non, je suis bien en full 64 bits :

# uname -a
Linux <snip machine du boulot> 2.6.32-279.14.1.el6.x86_64 #1 SMP Mon Oct 15 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
# which valgrind
/usr/bin/valgrind
# file $(!!)
/bin/valgrind: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped



--
Gugus [http://what.dafuq.it/]
JKB
Le #25049622
Le Wed, 12 Dec 2012 10:16:23 +0100,
Gugus

Coucou,

Ce cher JKB
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus

Ce cher Gugus


Bonsoir,

Bonjour à tous,

sur un système Linux Server RHEL6 (déjà, ça commence bien :D) 24 coeurs
avec 12Go de RAM, lorsque je lance une dizaine de process, gourmands en
mémoire, avec valgrind, je me ramasse une quantité incroyable de OOM
alors que la RAM n’est pas complètement remplie, et la swap n’est même
pas touchée ...



Plus exactement, le problème d’OOM vient bien de valgrind lui-même, et
non du process lancé :

F3== Valgrind's memory management: out of memory:
F3== memcheck:allocate new SecMap's request for 16384 bytes failed.
F3== 710709248 bytes have already been allocated.



Que donne uname -a ? Et file $(which valgrind) ? Ne serait-ce pas par
le plus grand des hasards une machine avec un userland 32 bits ? Ce
qui fait que valgrind se prend un coup de pied aux fesses dès qu'il
consomme un peu plus de 3 Go (le noyau est quelque part entre 3Go et
4Go en adressage virtuel).



Bien essayé, mais non, je suis bien en full 64 bits :

# uname -a
Linux <snip machine du boulot> 2.6.32-279.14.1.el6.x86_64 #1 SMP Mon Oct 15 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
# which valgrind
/usr/bin/valgrind
# file $(!!)
/bin/valgrind: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped



Et ton exécutable de test ? Quid des options de compilation de ton
exécutable ? Je pense aux modèles de mémoire de gcc. Par défaut (au
moins jusqu'à une version récente), il ne compile qu'en utilisant
une partie de la mémoire (je pense à quelque chose du genre
-mcmodel=large).

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #25049762
On 12/12/2012 10:16 AM, Gugus a dit:

# which valgrind
/usr/bin/valgrind
# file $(!!)
/bin/valgrind



Là, ça ne semble pas être le même, hein...

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Gugus
Le #25049822
Ce cher JKB

Et ton exécutable de test ? Quid des options de compilation de ton
exécutable ? Je pense aux modèles de mémoire de gcc. Par défaut (au
moins jusqu'à une version récente), il ne compile qu'en utilisant
une partie de la mémoire (je pense à quelque chose du genre
-mcmodel=large).



Aucune idée, ce que je sais c’est que je ne rencontre pas le problème
sur d’autres systèmes multi-CPUS, et avec des fichiers de test beaucoup
plus gros (~1-2Go) ..


Bon, j’ai creusé un peu, et il se trouve que sur cette machine
24-coeurs, il y a 12Go de RAM mais surtout 4Go de swap.. c’est trop peu
je trouve.
J’ai mis 24Go de swap pour tester (oui, c’est peut-être trop..), et là,
ça va tout de suite mieux. Je descendrai à 12Go.

Encore plus loin, je sais qu’«on» (moi, ou des collègues, ..) avait mis
quelques valeurs spécifiques à la gestion mémoire dans sysctl.conf :

vm.panic_on_oom = 0
vm.overcommit_memory = 2
vm.oom_kill_allocating_task = 1

Ceci pour faire la chasse aux problèmes de mémoire de notre soft
(notamment des OOM). La valeur qui me semble la plus dangereuse est
celle du overcommit_memory, je vais la re-vérifier...


..

Bon, je viens de faire l’essai :
pas de swap, overcommit_memory à 0, et je n’ai pas de problème...

Le souci était donc bien lié à la quantité de swap disponible + ce paramètre.

Reste à comprendre pourquoi on avait choisi de mettre '2' à ce
paramètre, et pour ça, la page man de 'proc' n’est pas ultra claire pour
moi ...

--
Gugus [http://what.dafuq.it/]
Gugus
Le #25050132
Ce cher Tonton Th
On 12/12/2012 10:16 AM, Gugus a dit:

# which valgrind
/usr/bin/valgrind
# file $(!!)
/bin/valgrind



Là, ça ne semble pas être le même, hein...



Oups fausse manip, j’ai dû couper le ‘/usr’ de la dernière ligne par mégarde.
Il n’y a pas de /bin/valgrind sur cette machine, donc pas de risque d’erreur.

--
Gugus [http://what.dafuq.it/]
Publicité
Poster une réponse
Anonyme