Bonjour, réponses dans le mail On 02/26/14 15:55, Loic.Gasche@ifremer.fr wrote:
Bonjour,
Voici plusieurs jours que j'essaye de joindre Tina au sujet d'un job que essayons de lancer sur caparmor.
elle est absente
C'est une analyse de sensibilité de grande taille lancée avec le simulateur ISIS-Fish, qui nécessiterait un nombre important de coeurs.
Nous avons dernièrement fait évoluer le modèle afin d'écrire un minimum d'informations, et de préférence dans la ram, afin de limiter les accès disques pour gagner du temps de simulation.
J'ai procédé la semaine dernière à des tests de ce modèle sur caparmor en faisant tourner de petites analyses de sensibilité. Tout s'est bien déroulé avec des temps de simulation qui sont passés sous la barre des 3 heures pour une simulation.
J'ai donc lancé la grosse AS que nous souhaitions réaliser jeudi soir, en faisant un mail à Tina pour le lui indiquer afin que nous puissions regarder le lendemain si tout tournait correctement et éventuellement allouer plus de coeurs à ce job pour le weekend.
Il m'a semblé vendredi que les simulations ne tournaient pas correctement et étaient tuées par caparmor car elles n'étaient pas terminées au bout de 3 heures.
Ces simulations sont pourtant plus simples que celles testées avant, et qui tournaient en moins de 3 heures.
N'étant pas un grand expert de caparmor je cherchais à obtenir des informations sur ce qui a pu se passer :
- les simus ont-elles bien été tuées en raison de leur durée > à 3 heures (nous utilisons la queue isisfish, par le passé Tina avait augmenté le temps max par simu à 5 heures mais l'avait baissé à 3 dernièrement je crois) ?
3 heures en nominal mais vous pouvez l'augmenter par une directive PBS #PBS -l walltime=05:00:00 ce qui correspond à 5 heures dans cet exemple
- nous avons normalement drastiquement réduit les écritures sur le disque, pourtant notre temps de simulation n'a que peu diminué (on espérait descendre largement en dessous de 3 heures), serait-il possible de savoir d'où vient l'essentiel des temps de simulation et si beaucoup d'accès disques ont encore lieu ?
possible mais j'ai des doutes. Vous connaissez le code et pourrez surement mieux que moi identifier des points particuliers lors de son exécution.
- est-il possible qu'une même simulation prenne plus de temps pour tourner quand elle appartient à un job de grande taille plutôt qu'à un job contenant uniquement quelques simulations ? Caparmor a-t-il sa propre manière de calculer les temps de simulation ?
La parallélisation peut ne pas conduire au résultat escompté. Au mieux (théoriquement), on obtient le temps d'un job sequentiel divisé par le nombre de coeurs. Mais c'est théorique. Il y a les échanges entre les noeuds ainsi que la manière dont la parallélisation est gérée. Dans le cas au pire, la parallélisation n'apporte aucune amélioration en temps écoulé. Votre processus est en java n'est-ce pas ? Utilisez vous des softs de mesure et tracé de performance (je ne connais pas et n'ai pas assez utilisé java pour recourir à ce type d'outil, mais vous utilisez peut-être déjà). C'est peut-être un point à regarder car cela donne parfois des indications sur le temps passé par fonction ou le nombre d'appels.
- ces temps de simulation élevés peuvent-ils être expliqués par une surcharge de caparmor à ce moment là ?
Votre job tourne sur des noeuds qui vous sont attribués et, sauf cas particulier comme le sequentiel ou un nombre de coeurs différent d'un multiple de 8, que vous ne partagez pas. Il peut aussi y avoir une charge disque très ponctuelle, certes, mais si sur 2 ou 3 runs vous avez le même résultat, c'est plus probablement au niveau du code que vous trouverez des explications.
- Dans l'hypothèse où ces soucis sont causés par caparmor et non par le modèle et qu'il faut effectivement 3 à 4 heures pour faire une simulation, serait-il possible d'augmenter le temps alloué à chaque simulation d'une heure ?
action sur le walltime. Si vous avez encore un problème à 3h malgré cela, contactez moi Cordialement, Denis
Cordialement.
Loïc Gasche
----- Message transféré de Loic.Gasche@ifremer.fr ----- Date : Fri, 21 Feb 2014 17:46:01 +0100 De : Loic GASCHE <Loic.Gasche@ifremer.fr> Objet : error 143 : ISIS jobs killed because wall time is reached ? À : ODAKA <Tina.Odaka@ifremer.fr>
Hi Tina,
I thought that my simulations were running well but could not check in ISIS because the interface had crashed.
However I did a pbs-report and it appears that all my simulations have exited with code 143. I think this means that they have been killed ?
It seems that the wall time for my simulations is over 10800, is it the reason why they were killed (if they were) ?
I ran tests on caparmor with similar parameters before running my big SA and everything ran well, and in less than three hours. I may even have less rules than in my tests so simulation time should be even lower.
Besides we are writing files in the ram and keep only the 13 last timeSteps, which should help reduce time too.
Do you see any reason why we could have reached the maximum time for this SA and not for the others ?
Loïc
----- Fin du message transféré -----