Re: [Isis-fish-devel] Fwd: Re: CAPARMOR - différence entre la réservation cpu et l'utilisation
thanks, i'm following your job now. you are using r2i2n2 for your job (for array number 1) http://caparmor-admin2.ifremer.fr/ganglia/?m=load_one&r=hour&s=descending&c=Rack+2&h=r2i2n2&sh=1&hc=4&z=small if the developper from isis-fish want to follow how the job evolve, using top or strace, they need to connect caparmor with your account, then do ssh r2i2n2 with your account. tina Le 07/01/2014 10:30, Loic GASCHE a écrit :
Hi Tina,
I submitted the same job as yesterday using the option you told me to use.
Loïc
Le 07/01/2014 10:10, Tina ODAKA a écrit :
hi loic, can you try to submit same job you've submitted yesterday this morning? (plz use option -q parallel8 -l select=1:ncpus=8 ) i want to verify if you've really using 8 cores; thanks tina
Le 07/01/2014 09:55, Denis Croizé-Fillon a écrit :
-------- Original Message -------- Subject: Re: CAPARMOR - différence entre la réservation cpu et l'utilisation Date: Mon, 06 Jan 2014 17:12:27 +0100 From: Denis Croizé-Fillon <Denis.Croize.Fillon@ifremer.fr> To: Loic GASCHE <Loic.Gasche@ifremer.fr>, isis-fish-devel@list.isis-fish.org
Ok, merci de votre retour. Je verrai avec tina et l'équipe isis-fisch car les processus java utilisent plus d'un coeur et pénalisent les autres utilisateurs
Bonne fin de journée, Denis
On 01/06/14 16:58, Loic GASCHE wrote:
Bonjour,
Lorsque lancé dans la queue "sequentiel" ISIS-Fish utilise habituellement 8 coeurs.
Nous n'utilisons pas les files "parallel" car en fait ISIS fait tourner une simulation par coeur, l'utilisation de beaucoup de coeurs venant du fait que nous faisons de nombreuses simulations en même temps.
Il y a à priori une file spéciale pour ISIS mais elle limite les jobs à 10 minutes, ce qui est très insuffisant pour les simulations que nous faisons tourner actuellement.
Tina m'a donc dit d'utiliser la file "sequentiel", que nous utilisons par ailleurs depuis plusieurs années. J'ai d'ailleurs déjà fait tourner des dizaines de milliers de simulations de cette manière.
Je n'ai pas les compétences techniques pour faire évoluer ISIS afin de pouvoir utiliser les queues "parallel", mais je transmets votre mail à la liste des développeurs afin de voir quelles seraient les solutions.
Loïc
Le 06/01/2014 16:36, Denis Croizé-Fillon a écrit :
Bonjour,
j'observe pour vos jobs 6019446[0] et 6019446[1] une différence entre la réservation CPU et l'utilisation qui est faite.
Vous lancez ces processus sur sequentiel correspondant à un unique coeur utilisé. La commande qstat -f 6019446\[0\] montre alors ce que PBS réserve : exec_vnode = (r5i2n8:mem=2867200kb:ncpus=1)
Pourtant, localement, le processus utilise plus qu'un coeur (% cpu supérieur à 100): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1990 lgasche 20 0 2562m 1.6g 406m S 255 6.7 213:43.96 java
1994 lgasche 20 0 2603m 2.3g 1.1g S 164 9.8 219:46.86 java
Votre processus java apparait faire du multithreading, donc utilisant plus d'un coeur. Toutefois, le noeud de calcul est également utilisé par d'autres processus ayant fait la demande des coeurs disponibles. Ces processus n'ont toutefois pas accès à toutes les ressources demandées puisque utilisées par vos processus.
Il vous faut donc, soit limiter votre utilisation en nombre de coeur à 1 comme ce qui est réservé ou, demander plus de coeurs et soumettre sur une file comme parallel8 parallel16 ...
Merci de faire évoluer vos scripts en ce sens et de relancer vos jobs pour libérer les ressources des autres utilisateurs. Merci
Denis
-- =================================================== 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 ==================================================
hello loic, your job change its behaviour around 11:15, which is about 100 minutes after you submitted your job. until then, it only used 1 core. but from that point it starts to use more than 1 core, on average use 2 core, sometime it goes up to 4 cores. can anyone explain to me what kind of parallelism you are using for each of your java process?? actually, mem is exceeding 2.2g r2i2n2:~ # ps -ef |grep lgasche lgasche 29900 5283 0 09:28 ? 00:00:00 -csh lgasche 29941 29900 0 09:28 ? 00:00:00 /bin/csh /var/spool/PBS/mom_priv/jobs/6020995[1].service0.ice.ifremer.fr.SC lgasche 29944 29941 99 09:28 ? 02:59:33 /home3/caparmor/poussin/jdk7/bin/java -Djava.library.path=jri64 -DR.type=jni -Xmx1000M -jar isis-fish-4.2.1.2.jar --option launch.ui false --option perform.vcsupdate false --option perform.migration false --option perform.cron false --simulateRemotellyWithPreScript as_7DV10_toutesRegles_CantonnementsTotaux_1000M_testParallel8_2014-01-07-10-28_1 /home1/caparmor/lgasche/isis-tmp/simulation-as_7DV10_toutesRegles_CantonnementsTotaux_1000M_testParallel8_2014-01-07-10-28-preparation.zip /home1/caparmor/lgasche/isis-tmp/simulation-as_7DV10_toutesRegles_CantonnementsTotaux_1000M_testParallel8_2014-01-07-10-28_1-result.zip /home1/caparmor/lgasche/isis-tmp/simulation-as_7DV10_toutesRegles_CantonnementsTotaux_1000M_testParallel8_2014-01-07-10-28_1-prescript.bsh root 30806 30067 0 11:52 pts/0 00:00:00 grep lgasche r2i2n2:~ # top shows; 29944 lgasche 20 0 2486m 2.2g 1.0g S 565 9.5 182:05.45 java regards, tina Le 07/01/2014 10:38, Tina ODAKA a écrit :
thanks, i'm following your job now. you are using r2i2n2 for your job (for array number 1) http://caparmor-admin2.ifremer.fr/ganglia/?m=load_one&r=hour&s=descending&c=Rack+2&h=r2i2n2&sh=1&hc=4&z=small
if the developper from isis-fish want to follow how the job evolve, using top or strace, they need to connect caparmor with your account, then do ssh r2i2n2 with your account.
tina
Le 07/01/2014 10:30, Loic GASCHE a écrit :
Hi Tina,
I submitted the same job as yesterday using the option you told me to use.
Loïc
Le 07/01/2014 10:10, Tina ODAKA a écrit :
hi loic, can you try to submit same job you've submitted yesterday this morning? (plz use option -q parallel8 -l select=1:ncpus=8 ) i want to verify if you've really using 8 cores; thanks tina
Le 07/01/2014 09:55, Denis Croizé-Fillon a écrit :
-------- Original Message -------- Subject: Re: CAPARMOR - différence entre la réservation cpu et l'utilisation Date: Mon, 06 Jan 2014 17:12:27 +0100 From: Denis Croizé-Fillon <Denis.Croize.Fillon@ifremer.fr> To: Loic GASCHE <Loic.Gasche@ifremer.fr>, isis-fish-devel@list.isis-fish.org
Ok, merci de votre retour. Je verrai avec tina et l'équipe isis-fisch car les processus java utilisent plus d'un coeur et pénalisent les autres utilisateurs
Bonne fin de journée, Denis
On 01/06/14 16:58, Loic GASCHE wrote:
Bonjour,
Lorsque lancé dans la queue "sequentiel" ISIS-Fish utilise habituellement 8 coeurs.
Nous n'utilisons pas les files "parallel" car en fait ISIS fait tourner une simulation par coeur, l'utilisation de beaucoup de coeurs venant du fait que nous faisons de nombreuses simulations en même temps.
Il y a à priori une file spéciale pour ISIS mais elle limite les jobs à 10 minutes, ce qui est très insuffisant pour les simulations que nous faisons tourner actuellement.
Tina m'a donc dit d'utiliser la file "sequentiel", que nous utilisons par ailleurs depuis plusieurs années. J'ai d'ailleurs déjà fait tourner des dizaines de milliers de simulations de cette manière.
Je n'ai pas les compétences techniques pour faire évoluer ISIS afin de pouvoir utiliser les queues "parallel", mais je transmets votre mail à la liste des développeurs afin de voir quelles seraient les solutions.
Loïc
Le 06/01/2014 16:36, Denis Croizé-Fillon a écrit :
Bonjour,
j'observe pour vos jobs 6019446[0] et 6019446[1] une différence entre la réservation CPU et l'utilisation qui est faite.
Vous lancez ces processus sur sequentiel correspondant à un unique coeur utilisé. La commande qstat -f 6019446\[0\] montre alors ce que PBS réserve : exec_vnode = (r5i2n8:mem=2867200kb:ncpus=1)
Pourtant, localement, le processus utilise plus qu'un coeur (% cpu supérieur à 100): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1990 lgasche 20 0 2562m 1.6g 406m S 255 6.7 213:43.96 java
1994 lgasche 20 0 2603m 2.3g 1.1g S 164 9.8 219:46.86 java
Votre processus java apparait faire du multithreading, donc utilisant plus d'un coeur. Toutefois, le noeud de calcul est également utilisé par d'autres processus ayant fait la demande des coeurs disponibles. Ces processus n'ont toutefois pas accès à toutes les ressources demandées puisque utilisées par vos processus.
Il vous faut donc, soit limiter votre utilisation en nombre de coeur à 1 comme ce qui est réservé ou, demander plus de coeurs et soumettre sur une file comme parallel8 parallel16 ...
Merci de faire évoluer vos scripts en ce sens et de relancer vos jobs pour libérer les ressources des autres utilisateurs. Merci
Denis
-- =================================================== 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 07/01/2014 12:55, Tina ODAKA a écrit :
hello loic, hi your job change its behaviour around 11:15, which is about 100 minutes after you submitted your job.
until then, it only used 1 core. but from that point it starts to use more than 1 core, on average use 2 core, sometime it goes up to 4 cores.
can anyone explain to me what kind of parallelism you are using for each of your java process?? actually, mem is exceeding 2.2g our caparmor jobs runs only one java process.
Into this java process, we are using java "soft" thread, but maybe since recents releases (java 7) java can parallelize thus threads in multiples cores. For now, i don't know if we can control this behaviour with java. Is there a possibility to reduce job's visible core to one (with qsub options or env vars) ? Regards. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
hello du nouveau??? Loic est vraiment bloqué. Comment peut-on faire avancer la resolution du probleme? Merci Stephanie Le 07/01/2014 16:00, Eric Chatellier a écrit :
Le 07/01/2014 12:55, Tina ODAKA a écrit :
hello loic, hi your job change its behaviour around 11:15, which is about 100 minutes after you submitted your job.
until then, it only used 1 core. but from that point it starts to use more than 1 core, on average use 2 core, sometime it goes up to 4 cores.
can anyone explain to me what kind of parallelism you are using for each of your java process?? actually, mem is exceeding 2.2g our caparmor jobs runs only one java process.
Into this java process, we are using java "soft" thread, but maybe since recents releases (java 7) java can parallelize thus threads in multiples cores. For now, i don't know if we can control this behaviour with java.
Is there a possibility to reduce job's visible core to one (with qsub options or env vars) ?
Regards.
-- ...................................................................... Stephanie MAHEVAS (Stephanie.Mahevas@ifremer.fr) IFREMER/EMH (Ecologie et Modèles pour l'Halieutique) Tel: (33) 2 40 37 41 81 Fax: (33) 2 40 37 40 75 o \ o / _ o __| \ / |__ o _ \ o / o /|\ | /\ ___\o \o | o/ o/__ /\ | /|\ / \ / \ | \ /) | ( \ /o\ / ) | (\ / | / \ / \ ......................................................................
Le 10/01/2014 14:59, Stephanie MAHEVAS a écrit :
hello
du nouveau??? Loic est vraiment bloqué. Comment peut-on faire avancer la resolution du probleme? On a peut-être identifié une option qui par défaut fonctionne en multi coeur.
Sur la ligne "Emplacement de Java", peut-tu essayer d'ajouter : "-XX:+UseSerialGC". Exemple au final: /home3/caparmor/poussin/jdk64/bin/java -XX:+UseSerialGC -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
participants (3)
-
Eric Chatellier -
Stephanie MAHEVAS -
Tina ODAKA