Temps de simu très variables pour les simus d'une même AS ?
Bonjour, C'est un phénomène qu'on observe assez souvent, mais que je n'arrive pas à expliquer : des simulations d'une même AS ne durent pas du tout le même temps dans certains cas quand on les fait tourner sur caparmor. Par exemple, dans ma grosse AS qui avait planté, j'ai retrouvé deux simus qui avaient tourné et avaient été téléchargées correctement (la 161 et la 193), ce qui veut dire qu'elles avaient tourné en moins de 3 heures. J'en ai encore eu un exemple assez frappant ce matin. J'ai repris les paramètres de ma grosse AS pour faire des tests de petites AS afin de voir si les options PBS fonctionnent. Sur les 4 simus de l'AS une d'entre elles a plus de 2 ans d'avance sur les autres en milieu de simu ! C'est très loin d'être négligeable. Donc je me demandais si on a une idée de la causes de ces ralentissements/accélérations, et si ca ne peut pas être lié au fait qu'on gagne si peu de temps en écrivant dans la ram alors qu'on avait prévu d'en gagner beaucoup plus ? Loïc
Bonjour, J'ai continué à faire des tests, et en particulier à comparer les temps de simu en local avec ceux sur caparmor. J'ai pour cela lancé deux AS de 4 simus identiques, une en local et une sur caparmor (en conservant tous les timeSteps et pas seulement les 13 derniers, je me demandais si ça ne pouvait pas être une des cause des problèmes). Sur caparmor j'ai utilisé la queue isisfish et ai augmenté le walltime de mes simus à 5h. Elles ont bien tourné 5h car à 23h05 je recevais encore les messages d'avertissement de caparmor me disant qu'elles ne tournaient pas assez bien (elles ont été lancées à 18h10). Aucune des simus lancées sur caparmor n'est arrivée à son terme, même en 5 heures. Donc il semble que la situation soit en fait encore pire qu'avant quand on écrivait tous les pas de temps sur le disque. Là aussi on observe une variabilité extrême dans les temps de simu, une des simus étant à l'année 6 au bout de 5h alors que les autres étaient à l'année 11. J'ai lancé la même AS une minute après en local. Toutes les simus de cette AS ont mis moins de 3 heures pour tourner, le dossier de chacune de ces simus ayant été mis à jour pour la dernière fois entre 2h32 et 2h41 après l'heure de lancement de la simu. Donc en résumé on a des simus similaires en termes de règles et de paramètres utilisés, utilisant la même base, tournant sur des processeurs quasiment identiques, et pourtant le temps de simulation est approximativement deux fois plus élevé sur caparmor. Ca traduit bien de la présence d'un soucis quelque part non ? Est-ce que ca ne vaudrait pas le coup de repasser à la 4.2.1.2 sur caparmor pour pouvoir relancer des simus et voir si les temps de simulation sont du même ordre, afin de tenter de piger d'où vient le problème ? Loïc Le 03/03/2014 11:44, Loic GASCHE a écrit :
Bonjour,
C'est un phénomène qu'on observe assez souvent, mais que je n'arrive pas à expliquer : des simulations d'une même AS ne durent pas du tout le même temps dans certains cas quand on les fait tourner sur caparmor.
Par exemple, dans ma grosse AS qui avait planté, j'ai retrouvé deux simus qui avaient tourné et avaient été téléchargées correctement (la 161 et la 193), ce qui veut dire qu'elles avaient tourné en moins de 3 heures.
J'en ai encore eu un exemple assez frappant ce matin. J'ai repris les paramètres de ma grosse AS pour faire des tests de petites AS afin de voir si les options PBS fonctionnent.
Sur les 4 simus de l'AS une d'entre elles a plus de 2 ans d'avance sur les autres en milieu de simu ! C'est très loin d'être négligeable.
Donc je me demandais si on a une idée de la causes de ces ralentissements/accélérations, et si ca ne peut pas être lié au fait qu'on gagne si peu de temps en écrivant dans la ram alors qu'on avait prévu d'en gagner beaucoup plus ?
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
Salut les lutins, Vous n'avez pas de pistes ? J'ai oublié de préciser que j'ai aussi essayé de jouer avec les arguments qsub pour modifier la quantité de mémoire par simu et forcer chaque simu à tourner sur un unique coeur, ça n'a rien changé. Loïc Loic GASCHE <Loic.Gasche@ifremer.fr> a écrit :
Bonjour,
J'ai continué à faire des tests, et en particulier à comparer les temps de simu en local avec ceux sur caparmor.
J'ai pour cela lancé deux AS de 4 simus identiques, une en local et une sur caparmor (en conservant tous les timeSteps et pas seulement les 13 derniers, je me demandais si ça ne pouvait pas être une des cause des problèmes).
Sur caparmor j'ai utilisé la queue isisfish et ai augmenté le walltime de mes simus à 5h. Elles ont bien tourné 5h car à 23h05 je recevais encore les messages d'avertissement de caparmor me disant qu'elles ne tournaient pas assez bien (elles ont été lancées à 18h10).
Aucune des simus lancées sur caparmor n'est arrivée à son terme, même en 5 heures. Donc il semble que la situation soit en fait encore pire qu'avant quand on écrivait tous les pas de temps sur le disque.
Là aussi on observe une variabilité extrême dans les temps de simu, une des simus étant à l'année 6 au bout de 5h alors que les autres étaient à l'année 11.
J'ai lancé la même AS une minute après en local.
Toutes les simus de cette AS ont mis moins de 3 heures pour tourner, le dossier de chacune de ces simus ayant été mis à jour pour la dernière fois entre 2h32 et 2h41 après l'heure de lancement de la simu.
Donc en résumé on a des simus similaires en termes de règles et de paramètres utilisés, utilisant la même base, tournant sur des processeurs quasiment identiques, et pourtant le temps de simulation est approximativement deux fois plus élevé sur caparmor.
Ca traduit bien de la présence d'un soucis quelque part non ?
Est-ce que ca ne vaudrait pas le coup de repasser à la 4.2.1.2 sur caparmor pour pouvoir relancer des simus et voir si les temps de simulation sont du même ordre, afin de tenter de piger d'où vient le problème ?
Loïc
Le 03/03/2014 11:44, Loic GASCHE a écrit :
Bonjour,
C'est un phénomène qu'on observe assez souvent, mais que je n'arrive pas à expliquer : des simulations d'une même AS ne durent pas du tout le même temps dans certains cas quand on les fait tourner sur caparmor.
Par exemple, dans ma grosse AS qui avait planté, j'ai retrouvé deux simus qui avaient tourné et avaient été téléchargées correctement (la 161 et la 193), ce qui veut dire qu'elles avaient tourné en moins de 3 heures.
J'en ai encore eu un exemple assez frappant ce matin. J'ai repris les paramètres de ma grosse AS pour faire des tests de petites AS afin de voir si les options PBS fonctionnent.
Sur les 4 simus de l'AS une d'entre elles a plus de 2 ans d'avance sur les autres en milieu de simu ! C'est très loin d'être négligeable.
Donc je me demandais si on a une idée de la causes de ces ralentissements/accélérations, et si ca ne peut pas être lié au fait qu'on gagne si peu de temps en écrivant dans la ram alors qu'on avait prévu d'en gagner beaucoup plus ?
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 06/03/2014 10:07, Loic.Gasche@ifremer.fr a écrit :
Salut les lutins,
Vous n'avez pas de pistes ?
J'ai oublié de préciser que j'ai aussi essayé de jouer avec les arguments qsub pour modifier la quantité de mémoire par simu et forcer chaque simu à tourner sur un unique coeur, ça n'a rien changé. Non, pas vraiment.
Soit c'est caparmor qui a un problème (par exemple un nœud moins performant qu'un autre). Soit c'est un des paramètres de ton AS qui influence l’exécution (par exemple un preAction ou postAction d'une règle qui s’exécute plus souvent). Très difficile à dire en tout cas. Les AS sont terminées ? Tu peux regarder dans le simulation.log ou le simulation.control ou information si ca vient d'une regles en particulier. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
En fait le fait que ce soit très variable c'est presque secondaire, la question principale c'est pourquoi c'est si long. J'avais augmenté le temps de simu à 5 heures mais même comme ça ça n'avait pas marché, donc je n'ai aucun log de simu. Il faudrait que je laisse les simus tourner encore plus longtemps sur caparmor. Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 06/03/2014 10:07, Loic.Gasche@ifremer.fr a écrit :
Salut les lutins,
Vous n'avez pas de pistes ?
J'ai oublié de préciser que j'ai aussi essayé de jouer avec les arguments qsub pour modifier la quantité de mémoire par simu et forcer chaque simu à tourner sur un unique coeur, ça n'a rien changé. Non, pas vraiment.
Soit c'est caparmor qui a un problème (par exemple un nœud moins performant qu'un autre).
Soit c'est un des paramètres de ton AS qui influence l’exécution (par exemple un preAction ou postAction d'une règle qui s’exécute plus souvent).
Très difficile à dire en tout cas.
Les AS sont terminées ? Tu peux regarder dans le simulation.log ou le simulation.control ou information si ca vient d'une regles en particulier.
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
_______________________________________________ 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 06/03/2014 13:13, Loic.Gasche@ifremer.fr a écrit :
En fait le fait que ce soit très variable c'est presque secondaire, la question principale c'est pourquoi c'est si long. Ha oui, mais je peux difficilement répondre. Tina ne t'as pas encore répondu ?
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Tina n'est pas là en ce moment. J'avais fait un mail à Denis Croizé-Fillon qui s'occupe aussi de caparmor, au début il penchait plus pour un "problème" ISIS à priori vu qu'il m'avait indiqué de voir avec vous. On en a brièvement rediscuté ce matin, il n'avait toujours pas l'air de penser que ça venait de caparmor. Je vais essayer d'en remettre une couche, mais je ne pense pas que ça donne grand chose. Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 06/03/2014 13:13, Loic.Gasche@ifremer.fr a écrit :
En fait le fait que ce soit très variable c'est presque secondaire, la question principale c'est pourquoi c'est si long. Ha oui, mais je peux difficilement répondre. Tina ne t'as pas encore répondu ?
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
_______________________________________________ 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 06/03/2014 16:11, Loic.Gasche@ifremer.fr a écrit :
Tina n'est pas là en ce moment.
J'avais fait un mail à Denis Croizé-Fillon qui s'occupe aussi de caparmor, au début il penchait plus pour un "problème" ISIS à priori vu qu'il m'avait indiqué de voir avec vous.
On en a brièvement rediscuté ce matin, il n'avait toujours pas l'air de penser que ça venait de caparmor.
Je vais essayer d'en remettre une couche, mais je ne pense pas que ça donne grand chose. En fait, ce qu'il faudrait, c'est les statistiques des simulations lentes et pas lentes pour savoir quoi chercher, sinon, on ne va faire que se renvoyer la balle. Tu as les commandes de tina pour avoir les stats utilisations disque / processeurs ?
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Salut Eric, Alors après m'être connecté à caparmor : qstat -u lgasche pour trouver mes jobs qstat -f jobID\[numeroSimu\] pour trouver sur quel node caparmor la simu est entrain de tourner (ligne exec_node). Une fois qu'on connait le node, soit aller sur : http://caparmor-admin2.ifremer.fr/ganglia/?r=hour&s=descending&c= et sélectionner son rack puis son node dans la liste jusqu'à trouver celui qu'on veut. Ou alors faire ssh numNode (ex ssh r2i2n2) Puis on peut faire top pour savoir le numero des simus ISIS sur ce node. Enfin on peut faire strace -p numSimNode -f, par exemple strace -p 29006 -f pour avoir les infos sur la simu. Par contre il y a énormément d'infos donc il faudrait les écrire dans un fichier à part pour pouvoir les lire correctement. Comment faire ça facilement ? A première vue comme le disait Tina il y apleins de "futex..." Voilà, c'est ce que j'ai ressorti des mails de Tina, ça a l'air de marcher. Loïc Le 06/03/2014 16:18, Eric Chatellier a écrit :
Le 06/03/2014 16:11, Loic.Gasche@ifremer.fr a écrit :
Tina n'est pas là en ce moment.
J'avais fait un mail à Denis Croizé-Fillon qui s'occupe aussi de caparmor, au début il penchait plus pour un "problème" ISIS à priori vu qu'il m'avait indiqué de voir avec vous.
On en a brièvement rediscuté ce matin, il n'avait toujours pas l'air de penser que ça venait de caparmor.
Je vais essayer d'en remettre une couche, mais je ne pense pas que ça donne grand chose. En fait, ce qu'il faudrait, c'est les statistiques des simulations lentes et pas lentes pour savoir quoi chercher, sinon, on ne va faire que se renvoyer la balle. Tu as les commandes de tina pour avoir les stats utilisations disque / processeurs ?
PS : j'ai une AS de 4 simus lancée ce matin entrain de tourner, donc on peut effectivement aller voir ce qui se passe. Elles ont un walltime de 10h donc peut-être que cette fois-ci elles vont arriver à leur terme. Le 07/03/2014 09:19, Loic GASCHE a écrit :
Salut Eric,
Alors après m'être connecté à caparmor :
qstat -u lgasche pour trouver mes jobs
qstat -f jobID\[numeroSimu\] pour trouver sur quel node caparmor la simu est entrain de tourner (ligne exec_node).
Une fois qu'on connait le node, soit aller sur :
http://caparmor-admin2.ifremer.fr/ganglia/?r=hour&s=descending&c=
et sélectionner son rack puis son node dans la liste jusqu'à trouver celui qu'on veut.
Ou alors faire ssh numNode (ex ssh r2i2n2)
Puis on peut faire top pour savoir le numero des simus ISIS sur ce node.
Enfin on peut faire strace -p numSimNode -f, par exemple strace -p 29006 -f pour avoir les infos sur la simu.
Par contre il y a énormément d'infos donc il faudrait les écrire dans un fichier à part pour pouvoir les lire correctement. Comment faire ça facilement ?
A première vue comme le disait Tina il y apleins de "futex..."
Voilà, c'est ce que j'ai ressorti des mails de Tina, ça a l'air de marcher.
Loïc
Le 06/03/2014 16:18, Eric Chatellier a écrit :
Tina n'est pas là en ce moment.
J'avais fait un mail à Denis Croizé-Fillon qui s'occupe aussi de caparmor, au début il penchait plus pour un "problème" ISIS à priori vu qu'il m'avait indiqué de voir avec vous.
On en a brièvement rediscuté ce matin, il n'avait toujours pas l'air de penser que ça venait de caparmor.
Je vais essayer d'en remettre une couche, mais je ne pense pas que ça donne grand chose. En fait, ce qu'il faudrait, c'est les statistiques des simulations lentes et pas lentes pour savoir quoi chercher, sinon, on ne va faire que se renvoyer la balle. Tu as les commandes de tina pour avoir les stats utilisations disque /
Le 06/03/2014 16:11, Loic.Gasche@ifremer.fr a écrit : processeurs ?
Mes simus de ce matin ont mis 4h15 à 4h25 pour tourner... Donc plus qu'en local mais moins que précédemment puisque elles n'arrivaient pas à leur terme en 5 heures... c'est à n'y plus rien comprendre. J'ai relancé la même AS avec la même config' caparmor pour voir si les résultats sont identiques. Qu'est-ce qu'il faut rechercher en particulier dans les infos accessibles sur caparmor concernant les simus, car c'est vraiment touffu ? Loïc Le 07/03/2014 09:26, Loic GASCHE a écrit :
PS : j'ai une AS de 4 simus lancée ce matin entrain de tourner, donc on peut effectivement aller voir ce qui se passe.
Elles ont un walltime de 10h donc peut-être que cette fois-ci elles vont arriver à leur terme.
Le 07/03/2014 09:19, Loic GASCHE a écrit :
Salut Eric,
Alors après m'être connecté à caparmor :
qstat -u lgasche pour trouver mes jobs
qstat -f jobID\[numeroSimu\] pour trouver sur quel node caparmor la simu est entrain de tourner (ligne exec_node).
Une fois qu'on connait le node, soit aller sur :
http://caparmor-admin2.ifremer.fr/ganglia/?r=hour&s=descending&c=
et sélectionner son rack puis son node dans la liste jusqu'à trouver celui qu'on veut.
Ou alors faire ssh numNode (ex ssh r2i2n2)
Puis on peut faire top pour savoir le numero des simus ISIS sur ce node.
Enfin on peut faire strace -p numSimNode -f, par exemple strace -p 29006 -f pour avoir les infos sur la simu.
Par contre il y a énormément d'infos donc il faudrait les écrire dans un fichier à part pour pouvoir les lire correctement. Comment faire ça facilement ?
A première vue comme le disait Tina il y apleins de "futex..."
Voilà, c'est ce que j'ai ressorti des mails de Tina, ça a l'air de marcher.
Loïc
Le 06/03/2014 16:18, Eric Chatellier a écrit :
Tina n'est pas là en ce moment.
J'avais fait un mail à Denis Croizé-Fillon qui s'occupe aussi de caparmor, au début il penchait plus pour un "problème" ISIS à priori vu qu'il m'avait indiqué de voir avec vous.
On en a brièvement rediscuté ce matin, il n'avait toujours pas l'air de penser que ça venait de caparmor.
Je vais essayer d'en remettre une couche, mais je ne pense pas que ça donne grand chose. En fait, ce qu'il faudrait, c'est les statistiques des simulations lentes et pas lentes pour savoir quoi chercher, sinon, on ne va faire que se renvoyer la balle. Tu as les commandes de tina pour avoir les stats utilisations disque /
Le 06/03/2014 16:11, Loic.Gasche@ifremer.fr a écrit : processeurs ?
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 07/03/2014 09:19, Loic GASCHE a écrit :
Salut Eric,
Alors après m'être connecté à caparmor :
qstat -u lgasche pour trouver mes jobs
qstat -f jobID\[numeroSimu\] pour trouver sur quel node caparmor la simu est entrain de tourner (ligne exec_node). J'ai essayé : qstat -f 6147968[].service0[0] qstat -f 6147968[0].service0 qstat -f 6147968.service0[0] qstat -f 6147968[0]
Rien en fonctionne :(
Une fois qu'on connait le node, soit aller sur :
http://caparmor-admin2.ifremer.fr/ganglia/?r=hour&s=descending&c= C'est une adresse interne, pour l'extérieur, il faut passer par https://domicile.ifremer.fr/
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Moi je tape qstat -f 6147968\[0\] pour avoir la simu 0 de mon AS et ça marche. Par contre c'est \[\] et pas juste [] (et pas non plus 6147968[]\[0\], il faut enlever les premiers crochets on dirait). Le 07/03/2014 15:10, Eric Chatellier a écrit :
Le 07/03/2014 09:19, Loic GASCHE a écrit :
Salut Eric,
Alors après m'être connecté à caparmor :
qstat -u lgasche pour trouver mes jobs
qstat -f jobID\[numeroSimu\] pour trouver sur quel node caparmor la simu est entrain de tourner (ligne exec_node). J'ai essayé : qstat -f 6147968[].service0[0] qstat -f 6147968[0].service0 qstat -f 6147968.service0[0] qstat -f 6147968[0]
Rien en fonctionne :(
Une fois qu'on connait le node, soit aller sur :
http://caparmor-admin2.ifremer.fr/ganglia/?r=hour&s=descending&c= C'est une adresse interne, pour l'extérieur, il faut passer par https://domicile.ifremer.fr/
Le 07/03/2014 15:17, Loic GASCHE a écrit :
Moi je tape qstat -f 6147968\[0\] pour avoir la simu 0 de mon AS et ça marche. Par contre c'est \[\] et pas juste [] (et pas non plus 6147968[]\[0\], il faut enlever les premiers crochets on dirait). Ok, ca marche.
Par contre, pour voir quelque chose dans la trace d’exécution système, c'est pas évident. Je vois quand même beaucoup d'accès disque pour les equations (c'est en lecture normalement on écrit pas, mais on tentera d'améliorer cà). Il y a aussi la commande : pbs-report -u lgasche -v -a 999999 Date/Time Execution Core Virtual Used Used Queue Suspend Job ID Username Queue Job Name Created Package Host(s) Nodes Memory Memory CPU Time Wall Time Wait Time Time Exit ------- -------- ---------- ---------- ---------------- ------------- ------------ ----- --------- --------- ---------- ---------- ---------- ---------- ----- 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i1n15/4 1 2195452kb 2455716kb 5580 10964 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/3 1 2175792kb 2459320kb 4565 10836 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/4 1 2209388kb 2476748kb 4525 10836 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/5 1 2165344kb 2454736kb 4503 10836 1 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i0n0/6 1 2182992kb 2460724kb 5449 18050 2 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i0n0/7 1 2195964kb 2459364kb 5432 18049 2 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i1n1/0 1 2200808kb 2461436kb 5770 14401 2 0 0 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i1n2/1 1 2196456kb 2403136kb 5868 11915 2 0 0 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n0/4 1 2549720kb 4016976kb 6582 18125 0 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n0/7 1 2598364kb 3996784kb 6607 18123 1 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n2/3 1 3006472kb 3352688kb 3605 5933 1 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n8/0 1 2884356kb 4116032kb 7314 15967 1 0 0 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n2/1*2 1 440248kb 2402628kb 54 172 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/1*2 1 537872kb 2461016kb 54 121 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/2*2 1 400164kb 2447824kb 44 121 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/3*2 1 393732kb 2457420kb 45 121 1 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n0/4 1 2284056kb 3436504kb 4080 10835 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n2/1 1 2421392kb 3000872kb 2183 4002 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n6/2 1 2418424kb 3464444kb 3883 7242 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n6/3 1 2408800kb 3474480kb 3973 7378 2 0 143 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/1 1 2521184kb 4179220kb 7279 15174 1 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/2 1 2834588kb 4174904kb 7329 15835 1 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/3 1 2649524kb 4192048kb 7278 15324 2 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/6 1 2521780kb 4118808kb 7401 15390 2 0 0 Les simulations sont longues, mais on a pas vraiment d'autres piste :( -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
pbs-report ce n'est que pour les simus terminées non (code 143 tuée, code 0 terminée comme il faut) ? On n'avait jamais observé ces différences avant entre le serveur et caparmor ? C'est Benjamin qui avait fait les scripts/interfaces pour lancer ISIS sur caparmor ? Il serait susceptible d'avoir plus d'idées ? Le 07/03/2014 15:42, Eric Chatellier a écrit :
Le 07/03/2014 15:17, Loic GASCHE a écrit :
Moi je tape qstat -f 6147968\[0\] pour avoir la simu 0 de mon AS et ça marche. Par contre c'est \[\] et pas juste [] (et pas non plus 6147968[]\[0\], il faut enlever les premiers crochets on dirait). Ok, ca marche.
Par contre, pour voir quelque chose dans la trace d’exécution système, c'est pas évident.
Je vois quand même beaucoup d'accès disque pour les equations (c'est en lecture normalement on écrit pas, mais on tentera d'améliorer cà).
Il y a aussi la commande : pbs-report -u lgasche -v -a 999999
Date/Time Execution Core Virtual Used Used Queue Suspend Job ID Username Queue Job Name Created Package Host(s) Nodes Memory Memory CPU Time Wall Time Wait Time Time Exit ------- -------- ---------- ---------- ---------------- ------------- ------------ ----- --------- --------- ---------- ---------- ---------- ---------- ----- 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i1n15/4 1 2195452kb 2455716kb 5580 10964 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/3 1 2175792kb 2459320kb 4565 10836 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/4 1 2209388kb 2476748kb 4525 10836 1 0 143 6138816 lgasche isisfish simulation 2014/03/03 08:16 None r5i2n0/5 1 2165344kb 2454736kb 4503 10836 1 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i0n0/6 1 2182992kb 2460724kb 5449 18050 2 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i0n0/7 1 2195964kb 2459364kb 5432 18049 2 0 143 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i1n1/0 1 2200808kb 2461436kb 5770 14401 2 0 0 6139149 lgasche isisfish simulation 2014/03/03 10:48 None r5i1n2/1 1 2196456kb 2403136kb 5868 11915 2 0 0 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n0/4 1 2549720kb 4016976kb 6582 18125 0 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n0/7 1 2598364kb 3996784kb 6607 18123 1 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n2/3 1 3006472kb 3352688kb 3605 5933 1 0 143 6139803 lgasche isisfish simulation 2014/03/03 17:10 None r5i0n8/0 1 2884356kb 4116032kb 7314 15967 1 0 0 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n2/1*2 1 440248kb 2402628kb 54 172 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/1*2 1 537872kb 2461016kb 54 121 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/2*2 1 400164kb 2447824kb 44 121 1 0 143 6140755 lgasche parallel8 simulation 2014/03/04 08:51 None r5i0n6/3*2 1 393732kb 2457420kb 45 121 1 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n0/4 1 2284056kb 3436504kb 4080 10835 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n2/1 1 2421392kb 3000872kb 2183 4002 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n6/2 1 2418424kb 3464444kb 3883 7242 2 0 143 6140783 lgasche isisfish simulation 2014/03/04 09:10 None r5i0n6/3 1 2408800kb 3474480kb 3973 7378 2 0 143 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/1 1 2521184kb 4179220kb 7279 15174 1 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/2 1 2834588kb 4174904kb 7329 15835 1 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/3 1 2649524kb 4192048kb 7278 15324 2 0 0 6147193 lgasche isisfish simulation 2014/03/07 07:20 None r5i0n0/6 1 2521780kb 4118808kb 7401 15390 2 0 0
Les simulations sont longues, mais on a pas vraiment d'autres piste :(
Le 07/03/2014 15:49, Loic GASCHE a écrit :
pbs-report ce n'est que pour les simus terminées non (code 143 tuée, code 0 terminée comme il faut) ? Je suppose. On n'avait jamais observé ces différences avant entre le serveur et caparmor ? Normalement non, c'est sensiblement le même temps. C'est Benjamin qui avait fait les scripts/interfaces pour lancer ISIS sur caparmor ? Il serait susceptible d'avoir plus d'idées ? Non, c'est moi mais c'est pas lié. Le simulation tourne de la même façon en local comme sur caparmor (sauf que caparmor à une architecture qui ralentit ou peu ou beaucoup le fonctionne de chaque simu, alors qu'il ne devrait pas. Caparmor permet juste d'en faire plus en parallèle.
Quoi qu'il en soit, tu en ai ou pour tes simulations ? Tu as possibilité d'utiliser une file avec un long walltime pour faire ton AS dans un temps convenable ou pas ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le walltime je peux l'ajuster comme je veux donc ce n'est plus vraiment un pb. Par contre je ne peux accéder au max qu'à 64 coeurs et seulement le weekend, caparmor est bien chargé en ce moment on dirait, et même la nuit. Si ma seconde AS tourne aussi à peu près correctement je vais tenter de relancer une grosse AS avec un walltime décent, mais la différence de temps de simu entre le serveur et caparmor va bien se faire sentir. Donc il va falloir que je fasse de très gros compromis entre nombre de paramètres et nombre de simus. Le 07/03/2014 15:55, Eric Chatellier a écrit :
Le 07/03/2014 15:49, Loic GASCHE a écrit :
pbs-report ce n'est que pour les simus terminées non (code 143 tuée, code 0 terminée comme il faut) ? Je suppose. On n'avait jamais observé ces différences avant entre le serveur et caparmor ? Normalement non, c'est sensiblement le même temps. C'est Benjamin qui avait fait les scripts/interfaces pour lancer ISIS sur caparmor ? Il serait susceptible d'avoir plus d'idées ? Non, c'est moi mais c'est pas lié. Le simulation tourne de la même façon en local comme sur caparmor (sauf que caparmor à une architecture qui ralentit ou peu ou beaucoup le fonctionne de chaque simu, alors qu'il ne devrait pas. Caparmor permet juste d'en faire plus en parallèle.
Quoi qu'il en soit, tu en ai ou pour tes simulations ? Tu as possibilité d'utiliser une file avec un long walltime pour faire ton AS dans un temps convenable ou pas ?
participants (3)
-
Eric Chatellier -
Loic GASCHE -
Loic.Gasche＠ifremer.fr