November 2009 - Isis-fish-devel - mailman.cloud.codelutin.com

[Fwd: Re: CR du 22 octobre]
by Jean Couteau 04 Nov '09

04 Nov '09

2 1

Test des jobs multiples PSB
by Eric Chatellier 04 Nov '09

04 Nov '09

Bonjour, Voici le rapport concernant les tests des jobs multiples effectués sur caparmor avec tina. -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com Test avec multijob PBS ====================== Test multijobs -------------- Tests avec 100, 500, 1000 simulations. C'était des simulations sur 1 ans, mais tina a pu suivre que PBS ne plantait pas dès la soumissions de 1000 jobs. Les simulations tournent 16 par 16. Il ne les fait pas dans l'ordre. On peut lancer plusieurs multijobs en meme temps, ils sont mis en pause. Elle trouvait quand même le niveau de logs de PBS (coté administration) trop fort, et (si j'ai bien compris), si on s'amusait a soumettre 100000 jobs par cette méthode, ca pourrait planter aussi. Elle demande des infos de son coté. Queue de simulations -------------------- Apparement certains utilisateurs utilisant "qstat" (liste des simulations en cours et en attente) étaient un petit peu gêné de voir 500 simulations en attente pour isis fish :) Le multijob apparait comme un job unique dans la file. Performances ------------ Elle a lu le document de test profiling de caparmor, et a retenu qu'on pouvait atteindre 95% en utilisant une base mémoire. Avec une jvm 32 bits, la limite de 2go peut être vite atteinte. Avec une jvm 64 bits la limite est supérieure, mais les performances sont moins bonnes. Utilité ------- Ce mode de lancement est bien adapté aux plan d'analyses independant, et aux analyses de sensibilité. Isis envoie toutes les simulations et demande le lancement de toutes les simulations une seule fois. Il faut environs 40 minutes pour envoyer 500 simulations. Les 500 simulations ont tourné en 5 heures.

1 0

Test de performance d'isis-fish sur caparmor
by Eric Chatellier 04 Nov '09

04 Nov '09

Bonjour, Voici les résultats des tests de performance d'IsisFish sur caparmor. La mise à jour effectuée par IsisFish 3.3 "semble" à elle seule améliorer les performances sur caparmor : - IsisFish-3.2 : 64% de temps CPU - IsisFish-3.3 : 85% de temps CPU Les 15% de temps restant étant bien utilisé par les accès disques: - zip de simulation - base de données résultats - exports - zip de résultats Cordialement. -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com Test de profiling caparmor ========================== Description ----------- Carparmor : jdk-1.6.0.13 (x86), linux 2.6.16.60 (amd64) Local : jdk-1.6.0.16 (x86), linux 2.6.30 (amd64) Les tests caparmor ont tous été fait dans un noeud caparmor: qsub -I -q parallel8 -l select=1:ncpus=8 Test témoin ----------- Test effectué sur la base Golfe de Gascogne, avec tous les résultats sélectionné, tous les exports selectionnés. Local: real 11m49.791s user 11m34.471s sys 0m26.690s Caparmor: real 10m27.015s user 8m50.865s sys 0m38.374s Caparmor test 2 : real 9m59.770s user 8m42.357s sys 0m38.202s Mise à jour de java sur caparmor -------------------------------- Passage au jdk-1.6.0.16. Caparmor: real 9m34.355s user 8m51.889s sys 0m36.402s Caparmor test 2 : real 10m14.276s user 8m31.252s sys 0m37.202s Sensiblement la même chose. Test sans exports ----------------- Pas d'export. Tous les résultats possible sélectionné. Tous les logs en "error". Création du zip final. Caparmor: real 9m45.530s user 8m55.177s sys 0m40.087s Caparmor test 2 : real 10m44.570s user 8m42.845s sys 0m38.494s Sans la création du zip de resultat ----------------------------------- Pas d'export. Tous les résultats possible selectionné. Tous les logs en "error". Pas de creation du zip de fin. Caparmor : real 9m11.346s user 8m43.661s sys 0m36.758s Caparmor test 2 : real 10m7.875s user 8m25.776s sys 0m36.938s Seul les exports en écriture à la fin de la simulation ------------------------------------------------------ Base mémoire. Tous les résultats possible séléctionné. Export des résultats. Tous les logs en "error". Pas de creation du zip de résultats. Caparmor : real 9m25.109s user 9m49.869s sys 0m24.310s Caparmor test 2 : real 9m32.726s user 9m58.029s sys 0m23.917s Sans aucune écriture disque --------------------------- Base mémoire. Tous les résultats possible séléctionné. Pas d'export. Tous les logs en "error". Pas de creation du zip de résultats. Caparmor: real 9m36.553s user 9m36.592s sys 0m23.313s Caparmor test 2 : real 9m10.363s user 10m6.166s sys 0m24.294s Seule la base en mémoire ------------------------ Dans ce test, tous les acces disque ont été conservé (zip, export, zip resultat), exeptée la base de données résultat. Caparmor: real 9m39.021s user 9m37.508s sys 0m23.045s Caparmor test 2 : real 9m32.731s user 9m26.603s sys 0m23.297s Tests supplémentaires --------------------- Tous ces test ont révélés, un temps d'acces disque dû entre autre à la base de données, cependant, je ne suis jamais parvenu à reproduire les performances à 50% obtenu pendant la réunion. Tous les tests précendents ont été effectués sur la version 3.3.0 de IsisFish qui contient des versions plus récentes de quelques librairies. Test isis-fish-3.2.0.9 ~~~~~~~~~~~~~~~~~~~~~~ Caparmor: real 11m39.838s user 7m30.392s sys 0m27.446s Caparmor test 2: real 11m20.282s user 7m41.549s sys 0m27.146s On retrouve la perte de performance rencontrée lors de la réunion. Les tests de non regression ont été effectués entre isisfish 3.1 et 3.3, et les résultats sont bien toujours identiques. Test isis-fish-3.3 avec h2-1.1.119 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ real 11m9.378s user 7m55.218s sys 0m28.058s Test isis-fish-3.3 avec hibernate-3.3.1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ real 9m58.471s user 8m0.890s sys 0m38.202s La mise a jour apporté par hibernate 3.3.2 semble améliorer les performances. Conclusion ---------- Les résultats des tests ont bien montrer que les écritures disques reduisaient les performance des jobs caparmor. Surtout les accès disques "en cours" de simulations dûs à la base de données. Performance: - isisfish-3.2 : ~ 64% - isisfish-3.3 : ~ 85% - isisfish-3.3 (avec base mémoire) : ~ 95% - isisfish-3.3 (sans ecriture) : ~ 105% Cependant, les optimisations envisageables ne sont pas évidentes: - l'import du zip initial est nécéssaire (données de simulation) - la base de résultat (pour ne pas consomer trop d'espace mémoire en cours de simulation) - les exports (les résultats de simulations) - le zip final de résultat (pour récupération des résultats)

3 7

[Fwd: (pas de sujet)]
by Eric Chatellier 03 Nov '09

03 Nov '09

-------- Message original -------- http://asserttrue.blogspot.com/2008/11/why-64-bit-java-is-slow.html To get more heap than that means either moving to a 64-bit JVM or using Terracotta. The latter (if you haven't heard of it) is a shared-memory JVM clustering technology that essentially gives you unlimited heap space. Or should I say, heap space is limited only by the amount of disk space. Terracotta pages out to disk as necessary. A good explanation of how that works is given here. -- =================================================== Tina Odaka RIC - IDM - IFREMER Tel: +33 (0)2 98 22 41 85 Fax: +33 (0)2 98 22 45 46 email: Tina.Odaka(a)ifremer.fr http://www.ifremer.fr/pcim ================================================== -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0

Creation d'un job PBS pour 3000 jobs de simulation
by Benjamin POUSSIN 03 Nov '09

03 Nov '09

----- Message Transféré ----- Date: Thu, 22 Oct 2009 14:43:23 +0200 De: Tina.Odaka(a)ifremer.fr À: poussin(a)codelutin.com Sujet: -J range Declares that this job is an array job. Sets job's array attribute to TRUE. The argument range identi- fies the integers greater than or equal to zero that are associated with the subjobs of the array. range is specified in the form X-Y[:Z] where X is the first index, Y is the upper bound on the indices and Z is the stepping factor. For example, 2-7:2 will produce indices of 2, 4, and 6. If Z is not specified, it is taken to be 1. service4>1015% cat toto echo $PBS_ARRAYID >out.$PBS_ARRAYID sleep 100 service4>1016% qsub -J 1:10 -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii

2 2