Discussion :

[TanguyT]

Bonjour à tous,

Voila… J’ai un problème système avec un de mes AS400 (en fait un iSerie 270) qui est en version V4R3.
Depuis une quinzaine de jour (vers le 27/12/2012… en tout cas, avant la fin de l’année), le pourcentage d’occupation de la mémoire (% ASP système utilisé) augmente régulièrement et fortement d’environ 5% par jour (avant, c’était plutôt 0,2% par jour).
Pour essayer de trouver les objets qui peuvent expliquer une telle augmentation, j’ai fais (sous Qsecofr) des DSPOBJD (avec les options OBJ(*ALL/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) ) à 1 jour d’intervalle… Mais aucun nouvel objet ou augmentation de la taille d’un déjà existant peut expliquer une telle évolution.

Lorsqu’on fait un IPL, le « % ASP système utilisé » redescend à 67%, ce qui nous force à en faire un tous les 4 jours environ (67%+4*5%=87% soit 13% de marge).

Avez-vous des idées sur l’origine de ce problème et comme y remédier ?

Merci d’avance.

[m4k-Hurrican]

Bonjour,

Je vois deux possibilités.
- Un programme génère des données temporaires, qui sont donc supprimées à l'IPL (gros spoules, files d'attente de message, etc...).
- Un programme spécifiquement écrit pour le problème que tu constates fait le ménage dans le traitement de l'IPL.

Donc :
1) Regarde quel est le CL qui est exécuté à l'IPL (valeur système QSTRUPPGM). Si ce n'est pas le QSTRUP de QSYS, Utilise RTVCLSRC pour en extraire le source et voir s'il ne fait pas quelque chose de spécial (supprimer des récepteurs de journaux, ou que sais-je encore).
2) Plutôt qu'un DSPOBJD, très long à scruter, commence par un DSPLIB *ALL OUTPUT(*PRINT). Ce qui te permettra si les objets concernés sont dans une bibliothèque, de voir lesquelles sont en cause.
3) Pense à l'IFS. Ce n'est pas dans une bibliothèque. Je ne me rappelle plus les commandes disponibles en V4R3, mais si tu as la commande DSPF, tu peux essayer de faire un DSPF STMF('\') pour lister la racine. Ensuite en mettant un 6 en face des répertoires tu obtiendras dans la colonne size la taille du répertoire. Prend des captures d'écran pour comparer le lendemain.

En espérant que çà t'aide.

[larry57]

Bonjour,

il existe aussi la commande PRTDSKINF.
Pour moi, elle permet une analyse plus fine.

Larry57

[TanguyT]

Bonjour,

Tout d’abord un grand merci à « m4k-Hurrican » et « Larry57 » pour leur réponse.

Concernant les 3 points de « m4k-Hurrican » :
1) Sur nos machines, 95% des applications ont été développé en internes. Nous avons donc pratiquement toutes nos sources, et à l’IPL, rien de spéciale (départ de sous-système, libération de jobq…)
2) Quand je fais mes DSPOBJD, je place le résultat dans un 1 fichier que j’importe ensuite dans un fichier Excel. Je génère ensuite un «tableau croisé dynamique » avec en colonne les date des clichés, ce qui me permet de repérer « facilement » avec des filtres, parmi les 40000 objets de l’AS400, les nouveaux, ceux qui ont augmenté de taille… La variation théorique est de quelques dixièmes de % (loin des 5%).
3) En V5R3, j’ai bien la commande « DSPF STMF('\') », j’en en fais 2 à quelques jours d’intervalle, je constate une variation de 1,1Mo (négligeable)

Quant à la commande « PRTDSKINF », je ne la connaissais pas. Par contre, elle a l’air gourmande en ressource (d’après ce que je lis sur internet). Je la lancerai demain entre midi et deux.

Encore merci à tous les 2.

Bien cordialement.

[Hédhili Jaïdane]

...Quant à la commande « PRTDSKINF », je ne la connaissais pas. Par contre, elle a l’air gourmande en ressource (d’après ce que je lis sur internet). Je la lancerai demain entre midi et deux.

Bonjour.

Tu dois au préalable lancer la commande RTVDSKINF qui, elle, va collecter toutes les infos sur un ASP et c'est elle qui est gourmande en ressources, il faudrait la lancer quand le système n'est pas surchargé.
Ensuite tu lances la commande PRTDSKINF en fonction de ce que tu cherches. Voir ses paramètres. Regarde aussi l'aide sur la commande RTVDSKINF pour savoir où sont stockées les informations collectées. Le fichier DB généré, tu peux l'utiliser à loisir.

PS : Au risque de faire rire certains, vérifie si tu n'as par hasard des programmes ou des procédures qui font des tris internes ou externes et qui ne suppriment les fichiers de tri.

[TanguyT]

Bonjour,

Merci à Hédhili Jaïdane pour sa contribution…
Un petit point intermédiaire sur les avancées de ma recherche…
J’ai donc fais un « RTVDSKINF » à 20 heures d’intervalle… Et je constate que l’objet « *TMPSPACE » (Espace pour les objets temporaires…) augmente dans des proportions qui explique à lui seul la saturation du système (Rem : j’aurai pu m’en apercevoir avant car cette valeur correspond aussi à « Non protégée maximale » du DSPSYSSTS).
J’ai commencé à regarder sur internet… On parle de PTF pour résoudre ce problème (mais en V5R3 sic…).
Ce qui m’étonne encore, c’est la soudaineté de l’apparition du problème alors que l’on n’a pas changé notre façon de travailler (pas de nouveau logiciel…).

Très cordialement....

[Hédhili Jaïdane]

Bonjour.

En attendant de voir les raisons de cet accroissement de besoins en ressources temporaires :
- faites passer régulièrement les commandes, par un CL planifié, RCLTMPSTG et RCLSPLSTG; (si vous faites de très gros tirages sur les imprimantes, l'espace occupé par les membres spool pourrait ne pas être récupéré)
- activer le CLEANUP et y mettre le max de nettoyages

On pourrait peut être faire un RCLSTG ou des RCLDBXREF sur les biblios en erreur (*FIX et *ERR) ou sur des biblios spécifiques.

Si tout ça ne donne rien, planifier un power on/off ou un pwrdwnsys *immed et restart(*yes) pour éviter de trop solliciter la partie power du système.