IBM fournit plusieurs outils de collecte et d’analyse de données de performances iSeries, tels que iDoctor, Job Watcher et PEX analyzer, qui permettent d’isoler et de corriger les problèmes de performances. (Pour plus d’informations sur ces outils, allez à www-912.ibm.com/i_dir/idoctor.nsf. Pour des informations sur Job Watcher, voir www.redbooks.ibm.com/abstracts/SG246474.htlm?Open.
Identifier les problèmes de performances

Selon la situation, vous pouvez recourir à différentes techniques pour détecter si votre système connaît ou non des problèmes et pour déterminer l’action corrective pertinente.
Analyser la contention de CPU. Utilisez Job Watcher pour visualiser le temps de CPU utilisé par chaque priorité de job. Utilisez le Job Watcher Query Definition sur le Server Side TDE (task ID) pour examiner la priorité originale et courante d’un job. Le flag PRICHG du fichier TDE indique que la priorité du job a changé dans l’intervalle courant. Les causes peuvent en être diverses : algorithmes DPS (dynamic priority scheduling), ajustements des priorités de conflits seize/lock, ou redéfinition de la priorité DPS après une longue attente. Le flag est peut-être activé, mais les priorités originales et courantes du job sont les mêmes parce que la priorité est revenue à l’original dans l’intervalle.
Priorité de job pour la CPU. Quand la charge du système est dans la fourchette normale, la CPU n’est pas entièrement utilisée et chaque job du système obtient le temps de CPU dont il a besoin, indépendamment de sa priorité. Cela ne signifie pas que chaque job obtient la CPU dès qu’il en a besoin, mais que chaque job obtient ce dont il a besoin dans un délai raisonnable. Dans ce cas, la mise en file d’attente de la CPU a un effet prévisible et acceptable sur le temps de réponse des transactions.
Que se passe-t-il quand l’accroissement de la charge de travail conduit la CPU à 100 % d’utilisation ? Chaque job du système obtient encore le temps de CPU dont il a besoin, mais beaucoup d’entre eux souffriront de délais bien plus longs et inacceptables à cause d’un plus haut niveau de file d’attente de la CPU, comme c’est le cas de Company aBc.
Company aBc utilise la fonction DPS du système qui, selon IBM, présente les quatre avantages suivants :
1. Aucun job ou ensemble de jobs ne monopolisera la CPU.
2. Les jobs de faible priorité, du genre batch, auront une chance de progresser.
3. Les jobs qui utilisent trop de ressources seront pénalisés par la réduction de leur priorité.
4. Les temps de réponse/débit des jobs se comporteront à bien des égards comme dans une planification à priorité fixe.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.