[linux] out of memory avec +sieurs valgrind en parallèle, mais plein de mémoire libre..
7 réponses
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 ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gugus
Ce cher Gugus a posté :
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/]
Ce cher Gugus <what@dafuq.it> a posté :
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é :
=463== Valgrind's memory management: out of memory:
=463== memcheck:allocate new SecMap's request for 16384 bytes failed.
=463== 710709248 bytes have already been allocated.
=463== Valgrind cannot continue. Sorry.
=463= =463== There are several possible reasons for this.
=463== - You have some kind of memory limit in place. Look at the
=463== output of 'ulimit -a'. Is there a limit on the size of
=463== virtual memory or address space?
=463== - You have run out of swap space.
=463== - Valgrind has a bug. If you think this is the case or you are
=463== not sure, please let us know and we'll try to fix it.
=463== Please note that programs can take substantially more memory
than
=463== normal when running under Valgrind tools, eg. up to twice or
=463== more, depending on the tool. On a 64-bit machine, Valgrind
=463== should be able to make use of up 32GB memory. On a 32-bit
=463== machine, Valgrind should be able to use all the memory
available
=463== to a single process, up to 4GB if that's how you have your
=463== kernel configured. Most 32-bit Linux setups allow a maximum of
=463== 3GB per process.
=463= =463== Whatever the reason, Valgrind cannot continue. Sorry.
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 Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus <what@dafuq.it> écrivait :
Ce cher Gugus <what@dafuq.it> a posté :
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é :
=463== Valgrind's memory management: out of memory:
=463== memcheck:allocate new SecMap's request for 16384 bytes failed.
=463== 710709248 bytes have already been allocated.
=463== Valgrind cannot continue. Sorry.
=463= >=463== There are several possible reasons for this.
=463== - You have some kind of memory limit in place. Look at the
=463== output of 'ulimit -a'. Is there a limit on the size of
=463== virtual memory or address space?
=463== - You have run out of swap space.
=463== - Valgrind has a bug. If you think this is the case or you are
=463== not sure, please let us know and we'll try to fix it.
=463== Please note that programs can take substantially more memory
than
=463== normal when running under Valgrind tools, eg. up to twice or
=463== more, depending on the tool. On a 64-bit machine, Valgrind
=463== should be able to make use of up 32GB memory. On a 32-bit
=463== machine, Valgrind should be able to use all the memory
available
=463== to a single process, up to 4GB if that's how you have your
=463== kernel configured. Most 32-bit Linux setups allow a maximum of
=463== 3GB per process.
=463= >=463== 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
Le Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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
Coucou,
Ce cher JKB a posté :
Le Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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/]
Coucou,
Ce cher JKB <jkb@koenigsberg.invalid> a posté :
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus <what@dafuq.it> écrivait :
Ce cher Gugus <what@dafuq.it> a posté :
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é :
=463== Valgrind's memory management: out of memory:
=463== memcheck:allocate new SecMap's request for 16384 bytes failed.
=463== 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
Le Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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 Wed, 12 Dec 2012 10:16:23 +0100, Gugus écrivait :
Coucou,
Ce cher JKB a posté :
Le Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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
Le Wed, 12 Dec 2012 10:16:23 +0100,
Gugus <what@dafuq.it> écrivait :
Coucou,
Ce cher JKB <jkb@koenigsberg.invalid> a posté :
Le Tue, 11 Dec 2012 17:55:04 +0100,
Gugus <what@dafuq.it> écrivait :
Ce cher Gugus <what@dafuq.it> a posté :
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é :
=463== Valgrind's memory management: out of memory:
=463== memcheck:allocate new SecMap's request for 16384 bytes failed.
=463== 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
Le Wed, 12 Dec 2012 10:16:23 +0100, Gugus écrivait :
Coucou,
Ce cher JKB a posté :
Le Tue, 11 Dec 2012 17:55:04 +0100, Gugus écrivait :
Ce cher Gugus a posté :
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
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/
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/
# 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
Ce cher JKB a posté :
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 :
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/]
Ce cher JKB <jkb@koenigsberg.invalid> a posté :
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 :
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 ...
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 :
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
Ce cher Tonton Th a posté :
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/]
Ce cher Tonton Th <tth@la.bas.invalid> a posté :
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.
# 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.
