Précédent   Forum des professionnels en informatique > Systèmes > Autres systèmes > z/OS
z/OS Forum d'entraide sur z/OS et MVS (Multiple Virtual Storage), les systèmes d'exploitation des ordinateurs « mainframes » IBM : JCL, Tso, Ispf, Vsam, Racf, SMS, Cics, Ims, OPC, Ca-7, Control-M, Dialog Manager ...
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
Vieux 19/10/2009, 00h42   #1
Invité de passage
 
Inscription : décembre 2008
Messages : 3
Détails du profil
Informations forums :
Inscription : décembre 2008
Messages : 3
Points : 0
Points : 0
Par défaut Java sous USS

Bonjour,

Je travaille sur un projet qui consiste à faire exécuter des programmes Java sur la couche USS sur Z/os. L'éxécution ce fait à partir d'un JCL (exe du pgm BPXBATCH), cela marche bien sauf que nous rencontons des pbs de performances. En effet, on constate une consommation importante de CPU et des temps de traitements assez long par rapport au monde Windows ou unix.

Avez-vous un retour d'expérience dans ce domaine, y-a-t-il des optimisations à faire (au niveau de la JVM). je sais qu'il existe des processeurs dédiés ZAAP pour les traitements java mais nous n'en avons pas sur notre site.

Merci d'avance.
chalys est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 19/10/2009, 15h01   #2
Membre habitué
 
Inscription : janvier 2008
Messages : 120
Détails du profil
Informations forums :
Inscription : janvier 2008
Messages : 120
Points : 141
Points : 141
Bonjour Chalys,

je ne vais pas être très précise, mais dans mon souvenir (expérience dans mon ancienne boite), la mise en place d'appli Java sous Z/os avait nécessité beaucoup de travail de notre ingénieur système en ce qui concerne les performances (y compris de conso mémoire) pour arriver aux bons réglages.
En vrac parce que ça fait quelques années, nous avions du essuyer des problèmes au niveau du Driver DB2 ODBC, de la mémoire occupée par la JVM et l'appli (mais peut être que le garbage collector est aujourd'hui plus performant), et des problèmes de perf plus standard Z/OS avec des actions en montée en lla systématique et autres trucs.
Je te conseillerais de passer tes traitements dejà sous des outils standard Z/os du genre Strobe et/ou du type Mainview Z/os/USS ou TMON. Je pense que cela te donnera quelques bonnes orientations sur ton soucis.
USS dans ses bases est assis sur l'architecture Z/os, utiliser dans un premier temps les outils standard te permettra de dégrossir tout ça.
Nous n'avions pas non plus de processeurs dédiés ZAAP et pourtant, avec je l'avoue pas mal d'huile de coude nous sommes arrivé à un système aux perf très acceptables.

Enfin, il y a pas mal de RedBook IBM très intéressants sur cet environnement USS , je te conseillerais d'y jeter un œil.
xfanx est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 22/10/2009, 12h27   #3
Invité de passage
 
Inscription : décembre 2008
Messages : 3
Détails du profil
Informations forums :
Inscription : décembre 2008
Messages : 3
Points : 0
Points : 0
Merci pour cette réponse, malheuresement nous ne disposons pas de ces outils sur nos sites, notre équipe système doit faire des recherches complémentaires mais en ce moment ils sont pas trop dispo (en pleine migration).
chalys est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 24/10/2009, 07h07   #4
Membre expérimenté
 
Inscription : mai 2005
Messages : 414
Détails du profil
Informations forums :
Inscription : mai 2005
Messages : 414
Points : 589
Points : 589
de mémoire les Zaaps sont simplement des processeurs standards z10 qui sont dédiés aux traitements JAVA, ce qui allege la facturation puisque IBM reduit le cout sur ses traitements. mais pour moi ce sont des processeurs standards

Mais le fait d'isoler par WLM les traitements Java permet d'avoir des perfs un peu meilleur.

Concernant l'optimisation, la JVM doit être forcée en mémoire réelle déjà.
Verifier le temps de passage du GC sur les différentes étapes (marquage, nettoyage, compactage.
Par défaut, le compactage bloque les threads donc vérifier qu'il passe pas trop souvent.

Effectivement, les drivers JDBC sont parfois capricieux, globalement, souvent le DB2 est sur la LPAR z/OS où tourne le batch et nous avions de meilleurs résultats avec les drivers de type 2 qu'avec ceux de type 4.

Et apres effectivement, il faut creuser. nous utilisions Introscope de Wily (racheté par CA)
gregory.broissard est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 28/10/2009, 00h15   #5
Invité de passage
 
Inscription : décembre 2008
Messages : 3
Détails du profil
Informations forums :
Inscription : décembre 2008
Messages : 3
Points : 0
Points : 0
Merci pour ses infos gregory.broissard par contre comment doit procéder pour forcer la JVM en mémoire réelle ?
chalys est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +1. Il est actuellement 08h39.


 
 
 
 
Partenaires

Hébergement Web