Fort d'un réseau de plus de 200 experts EFFSYS peut vous apporter une aide précieuse et de qualité.

Pour toute demande MOA ou MOE, d'AUDITS, détection d'intrusion, n'hésitez pas à nous consulter !

Parmi les domaines d'expertise historiques, l'environnement technique i-serie ( AS/400),

Michel Rubio, associé EFFSYS détaille quelques idées fortes sur l'optimisation de ce serveur :

L’optimisation de performances AS/400 en 2011

L’âge de pierre

Le sujet des performances AS/400(*) a évolué avec le temps. A l’âge de pierre de ce serveur (début des années 90), la problématique des performances était essentiellement centrée autour du tuning système. Les AS/400 n’étaient pas très puissant et optimiser les performances de ces serveurs consistait a optimiser le « tuning » du système. Immanquablement, la CPU n’était pas assez puissante, la mémoire était trop petite et les disques chauffaient !!!

On passait son temps à déshabiller Paul pour habiller Jacques…. Le moindre traitement non planifié comme un Query lancé en pleine journée pouvait mettre à genoux la machine.

On jouait avec les trois fameuses commandes :

• WRKACTJOB pour savoir qui monopolisait la CPU.

• WRKSYSSTS pour savoir comment la mémoire paginait.

• WRKDSKSTS pour savoir comment travaillaient les bras de disques.

IBM nous fournissait des seuils à ne pas dépasser et si c’était le cas on devait organiser différemment l’ordonnancement des travaux ou bien demander au DSI de lancer un (coûteux) upgrade. Quelquefois, on était à la limite de puissance du serveur et l’upgrade était impossible….

Bien sur, les experts utilisaient le Performance Tool, outil qui collectait des données plus précises, mais l’interprétation des résultats était complexe. De plus le niveau de finesse de Performance Tools s’arrêtait au niveau Job. Ces derniers étaient essentiellement de deux types : 5250 pour les interactifs et Batchs pour les traitements de nuits ou de jour.

Les programmeurs utilisaient des techniques précises dans leur programme RPG, pour ne pas trop charger la machine (affichage de sous fichier dynamiques par exemple).

Les exploitants avaient toujours un œil sur le serveur et déclenchaient des alertes dès que le temps de réponse se dégradait.

L’architecture AS/400 bâtie par Frank SOLTIS permettait toutefois qu’un programme utilise toutes les ressources du système s’il était seul à s’exécuter.

Les performances AS/400 aujourd’hui

Des machines plus puissantes

Depuis 20 ans, la puissance des serveurs a considérablement augmenté. Les systèmes sont virtualisés en partitions. Chacune de celle-ci utilisent plusieurs CPUs. En cas de besoin, une partition peut prendre des cycles CPU à une autre. La mémoire réelle fait plusieurs Giga octets. L’espace disque fait souvent plusieurs Tera octets. Les caches mémoire et disques réduisent les accès disques.

Des applications plus complexes

Les connexions à ces serveurs sont de différents types : 5250, WEB, Client-serveur. Le système de fichier natif (PF et LF) est devenu une vraie base de données DB2 avec des contraintes, des triggers, un optimiseur, etc …

Des programmes anciens

Par contre, ce qui n’a pas ou peu changé, ce sont les programmes applicatifs métiers qui s’exécutent sur ces serveurs. Quand bien même on ait 8 CPU sur un serveur AS/400, si le traitement qui s’exécute est un programme batch monolithique non parallélisé, celui sera long et peu performant.

En effet, au lieu d’utiliser l’ensemble des ressources du serveur, il n’en utilise qu’une infime partie souvent à cause d’une conception ancienne et non adaptée aux ressources d’aujourd’hui.

Ceux-ci ont souvent été développés sur des plates-formes ancêtres de l’AS/400 (S36 ou S38). Les personnes qui ont développé ces programmes sont souvent devenus soit chefs de projets ou bien sont partis à la retraite.

Des applications sensibles

A l’époque, documenter ses développements ne paraissait pas une nécessité et les réécrire aujourd’hui parait compliqué. D’autant plus que ces applications gèrent souvent les parties cruciales d’une entreprise, à savoir celles qui sont source de revenu : Gestion Commerciale, Compta, Facturation, Paie, Gestion des crédits etc…

Des informaticiens vieillissants

A ce constat il convient d’ajouter le phénomène suivant : Les programmeurs RPG ont vieillis et disparus en partie. Les nouveaux programmeurs utilisent des AGL de type ADELIA par exemple et codent leurs accès à la base en SQL. Au lieu de suivre une démarche algorithmique classique, le niveau de performance d’un programme devient complètement dépendant du niveau en SQL du programmeur. Bon niveau : Pas de problème. Niveau moyen : Aie Aie Aie ….dans ce cas l’optimiseur DB2 de l’AS/400 fait de son mieux mais quand la requête est tellement mal codée qu’elle passe son temps par exemple à scanner une table de plusieurs millions d’enregistrements, le temps de réponse peut-être de plusieurs dizaines de secondes.

Des équipes structurées à l’ancienne

Enfin les équipes d’informaticiens AS/400 sont souvent structurées à l’ancienne : Peu ou pas d’Ingénieur systèmes (IBM vendait l'AS/400 comme une machine tournant toute seule), une exploitation pilotée en partie par des programmeurs dont très peu savent vraiment comment fonctionne le serveur, une quasi absence de DBA, des intervenant techniques (sur Websphere par exemple) qui n’ont qu’une vision très partielle du serveur...

La conséquence de ceci, c’est que peu de personnes savent utiliser les outils qui pourtant ont été développés et perfectionnés par IBM pour faire du diagnostic de performance (System Director, iSeries Navigator, Performance Tool, iDoctor-Job Watcher, iDoctor PEX Analyzer, Trace SQL DBMON, SQL Plan Caches, Visual Explain, Heap Analyzer ….).

Une méconnaissance des outils

Et lorsque quand bien ces outils sont utilisés, ils sont utilisés comme outil statistique mais pas comme d’outil d’analyse. Qui n’a pas vu ces merveilleuses courbes de charge CPU, très jolies dans des  présentations mais complètement inexploitables pour expliquer pourquoi la CPU est chargée à une certaine heure ? Au mieux, il est possible d'incriminer un traitement (donc souvent un programmeur) mais personne n'est capable de lui expliquer ce qui ne va pas.

De leurs cotés, les équipes de développement tentent bien d’optimiser leurs traitements mais sont souvent inefficaces. En effet elles optimisent une partie du code qui marchait bien et peuvent gagner 3 dixièmes de secondes là ou il aurait fallu gagner 10 secondes. Des précisions techniques sont demandées aux exploitants mais ceux-ci sont bien incapables de les donner.

Un aveu d’impuissance

En réunion sur ces sujets, tout le monde s'exprime en ayant une idée sur la question, mais la réunion se termine souvent , non pas par un plan d’action précis, mais par un aveu d’impuissance.

Le chaînon manquant

Ce qui manque aux deux équipes pour traiter efficacement ce type de problème a un nom : Le diagnostic.

Avant de bâtir une solution il faut d’abord diagnostiquer avec méthode et précision ce qui se passe.

Il faut savoir par exemple répondre en détail aux questions suivantes :

• Pourquoi le temps de traitement est long ?

• Ou perd-on du temps ?

• Quelle partie du code charge la CPU ?

• Pourquoi l’optimiseur DB2 a -t il décidé de reconstruire un index dynamiquement ?

• Pourquoi le programme X balaie t il la table Y séquentiellement, etc. ….

Le choix du bon outil

Avec les outils standards IBM listés plus haut, il est possible de faire un diagnostic précis de ce qui se passe dans le système ou dans un traitement. Il faut par contre utiliser les bons outils en fonction de la problématique à résoudre : Trace SQL si on veut optimiser les accès DB2, Trace PEX si on veut décomposer le temps de traitement d’un job et le ventiler par programme ou sous programmes, IDoctor Job Watcher si on veut isoler les problèmes de verrouillages, System Director si on veut diagnostiquer des problèmes de configuration de partitions…..

Conclusion

Aujourd’hui, c'est autour des applications qu'il faut travailler l'optimisation, plutôt que le tuning du système comme par le passé…

Méthodologie EFFSYS

L’approche générale doit être de type Top / Down.

Identification

Face à un problème de performance identifié, il convient d’abord de comprendre le problème tel qu’il est exposé par l’exploitant, l’utilisateur ou parfois le programmeur. S’il y en a plusieurs, il faut les prioriser.

Analyse Setup Système

Il faut ensuite reproduire (ou essayer de tracker) le problème tout en se mettant en mode surveillance.

Au moment du problème, il convient de vérifier la charge générale du serveur (charge CPU, mémoire, disques, jobs) et en contrôler son setup (Taille des partitions, Puissance CPU, taille Mémoire, Nombre de disques, Espace disponible, valeurs Systèmes, Job Descriptions, Sub-System Description etc. …. ).

Trace

En parallèle, il faut choisir l’outil qui va bien en fonction de la problématique à traiter (voir ci-dessus).

Ensuite il s'agit de lancer le/les outils de collection avec un paramétrage adapté. Ainsi par exemple on peut ne tracer que les requêtes SQL d’un job précis, ou bien on peut ventiler le temps d’exécution que sur un seul job.

Analyse des résultats

Cette phase est la plus complexe. Elle consiste pour l’expert performance, sur la base des données collectées, à comprendre ce qui se passe et surtout à traduire ce qu’il voit dans les collectes en quelque chose qui soit compréhensible par les exploitants, les développeurs ou le DSI.

Par exemple : Le temps de traitement est long car lorsque que telle requête SQL démarre, l’optimiseur DB2 ne trouvant pas en base d’index pour l’aider, décide de recréer un index dynamiquement.

Une fois que le diagnostic précis est fait sur la compréhension d'un temps trop long , alors seulement on peut entrer dans la phase de recherche de solutions techniques pour remédier au problème.

Recherche et proposition de solution

L’expert EFFSYS propose des solutions techniques qui sont validées ou pas (en fonction d’autres critères parfois comme la sécurité ou l’intégrité des données) par l’équipe client. Parfois, le diagnostic précis étant fait, les équipes du client proposent elles mêmes des solutions. Il nous est arrivé qu’un programmeur nous dise : On perd du temps dans une partie du traitement dans un module qui ne sert plus à rien aujourd’hui par exemple.

Idéalement, l’expert EFFSYS doit pouvoir aussi estimer le temps qui sera gagné par telle ou telle optimisation.

Contrôle de l’impact de l’optimisation

La dernière phase, et pas de la moindre importante, consiste, une fois l’optimisation mise en place à mesurer le traitement à optimiser (toujours avec les outils IBM standards listés lus haut), pour valider que l’optimisation proposée est bien positive.

En général ce type de mission se déroule en 2 ou 3 semaines, en fonction du nombre de problèmes de performance à traiter.

(*) On emploiera dans ce document le terme générique AS/400 pour parler des : AS/400, iSeries, i5 et « IBM i ».