Changement de machine : retour d’expérience

Un de nos clients a décidé de passer son infrastructure informatique sur le cloud.

Rien à redire à cela, derrière ce sont toujours des Powers qui répondront aux requêtes. Par contre cela a permis de faire quelques tests de performances avec des résultats étonnants.

Le client est passé d’une partition S824 à une partition S922.

  • Même capacité mémoire,
  • même capacité disque,
  • même fraction processeur.

Seul le processeur a changé : passage d’un P8 S824 à un P9 S922.

L’application test consistait en une chaine de 160 programmes RPGLE, SQLRPGLE, 30 programmes CLLE, 80 PF multi-formats et tables SQL en sortie et une vingtaine de PF en entrée.

L’application contient des accès natifs à la base de données, des requêtes SQL…

mais n’est pas en écriture modulaire, pas de programmes de services, de répertoire de liage, de groupes d’activation dédiés,…

Selon le paramétrage, on accède soit à 10 millions d’enregistrements en entrée (V10) soit à plus de 200 millions d’enregistrements en entrée (V200) donc 20 fois plus.

Cette application a été utilisée par le passé sur des P7 (724), P8 (824) avec à chaque fois des gains dans les temps d’exécution.

L’opération est simple : changement de machine et passage à une gamme processeur plus récent, MAIS passage d’un S824 à un S922.

Données de référence :Sur un P8/S824 la V10 dure 21 minutes. (moyenne sur 7 mois avec plusieurs lancés sur le même mois et des valeurs de temps entre 20 et 22 minutes).

Sur un P8/824 la V200 dure 7 heures (420 minutes, la règles de proportionnalité nous donne 420/20 : 21

Compte tenu de la durée des traitements, seule la V10 a été lancée pour valider les gains de temps.

Tests avec même fraction processeur (0.3), même mémoire, même capacité disque MAIS passage de disques de 133 Go à des disque de 260 Go.

– Temps moyen S922 : 41 minutes. (3 tests avec l’application seule sur la machine, temps identique à +/- 1 minute)

Test avec fraction processeur à 1, mémoire principale multipliée par 4 :

– Temps moyen S922 : 40 minutes. (3 tests avec l’application seule sur la machine, temps identique à +/- 1 minute)

Test avec multiplication du nombre de contrôleurs disque par 3 :

– Temps moyen inchangé

Test remplacement des disques de 260 Go par des disques de 133 Go :

– Temps moyen inchangé

D’après vous quel était l’élément pénalisant ?

Le processeur. Ou plutôt, la vitesse d’horloge de celui-ci.

Sur le S824, le processeur était cadencé à 4.15 Ghz.

Sur le S922, le processeur était cadencé à 2.275 GHz.

Sur un traitement interactif, cette donnée est négligeable et la différence de temps insignifiante.

Par contre sur du batch, le résultat peut être catastrophique.

Si on reporte sur le traitement V200 les résultats du V10, on obtient une durée qui passe de 7h à plus de 13h !

Heureusement (ou presque) en passant la fréquence à 3.9 GHz le temps moyen s’est amélioré :

– Temps moyen : 25 minutes.

Aucun gain mais moins de pertes.

Conclusion : Il faut toujours faire attention aux petits détails lors des changements de machine.

, Fréquence des IPL, complément

Fréquences des IPL, complément

La precaunistation d’IBM et de faire IPL à chaque appliction de PTFs
pour ne pas perdre le chache SQL par exemple

Mais, il y a quand même un point inviter à en faire plus, c’est la mémoire qui est perdu sur certain travaux

Vous avez une vue QSYS2.SYSTMPSTG qui permet

La vue SYSTMPSTG contient une ligne pour chaque espace de stockage temporaire qui contient une quantité de stockage temporaire sur le système.
Le stockage temporaire est un stockage qui ne persiste pas lors d’un redémarrage du système d’exploitation.
on parle de « BUCKET »

Voici une requête qui montre l’espace perdu par les jobs terminés

SELECT ‘Perdu’ as memoire , sum(BUCKET_CURRENT_SIZE) as taille
FROM qsys2.SYSTMPSTG
WHERE JOB_STATUS = ‘*ENDED’

le détail

SELECT JOB_NAME, JOB_USER_NAME, JOB_NUMBER , BUCKET_CURRENT_SIZE
FROM qsys2.SYSTMPSTG
WHERE JOB_STATUS = ‘*ENDED’
order by BUCKET_CURRENT_SIZE desc

Voici une requête qui donne la taille totale

SELECT ‘Total’ as memoire , sum(BUCKET_CURRENT_SIZE) as taille
FROM qsys2.SYSTMPSTG ;

Vous pouvez faire un ratio et si il est important 10 % par exemple

Vous devrez faire une IPL, pour récupérer cette mémoire

Vue dans Navigator For I

Ps:
A ce jour il n’y a pas d’autres solutions pour récupérer cette mémoire