Lenteur immense sur le système

**JauB** · 28/05/2008, 18h39

Bonjour,
on a un progiciel développé en COBOL tourant sur une machine I5. Ces derniers jours on a constaté qu'il y a une lenteur immense, mais on ne sait pas c'est dû à quoi!!
y a t il des commandes pour vérifier d'où peut venir ce genre de problème?
N.B: on a une autre application qui fait des éditions à partir de la même base de ce progiciel en utilisant du SQL. Je ne sais pas si le SQL n'est pas optimisé sur l'AS400 ou quoi!
Une piste les amis (es)

**BALLAT** · 28/05/2008, 19h22

Bonsoir,

1er Niveau
Déjà tu peux commencer par regarder les travaux actif : WRKACTJOB
Tu mets ton curseur sur la colonne "% UC" et faire la touche de fonction F16 pour trier les travaux actifs.
Faire F5 de temps en temps pour reactualiser
Tu prends donc le premier de ta liste (Celui qui prends le plus de ressource) et tu fais l'option 5 ("Gerer") puis regarde l'ensemble des options (Cela peux te donner des indications : Pgm ..fichiers...
Déjà tu saura quel job prends des ressources, le pgm en questions.....

2eme Niveau:
Si tu veux des informations plus technique....
Tu peux analyser les performances via le menu cmdpfr

Cordialement,
Jean-Philippe

**JauB** · 28/05/2008, 19h39

Merci pour ta réponse.
en fait comment faire pour :

Envoyé par BALLAT

Tu peux analyser les performances via le menu cmdpfr

?

**BALLAT** · 28/05/2008, 20h59

RE,

L'analyse des perf s'appuie sur un ensemble de Fichier.
Donc il faut alimenté ces bases
1.CFGPFRCOL : Configuration (Unité de tmps...)
2. Démarrer collecte de perf (STRPFRCOL)
3. Aprés un certain temps d'analyse : Arrêter collecte de perf (ENDPFRCOL)

Résultat :
Display Performance Data (DSPPFRDTA)
Display Performance Graph (DSPPFRGPH)
.....

Jean-Philiippe

**Hédhili Jaïdane** · 28/05/2008, 21h16

Bonjour.

Fais un GO CMDPFR et tu as le menu des mesures de performance. Commencer par faire une collecte. Mais c'est la grosse artillerie et ça va consommer de la cpu.

SQL est bien boosté à partir de la V5R2 et utilise le moteur SQE relativement très puissant par rapport à l'ancien CQE, je ne pense pas que le problème viendrait de là à moins d'un serpent qui se mordrait la queue.

Regarde plutôt ce qui consomme de la cpu comme le suggérait Jean-Philippe.

Regarde aussi ton occupation ASP (WRKSYSSTS)

A la limite lance un petit RCLSTG en dédié. Ca risque de durer, jusqu'à
qlqes heures.

Il y a aussi RCLDBXREF qu'on peut lancer s'il y a un pb avec la DB. (système pas obligatoirement dédié)

Donne nous des nouvelles.

**Hédhili Jaïdane** · 28/05/2008, 21h26

Addendum :

Regarde ce que contient QPFRADJ.

**Green Hornet** · 29/05/2008, 00h26

Envoyé par BALLAT

Faire F5 de temps en temps pour reactualiser

ah la la les anciens

bon alors WRKACTJOB + F4 + F10, et il y a un paramétrage pour le réaffichage automatique, renseigner le nombre de secondes souhaitées puis une fois l'affichage en cours, il suffit de faire F19 pour activer ou désactiver le réaffichage automatique... et les tris fonctionnent parfaitement dans le mode automatique

voilou, Green Hornet qui ne sait quoi répondre de plus mais qui est content d'avoir, peut être, appris quelque chose au maître Hédhili Jaïdane

**K2R400** · 29/05/2008, 09h25

Salut,

Regarde dans les messages de QSYSOPR si il n'y a pas une remontée concernant la pile de la carte RAID. Officiellement il faut la changer tous les 2 à 3 ans.
Si la pile est morte, la carte RAID n'utilise plus son cache (question de sécurité) et les perfs seront catastrophiques !!!!!
C'est un cas très souvent rencontré pour les chutes de perfs subites du jour au lendemain !

**Hédhili Jaïdane** · 29/05/2008, 10h40

Envoyé par Green Hornet

ah la la les anciens

bon alors WRKACTJOB + F4 + F10, et il y a un paramétrage pour le réaffichage automatique, renseigner le nombre de secondes souhaitées puis une fois l'affichage en cours, il suffit de faire F19 pour activer ou désactiver le réaffichage automatique...

Salut Green Hornet.

Je suis moi aussi content que tu sois réactif et complète nos réponses, sinon tu serais là pourquoi. Mais je te signale quand même que les anciens connaissent bien le réaffichage auto de WRKACTJOB. Na !

**Green Hornet** · 29/05/2008, 20h28

Envoyé par K2R400

Salut,

Regarde dans les messages de QSYSOPR si il n'y a pas une remontée concernant la pile de la carte RAID. Officiellement il faut la changer tous les 2 à 3 ans.
Si la pile est morte, la carte RAID n'utilise plus son cache (question de sécurité) et les perfs seront catastrophiques !!!!!
C'est un cas très souvent rencontré pour les chutes de perfs subites du jour au lendemain !

ah oui on a eu ce soucis une fois dans mon ancienne boite, un petit coup de ANZPRB si mes souvenirs sont bons permet d'en savoir plus...

**Green Hornet** · 29/05/2008, 20h30

Envoyé par Hédhili Jaïdane

Salut Green Hornet.

Je suis moi aussi content que tu sois réactif et complète nos réponses, sinon tu serais là pourquoi. Mais je te signale quand même que les anciens connaissent bien le réaffichage auto de WRKACTJOB. Na !

salut

je l'aurai un jour je l'aurai

**Hédhili Jaïdane** · 30/05/2008, 20h43

Salut JauB.

As-tu trouvé une soluce à ton pb ?

**JauB** · 30/05/2008, 23h24

En fait on a enlevé l'état (état jasper contenant une requête attaquant plusieurs fichiers volumineux) et ça s'est amélioré un peu.
Je pense qu'on doit chercher comment faire pour que notre serveur I5 supporte bien les requêtes SQL. car en attaquant en COBOL les mêmes fichiers dont je viens de parler le problème ne se pose pas, mais avec du SQL ça galère!
de plus nos états attaquent des fichiers (DDS) d'un progiciel, on ne peut alors même pas faire des index sur ces fichiers car on ne connait pas les risques d'ajouter des index
To be continued ...
Bon week-end tout le monde

**K2R400** · 31/05/2008, 00h12

Envoyé par JauB

on ne peut alors même pas faire des index sur ces fichiers car on ne connait pas les risques d'ajouter des index

Commence par faire un CRTDUPOBJ de QAQQINI de QSYS dans QUSRSYS.
Et mets la valeur *YES dans IGNORE_DERIVED_INDEX (tu peux utiliser iSeries Navigator pour ce faire, même pour dupliquer le fichier)
Reste à créer des Index pertinents, mais tu ne risques rien à créer des Index, l'application ne sera pas impactée, tu auras juste des perfs améliorées en lecture (et diminuées en écriture).
Il faut voir aussi si tes fichiers sont journalisés ou non, et si oui il vaudra mieux isoler les récepteurs sur un ASP différent.
SQL bien réglé offre de très bonnes perfs.
Quelle version d'OS as-tu ?

**BALLAT** · 01/06/2008, 11h26

Bonjour,

"de plus nos états attaquent des fichiers (DDS) d'un progiciel, on ne peut alors même pas faire des index sur ces fichiers car on ne connait pas les risques d'ajouter des index"

Tu ne risque absolument rien si tu le fais propement.

En gros, tu as un progiciel avec des fichiers DDS, et tu fais des requêtes dessus.

Tu peux te creer une bibliothèque "Specifiques ta société" , Ajouter ta bib par ADDLIBLE, créer tes fichiers sources nécessaire QDDSSRC , QCBLSRC....
Et donc créer tes vues et/ou programmes indépendamment du progiciel.

Tu peux améliorer tes temps de réponses en créant tes vues dans ta bib.

Exemple pour les perf sur des liens entre fichier en SQL...Tu peux faires tes liens dans un ou des fichiers joints et donc ta requete SQL ne lira qu'un seul fichier en ne sélectionnant bien sur uniquement que les champs qui t'intéresse
Tu peux faire des selections omissions......

Cela est les perfs vues BD.

La qualité de la BD est primordiale.......Il n'y a pas de secret.

Base pourri ....Tmps de réponse pourri....

Aprés il y a en effet des réglages pour SQL (message de K2R400).
A voir aussi de trés prés.

Aprés il y a la charge réélle de l'I5.......

Cordialement,
Jean-Philippe

**K2R400** · 02/06/2008, 12h25

Envoyé par BALLAT

Exemple pour les perf sur des liens entre fichier en SQL...Tu peux faires tes liens dans un ou des fichiers joints et donc ta requete SQL ne lira qu'un seul fichier en ne sélectionnant bien sur uniquement que les champs qui t'intéresse
Tu peux faire des selections omissions......

Vrai, mais uniquement à travers des vues, pas de requêtes SQL sur des LF (joints ou non) créés avec des DDS