Discussion :

[JEDI1970]

Bonsoir,

Suite a des ralentissements de certains de nos AS/400 de prod, on me demande de mettre en place une surveillance de saturation d'une machine (au niveau UC).

Sachant que nous avons déjà un outil qui permet d'envoyer le % ASP ainsi qu'un seuil d'alerte de celui ci (via l'API QWCRSSTS, qui retourne les valeur du dspsyssts).

J'ai pensé a 2 solutions :

utiliser les monitoring avec seuil d'alerte de Navigator.

Le pb c'est qu'il faut qu'il soit constement démarré, qu'il ne prenne pas trop d'UC, ce qui me gène le plus c'est que j'ai entendu dire que les données restent stockées, je suppose que c'est sur les AS monitorés, et ca m'embete car , je ne sais pas ou ils sont stockés (pour en gérer la taille) et nous avons déjà queslques AS un peu limite au niveau ASP.

Ou le plus facile a mettre en place, récupérer % UC de la même API que pour l'ASP. Mais comme il s'agit de la valeur UC a un instant T et pas une moyenne, ce ne me plait pas beaucoup non plus.

Que pensez vous des 2 solutions ? Y a t'il un moyen, ou une API qui permette de récupéré un temps moyen, ou une valeur UC qui serait significatives pour gérer une alerte ?

[JEDI1970]

bon, a priori, mon pb n'a inspiré personne

Si ca peut aider une personne qui aurait la même problématique, j'ai opté pour la solution de récupérer le % CPU de QWCRSSTS dans un job en PJ avec un delay de 300 seconds (5mn), de mettre le CPU récupéré dans une DTAARA, et si j'ai 3 fois d'affilé plus de 95 % de CPU, j'envoi une alerte.

[hermellin]

Ce doit etre des Api tres techniques peu utilisées.

peut-etre pourrais tu utiliser l'API finder
http://publib.boulder.ibm.com/infoce...der/finder.htm

et peut-etre la categorie "Performance Management", c'est juste une idée.

Hermelin,

[Mercure]

Salut,

J'ai là un programme écrit par Carsten Flensburg, un as dans ce domaine, qui signale les programmes qui prennent plus de la moitié de la limite de temps du processeur interactif.

Tu pourrais le faire tourner toutes les 10 minutes avec un timer.

Si ça t'intéresse, fais-le moi savoir.

[JEDI1970]

Merci pour votre aide,
Vu le delai que l'on m'avait donné,

j'ai utilisé l'API pour récupéré le % UC , mais effectivement si les résultats ne sont pas probants, je regarderai vers les jobs interactifs qui prennent trop de temps du processeur dont me parlai Mercure(quoi que je ne soit pas sur que ca soit un processus interactif qui pose pb.)

Je te remercie Fabrice_44 pour les informations sur les analyses de performence, mais avec mon niveau actuel, il me faudrait un peu de temps devant moi (que je n'ai pas trop) ne serait-ce que pour découvrir, comprendre et savoir utiliser correctement les infos que tu m'as donné. Si les ralentissments persistent et qu'on se décide a me donner le temps necessaire pour analyser tout ca, j'espère pouvoir m'y pencher dessus. Parce qu' au vu de l'apercu que tu me donne, alerter lors du dépassement UC, semble un peu bidon...

Ceci dit j'ai fait une pré analyse en récupérant les % UC de nos machines et on dépasse rarement le 60 %, même lors des traitements plus lourds...

[Ralita]

Bonsoir,

J'ai le meme problematique pour le %CPU du DSPSYSSTS.
Pour disposer d'une valeur moyenne du %CPU, d'une tendance générale (sur une heure, sur la journée), la plus objective possible de la consommation d'UC :
1. pour ne pas trop lisser les valeurs=ne pas avoir une intervalle trop longue,
2. pour ne pas perdre des éventuelles pointes de CPU entre les intervalles=faire une moyenne sur 5mn est raisonnable (2mn si on veut être perfectionniste).

Pour ce faire, effectuer une boucle de collecte via l'API QWCRSStS toutes les 5mn avec la séquence suivante :

Exécuter l'API avec le paramètre initialisation (4ème paramètre) à *NO
Stocker l'information
Executer l'API avec le paramètre initialisation (4ème paramètre) à *YES
Attendre 5mn et reboucler au début.

L'exécution à *YES reinitialise et collecte la valeur à l'instant t (cette valeur ne sera pas stockée, l'appel de l'api sert uniquement de reinitialisation comme point de départ pour faire la moyenne des 5mn suivantes).

L'éxécution à *NO, 5mn après, renvoie la valeur moyenne du CPU des 5mn écoulées.

Les informations collectées donnent une tendance assez proche de la consommation moyenne réelle du CPU.
Comme dit ci-dessus, ramener l'intervalle à 3 ou 2mn apporte encore un peu plus de précisions.

Sachant que le job de collecte ne consomme presque rien du tout en bouclant sur 24h voire plus.

J'ai arrêté le performance Tools car cela prend un peu de CPU et surtout beaucoup de place sur disque (quelques gigots)

A votre disposition pour plus d'info