> Tech > Extensibilité de Java pour l’iSeries, 1ère partie

Extensibilité de Java pour l’iSeries, 1ère partie

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Rick Peterson - Mis en ligne le 01/10/02
Dans cet article en deux parties, je vais décrire quelques techniques qui vous permettront de régler des applications ou des systèmes Java pour une meilleure évolutivité sur les systèmes iSeries.

Les analystes de performances posent souvent la question suivante : « Comment puis-je rendre mon système plus extensible ? » En effet, les développeurs et testeurs d'applications obtiennent fréquemment des niveaux de performances acceptables lorsqu'ils testent une application sur un petit système, mais constatent une nette dégradation dès qu'ils la portent sur un système client de plus grande taille. L'insuffisance des performances se manifeste alors de plusieurs façons : débit plus faible que prévu, temps de réponse élevés et taux d'utilisation de la CPU inférieur aux prévisions. Certains problèmes d'évolutivité peuvent aussi se manifester par une utilisation de la CPU supérieure aux prévisions, même si c'est plus rare.

Dans ce premier papier, j'explique comment régler votre iSeries pour obtenir une performance Java maximale, et j'explore quelques possibilités de réglage de la base de données, là  aussi pour une meilleure évolutivité.

Extensibilité de Java pour l’iSeries, 1ère partie

Pour une bonne évolutivité, il faut
d’abord se concentrer sur le réglage du
système. Cette opération est en général la même pour des applications
Java que pour des applications classiques.
Il faut planifier avec soin la capacité
pour que le système donne satisfaction
en temps de réponse et en
débit.

Définir le maximum de jobs
actifs
. Les premiers ajustements système
à  envisager concernent les pools
de stockage de l’iSeries. Ils ne se bornent
pas à  stocker des informations – ils exécutent aussi des fonctions de
contrôle de job et de thread. Une valeur
appelée MAXACT (Maximum
Active Jobs) est associée à  chaque
pool. Quel que soit le nombre de soussystèmes
qui se partagent le pool,
MAXACT limite le nombre total de
threads pouvant résider dans le pool et
s’y exécuter. A noter que cette valeur limite
les threads, pas les jobs.

En principe, les applications Java
fonctionnent avec de multiples threads
dans un job. Il est facile de commettre
l’erreur consistant à  donner une valeur
trop basse à  MAXACT ; les choses se gâteront
peut-être quand le sous-système
de stockage existant verra surgir
soudain de nombreux nouveaux
threads Java provenant de nouvelles
applications Java. On pourra constater
les symptômes suivants :

• Des défaillances inexpliquées des applications.
Si l’on donne à  MAXACT
une valeur extrêmement basse, de 1
par exemple, Java risque de ne pas
fonctionner du tout, sans même daigner
s’en expliquer par un message.

• Des suspensions et des ralentissements
mystérieux du système. Si l’on
donne à  MAXACT une valeur trop
basse, le système fonctionnera peutêtre
mais il enverra aussi consciencieusement
des threads dans un fichier
temporaire connu comme «
inéligible », parce que c’est ce que
MAXACT lui ordonne. Ces threads
restent dans l’état inéligible jusqu’à 
ce qu’ils bondissent en haut de la
liste d’attente ; puis un autre thread
prend l’état inéligible. Résultat : Des états d’attente inutiles et une grande activité fébrile
et improductive du système. Il sera parfois même
impossible de « hisser » une CPU à  un niveau d’utilisation
supérieur et les temps de réponse s’allongeront
nettement.

Ces symptômes peuvent résulter d’une mise à  niveau.
Si vous venez d’acquérir une nouvelle machine
et si elle fonctionne plus lentement que prévu, il se
peut que vous utilisiez des valeurs MAXACT sous-dimensionnées
pour les pools de stockage.

On peut utiliser la commande WRKSYSSTS (Work
with System Status) avec des niveaux d’assistance *INTERMEDIATE
ou *ADVANCED pour déterminer si le
système place des threads en état « inéligible ».
Emettez simplement la commande WRKSYSSTS (si
vous êtes au niveau d’assistance *INTERMEDIATE, appuyez
sur PF11) et vérifiez si Act->Inel est autre que
zéro. Assurez-vous que les autres transitions, particulièrement
Act->Wait, sont dans le cadre des directives
du chapitre 14 du manuel iSeries OS/400 Work
Management V4R4 (SC41-5306), disponible à 
http://www.iseriesnetwork.com/resources/
isndocfinder.

Vérifiez que la valeur MAXACT de chaque pool de
stockage a une valeur suffisamment élevée. Vous pouvez
utiliser la commande CHGSHRPOOL (Change
Shared Storage Pool) pour changer le nombre de
theads pouvant être actifs dans le pool de stockage. Emettez la commande suivante :

CHGSHRPOOL ACTLVL(newmax)

Notons que des sous-systèmes multiples peuvent
partager un pool. On peut aussi utiliser WRKSYSSTS
pour changer la valeur MAXACT d'un pool de stockage
particulier. Il suffit de changer la colonne
Max Active pour le pool de stockage approprié.

Téléchargez cette ressource

Guide de cybersécurité en milieu sensible

Guide de cybersécurité en milieu sensible

Sur fond de vulnérabilités en tout genre, les établissements hospitaliers, pharmacies, laboratoires et autres structures de soin font face à des vagues incessantes de cyberattaques. L’objectif de ce livre blanc est de permettre aux responsables informatiques ainsi qu’à l’écosystème des sous-traitants et prestataires du secteur médical de se plonger dans un état de l’art de la cybersécurité des établissements de santé. Et de faire face à la menace.

Tech - Par iTPro.fr - Publié le 24 juin 2010