Simulations arrêtées en cours
Bonjour, J'ai lancé vendredi soir des simulations sur caparmor, et celles-ci semblent toutes arrêtées en cours de simulation ce matin. Je les ai lancées avec la version 4.2.1.2 d'ISIS car la méthode que je voulais utiliser (LHS) ne nous permet pas de faire d'AS sur les matrices qu' Eric à rendues accessibles dans la 4.2.1.3. J'ai recu environ un millier de messages d'erreur de caparmor concernant la "job performance" de mes simus. Dans les premiers messages reçus, cette "job performance" est de 0.72, puis elle décroit progressivement au cours du temps. Dans les derniers messages elle est au mieux à 0.05. J'ai mis en PJ l'état d'avancement des simus tel qu'on peut le voir dans l'interface ISIS. Comme elles sont sensées tourner 16 par 16 sur caparmor on voit que de nouvelles simulations ont été lancées alors que les précédentes n'étaient pas sensées être terminées. Un autre point surprenant est que toutes les simus ne s'arrêtent pas au même pas de temps. La plupart s'arrêtent à l'année 4, mais pas forcément au même mois, et certaines vont jusqu'en Décembre 11 s'arrêtent à l'export des résultats.. J'ai mis une capture d'écran de l'interface d'ISIS où on voit l'état des simus et une de la configuration pour caparmor, au cas où j'aurais encore fait une bêtise de ce côté là. Une idée de la cause du problème, et de comment le résoudre ? Loïc
Et voici le debug. Il n'a pas l'air très informatif. Le 23/12/2013 10:11, Loic GASCHE a écrit :
Bonjour,
J'ai lancé vendredi soir des simulations sur caparmor, et celles-ci semblent toutes arrêtées en cours de simulation ce matin.
Je les ai lancées avec la version 4.2.1.2 d'ISIS car la méthode que je voulais utiliser (LHS) ne nous permet pas de faire d'AS sur les matrices qu' Eric à rendues accessibles dans la 4.2.1.3.
J'ai recu environ un millier de messages d'erreur de caparmor concernant la "job performance" de mes simus. Dans les premiers messages reçus, cette "job performance" est de 0.72, puis elle décroit progressivement au cours du temps. Dans les derniers messages elle est au mieux à 0.05.
J'ai mis en PJ l'état d'avancement des simus tel qu'on peut le voir dans l'interface ISIS. Comme elles sont sensées tourner 16 par 16 sur caparmor on voit que de nouvelles simulations ont été lancées alors que les précédentes n'étaient pas sensées être terminées.
Un autre point surprenant est que toutes les simus ne s'arrêtent pas au même pas de temps. La plupart s'arrêtent à l'année 4, mais pas forcément au même mois, et certaines vont jusqu'en Décembre 11 s'arrêtent à l'export des résultats..
J'ai mis une capture d'écran de l'interface d'ISIS où on voit l'état des simus et une de la configuration pour caparmor, au cas où j'aurais encore fait une bêtise de ce côté là.
Une idée de la cause du problème, et de comment le résoudre ?
Loïc
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 23/12/2013 10:11, Loic GASCHE a écrit :
Bonjour,
Une idée de la cause du problème, et de comment le résoudre ? Je viens de m'apercevoir que caparmor tourne encore avec java6.
Cela expliquerais déjà peut-être les différences de comportements avec une simulations locale. Peut-tu modifier la configuration "Emplacement de java" à : /home3/caparmor/poussin/jdk7/bin/java Et relancer l'AS. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Donc j'enlève aussi le -XXMaxPermSize... ? Le 23/12/2013 10:44, Eric Chatellier a écrit :
Le 23/12/2013 10:11, Loic GASCHE a écrit :
Bonjour,
Une idée de la cause du problème, et de comment le résoudre ? Je viens de m'apercevoir que caparmor tourne encore avec java6.
Cela expliquerais déjà peut-être les différences de comportements avec une simulations locale.
Peut-tu modifier la configuration "Emplacement de java" à : /home3/caparmor/poussin/jdk7/bin/java
Et relancer l'AS.
Le 23/12/2013 10:54, Loic GASCHE a écrit :
Donc j'enlève aussi le -XXMaxPermSize... ? Oui ca se tente !
Et tu peut repasser a 2 ou 3Go de ram -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Bonjour Eric, Je n'ai pas encore relancé l'AS, car entre temps j'ai eu Tina au téléphone. On a regardé la quantité de mémoire qui avait été utilisée par mes jobs. Il apparait que ceux qui ont été tués (code 143 dans la colonne de gauche, ceux qui nous intéressent sont ceux de 18:45) sont ceux qui utilisaient plus de 2.8 gigas de mémoire (le max utilisable par coeur). Pourtant avec la configuration caparmor que j'utilisais dans ISIS, la quantité de mémoire utilisée n'aurait pas du monter si haut, si ? Ca a un lien avec Java ? Si on arrive à résoudre ce pb et que les simus tournent, Tina nous propose d'allonger le temps d'utilisation max par job de la queue ISIS utilisant 256 coeur pour les vacances. Loïc Le 23/12/2013 11:00, Eric Chatellier a écrit :
Le 23/12/2013 10:54, Loic GASCHE a écrit :
Donc j'enlève aussi le -XXMaxPermSize... ? Oui ca se tente !
Et tu peut repasser a 2 ou 3Go de ram
Le 23/12/2013 11:47, Loic GASCHE a écrit :
Bonjour Eric,
Je n'ai pas encore relancé l'AS, car entre temps j'ai eu Tina au téléphone.
On a regardé la quantité de mémoire qui avait été utilisée par mes jobs. Il apparait que ceux qui ont été tués (code 143 dans la colonne de gauche, ceux qui nous intéressent sont ceux de 18:45) sont ceux qui utilisaient plus de 2.8 gigas de mémoire (le max utilisable par coeur).
Pourtant avec la configuration caparmor que j'utilisais dans ISIS, la quantité de mémoire utilisée n'aurait pas du monter si haut, si ?
Ca a un lien avec Java ? Possible, en tout cas, l'erreur actuelle est tellement étrange, que ca ne pourra être que mieux.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
La vraie quetion c'est comment je fais pour faire en sorte qu'ISIS n'utilise pas plus de 2.8 gigas de mémoire ? Car a priori la config caparmor qu'on a utilisée et qui était sensée limiter l'utilisation de mémoire n'a servi à rien, ou en tout cas n'a pas permis de limiter assez l'utilisation de mémoire. Le 23/12/2013 11:54, Eric Chatellier a écrit :
Le 23/12/2013 11:47, Loic GASCHE a écrit :
Bonjour Eric,
Je n'ai pas encore relancé l'AS, car entre temps j'ai eu Tina au téléphone.
On a regardé la quantité de mémoire qui avait été utilisée par mes jobs. Il apparait que ceux qui ont été tués (code 143 dans la colonne de gauche, ceux qui nous intéressent sont ceux de 18:45) sont ceux qui utilisaient plus de 2.8 gigas de mémoire (le max utilisable par coeur).
Pourtant avec la configuration caparmor que j'utilisais dans ISIS, la quantité de mémoire utilisée n'aurait pas du monter si haut, si ?
Ca a un lien avec Java ? Possible, en tout cas, l'erreur actuelle est tellement étrange, que ca ne pourra être que mieux.
J'ai lancé une AS de seulement 16 simus en séquentiel, identique à l'AS précédente mais avec Java7, on va voir ce que ça donne. Le 23/12/2013 12:04, Loic GASCHE a écrit :
La vraie quetion c'est comment je fais pour faire en sorte qu'ISIS n'utilise pas plus de 2.8 gigas de mémoire ?
Car a priori la config caparmor qu'on a utilisée et qui était sensée limiter l'utilisation de mémoire n'a servi à rien, ou en tout cas n'a pas permis de limiter assez l'utilisation de mémoire.
Le 23/12/2013 11:54, Eric Chatellier a écrit :
Le 23/12/2013 11:47, Loic GASCHE a écrit :
Bonjour Eric,
Je n'ai pas encore relancé l'AS, car entre temps j'ai eu Tina au téléphone.
On a regardé la quantité de mémoire qui avait été utilisée par mes jobs. Il apparait que ceux qui ont été tués (code 143 dans la colonne de gauche, ceux qui nous intéressent sont ceux de 18:45) sont ceux qui utilisaient plus de 2.8 gigas de mémoire (le max utilisable par coeur).
Pourtant avec la configuration caparmor que j'utilisais dans ISIS, la quantité de mémoire utilisée n'aurait pas du monter si haut, si ?
Ca a un lien avec Java ? Possible, en tout cas, l'erreur actuelle est tellement étrange, que ca ne pourra être que mieux.
_______________________________________________ Isis-fish-users mailing list Isis-fish-users@list.isis-fish.org http://list.isis-fish.org/cgi-bin/mailman/listinfo/isis-fish-users
Le 23/12/2013 12:04, Loic GASCHE a écrit :
La vraie quetion c'est comment je fais pour faire en sorte qu'ISIS n'utilise pas plus de 2.8 gigas de mémoire ?
Car a priori la config caparmor qu'on a utilisée et qui était sensée limiter l'utilisation de mémoire n'a servi à rien, ou en tout cas n'a pas permis de limiter assez l'utilisation de mémoire. C'est bizarre car normalement il peut pas monter au delà de la limite qu'un lui donne. Esperons qu'avec java 7 cela soit mieux.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On dirait que ça ne change rien avec Java 7, je reçois déjà les mails me disant que la performance de mes jobs sur caparmor est trop faible. Le 23/12/2013 12:09, Eric Chatellier a écrit :
Le 23/12/2013 12:04, Loic GASCHE a écrit :
La vraie quetion c'est comment je fais pour faire en sorte qu'ISIS n'utilise pas plus de 2.8 gigas de mémoire ?
Car a priori la config caparmor qu'on a utilisée et qui était sensée limiter l'utilisation de mémoire n'a servi à rien, ou en tout cas n'a pas permis de limiter assez l'utilisation de mémoire. C'est bizarre car normalement il peut pas monter au delà de la limite qu'un lui donne. Esperons qu'avec java 7 cela soit mieux.
there is no evidence that 'slow' execution (=> cpu% is only 42 to 46% PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28184 lgasche 20 0 2980m 2.2g 508m S 46 9.4 34:16.96 java 28183 lgasche 20 0 2973m 1.8g 27m S 44 7.5 34:25.22 java 28185 lgasche 20 0 2901m 2.2g 496m S 42 9.4 34:23.71 java ) is due to your memory problem. for the moment the memory size it is using is 2.2g. for the job which is running now on caparmor. tina Le 23/12/2013 13:10, Loic GASCHE a écrit :
On dirait que ça ne change rien avec Java 7, je reçois déjà les mails me disant que la performance de mes jobs sur caparmor est trop faible.
Le 23/12/2013 12:09, Eric Chatellier a écrit :
Le 23/12/2013 12:04, Loic GASCHE a écrit :
La vraie quetion c'est comment je fais pour faire en sorte qu'ISIS n'utilise pas plus de 2.8 gigas de mémoire ?
Car a priori la config caparmor qu'on a utilisée et qui était sensée limiter l'utilisation de mémoire n'a servi à rien, ou en tout cas n'a pas permis de limiter assez l'utilisation de mémoire. C'est bizarre car normalement il peut pas monter au delà de la limite qu'un lui donne. Esperons qu'avec java 7 cela soit mieux.
-- =================================================== Tina Odaka RIC - IDM - IMN - IFREMER Pôle de Calcul Intensif pour la Mer (PCIM) Tel: +33 (0)2 98 22 41 85 Fax: +33 (0)2 98 22 45 46 email: Tina.Odaka@ifremer.fr http://www.ifremer.fr/pcim ==================================================
Le 23/12/2013 13:10, Loic GASCHE a écrit :
On dirait que ça ne change rien avec Java 7, je reçois déjà les mails me disant que la performance de mes jobs sur caparmor est trop faible. Ca ne va pas résoudre ce problème. Cela va seulement empecher la simulation de planter en année 4 ou pendant les exports.
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Ca a l'air de tourner pour le moment. Suivant la simulation il y a pas mal de disparités sur l'état d'avancement : après 2h20 environ certaines sont déjà à Février 7 tandis que d'autres sont encore à Avril 5. Donc il devrait falloir entre 4h et 5h pour que chacune de ces simus tournent. Est-ce que ces différences entre simulations sont normales ? Ca correspond environ aux temps de simulation que j'avais obtenus en faisant une AS en local sur le serveur, une simulation prenant entre 4h30 et 4h45. Ce qui est surprenant est que ces simulations dans une Analyse de Sensibilité prennent plus de temps pour tourner que des simulations plus complexes que l'on lance seules. Par exemple des simulations où il y avait en plus des cantonnements soit totaux, soit sur certains engins (donc plus complexes à priori), tournaient en 3h en les lançant seules. Est-ce normal ? Le 23/12/2013 13:35, Eric Chatellier a écrit :
Le 23/12/2013 13:10, Loic GASCHE a écrit :
On dirait que ça ne change rien avec Java 7, je reçois déjà les mails me disant que la performance de mes jobs sur caparmor est trop faible. Ca ne va pas résoudre ce problème. Cela va seulement empecher la simulation de planter en année 4 ou pendant les exports.
Bonjour, A priori le problème de mémoire subsiste. Si je fais un qstat -f de mon job, j'ai 9 simus qui sont en "expired". De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas.
Le 23/12/2013 15:44, Loic GASCHE a écrit :
Bonjour,
A priori le problème de mémoire subsiste.
Si je fais un qstat -f de mon job, j'ai 9 simus qui sont en "expired".
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas. @Tina: Nous lançons les simulations en limitant la taille de la mémoire à 2Go: /home3/caparmor/poussin/jdk7/bin/java -Djava.library.path=jri64 -DR.type=jni -Xmx2000M -jar isis-fish*.jar
Je ne comprend pas très bien pourquoi le jobs peut prendre jusqu'à 2,8Go. Cela correspond à 2,8Go de mémoire RAM ? ou autre chose est-il compté dans cette mémoire ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On 24 déc. 2013, at 09:39, Eric Chatellier <chatellier@codelutin.com> wrote:
Le 23/12/2013 15:44, Loic GASCHE a écrit :
Bonjour,
A priori le problème de mémoire subsiste.
Si je fais un qstat -f de mon job, j'ai 9 simus qui sont en "expired".
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas. @Tina: Nous lançons les simulations en limitant la taille de la mémoire à 2Go: /home3/caparmor/poussin/jdk7/bin/java -Djava.library.path=jri64 -DR.type=jni -Xmx2000M -jar isis-fish*.jar
Je ne comprend pas très bien pourquoi le jobs peut prendre jusqu'à 2,8Go. Cela correspond à 2,8Go de mémoire RAM ? ou autre chose est-il compté dans cette mémoire ?
It is ram When a job is running under your login , if you can find out which compute nosed you are using then do ssh to the compute node And check with top Or ps commands You will see that your java process is using more than 2g of ram ( ssh caparmor Then use command qstat -u your-login To find out your job id currently running qstat -f your-job-id-number to find out which job array number you are running qstat -f your-job-id-number\[array-number\] ( for example qstat -f 123456\[10\] Then you will see r1i1n0 or such host name of compute node ssh r1i1n0 from caparmor) Tina
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
Hi eric, were you able to see that it use more than 2G of ram?? what about if loic's job is submitted with option like -Xmx1000M ?? tina Le 24/12/2013 13:05, Tina Odaka a écrit :
On 24 déc. 2013, at 09:39, Eric Chatellier <chatellier@codelutin.com> wrote:
Le 23/12/2013 15:44, Loic GASCHE a écrit :
Bonjour,
A priori le problème de mémoire subsiste.
Si je fais un qstat -f de mon job, j'ai 9 simus qui sont en "expired".
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas. @Tina: Nous lançons les simulations en limitant la taille de la mémoire à 2Go: /home3/caparmor/poussin/jdk7/bin/java -Djava.library.path=jri64 -DR.type=jni -Xmx2000M -jar isis-fish*.jar
Je ne comprend pas très bien pourquoi le jobs peut prendre jusqu'à 2,8Go. Cela correspond à 2,8Go de mémoire RAM ? ou autre chose est-il compté dans cette mémoire ?
It is ram
When a job is running under your login , if you can find out which compute nosed you are using then do ssh to the compute node And check with top Or ps commands You will see that your java process is using more than 2g of ram ( ssh caparmor Then use command qstat -u your-login To find out your job id currently running qstat -f your-job-id-number to find out which job array number you are running qstat -f your-job-id-number\[array-number\] ( for example qstat -f 123456\[10\] Then you will see r1i1n0 or such host name of compute node ssh r1i1n0 from caparmor)
Tina
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
-- =================================================== Tina Odaka RIC - IDM - IMN - IFREMER Pôle de Calcul Intensif pour la Mer (PCIM) Tel: +33 (0)2 98 22 41 85 Fax: +33 (0)2 98 22 45 46 email: Tina.Odaka@ifremer.fr http://www.ifremer.fr/pcim ==================================================
Hi Tina, We were planning to try to run simulations with -Xmx1000M, but I am not in Nantes at the moment so I have not tried it yet. I will try to run these simulations as soon as I get back and let you know if it worked with -Xmx1000M or not. Loïc Tina ODAKA <Tina.Odaka@ifremer.fr> a écrit :
Hi eric, were you able to see that it use more than 2G of ram?? what about if loic's job is submitted with option like
-Xmx1000M
??
tina
Le 24/12/2013 13:05, Tina Odaka a écrit :
On 24 déc. 2013, at 09:39, Eric Chatellier <chatellier@codelutin.com> wrote:
Le 23/12/2013 15:44, Loic GASCHE a écrit :
Bonjour,
A priori le problème de mémoire subsiste.
Si je fais un qstat -f de mon job, j'ai 9 simus qui sont en "expired".
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas. @Tina: Nous lançons les simulations en limitant la taille de la mémoire à 2Go: /home3/caparmor/poussin/jdk7/bin/java -Djava.library.path=jri64 -DR.type=jni -Xmx2000M -jar isis-fish*.jar
Je ne comprend pas très bien pourquoi le jobs peut prendre jusqu'à 2,8Go. Cela correspond à 2,8Go de mémoire RAM ? ou autre chose est-il compté dans cette mémoire ?
It is ram
When a job is running under your login , if you can find out which compute nosed you are using then do ssh to the compute node And check with top Or ps commands You will see that your java process is using more than 2g of ram ( ssh caparmor Then use command qstat -u your-login To find out your job id currently running qstat -f your-job-id-number to find out which job array number you are running qstat -f your-job-id-number\[array-number\] ( for example qstat -f 123456\[10\] Then you will see r1i1n0 or such host name of compute node ssh r1i1n0 from caparmor)
Tina
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
-- =================================================== Tina Odaka RIC - IDM - IMN - IFREMER Pôle de Calcul Intensif pour la Mer (PCIM)
Tel: +33 (0)2 98 22 41 85 Fax: +33 (0)2 98 22 45 46 email: Tina.Odaka@ifremer.fr http://www.ifremer.fr/pcim ==================================================
Le 23/12/2013 15:44, Loic GASCHE a écrit :
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas.
Sinon, loic, au pire essaye en réduisant la mémoire à 1500 ou 1000M. Je ne sais plus trop quoi essayer :( -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
J'ai lancé une petite AS hier en réduisant la mémoire à 1000M, toutes les simus se sont arrêtées au cours de l'année 9. Le 24/12/2013 09:41, Eric Chatellier a écrit :
Le 23/12/2013 15:44, Loic GASCHE a écrit :
De plus si je fais la commande que m'a donnée Tina, je vois que plusieurs de mes simus de tout à l'heure apparaissent en type 143, avec des quantités de mémoire utilisées supérieures à 2.8 gigas.
Sinon, loic, au pire essaye en réduisant la mémoire à 1500 ou 1000M. Je ne sais plus trop quoi essayer :(
participants (5)
-
Eric Chatellier -
Loic GASCHE -
Loic.Gasche＠ifremer.fr
-
Tina ODAKA -
Tina Odaka