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é.
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 Adobe Firefly, l’IA générative dédiée aux équipes créatives
Depuis plus d’une décennie, Adobe exploite l’intelligence artificielle (IA) pour proposer des solutions toujours plus performantes et innovantes aux équipes créatives. Comment le nouveau moteur d’IA générative Adobe Firefly permet-il aux entreprises de développer leurs capacités créatives et de tirer, dès à présent, tout le profit de l'IA générative ?
