Help Temps de réponse

[jmmd]

Bonjour à tous, et merci de votre aide.

Nous avons des problèmes de temps de réponse épisodiques sur notre AS400.

Parfois quelques minutes, parfois par demi-journée (le système se met complètement à genoux)

J'ai déja supprimé tout les DYNSLT des vues logiques, mais ce n'est pas la seule cause apparemment.

Le WRKACTJOB ne montre pas d'anomalies (rarement au dessus de 30% CPU)

ASP système  . . . . . . :    211,6 G
% ASP système utilisé  . :    37,2064
Mémoire secondaire totale:    211,6 G
Non protégée utilisée  . :     6627 M
Non protégée maximale  . :     7749 M

Merci de me donner quelques pistes de recherche

[jmpenasse]

Bonjour,

Pouvez vous nous mettre des captures d'écrans de ce qu'affiche la commande DSPJOBTBL, svp ? (2 écrans, faire F11)

[Didier]

Bonjour,
Avez-vous des terminaux non IBM ?
J'ai par le passé rencontré la chose, avec une machine à genoux et un active job à 0%
La solution IPL.
amicalement

[jmmd]

Merci à vous pour cette rapidité de réponse.
Nous utilisons quasi exclusivement des PC non IBM sous client Accès. Ce choix date depuis 15 ans et a toujours donné satisfaction.

Ci-dessous la copie d'écran du DSPJOBTBL. A cette heure ci le système est peu actif, et ne presente pas de problème. Faut-il en refaire un au moment du problème?

Code:

                                                      11/03/11  18:13:11
 Structures de travail permanentes:       Structures de travail temporaires:    
   Initiales  . . . :   30                  Initiales  . . . :   20            
   Supplémentaires  :   10                  Supplémentaires  :   10            
   Disponibles  . . :   19393               Disponibles  . . :   157            
   Total  . . . . . :   70182                                                  
   Maximum  . . . . :   163520                                                  
                                                                                
                                                                                
                          ----------------------Postes----------------------    
      Table       Taille        Total  Disponibles     Utilisés       Autres    
          1     16752384        16352            5        16347            0    
          2     16749312        16352            5        16347            0    
          3     16749312        16352          900        15452            0    
          4     16749312        16352        13709         2643            0    
          5      4920064         4774         4774            0            0    

Code:

Structures de travail permanentes:       Structures de travail temporaires:  
  Initiales  . . . :   30                  Initiales  . . . :   20          
  Supplémentaires  :   10                  Supplémentaires  :   10          
  Disponibles  . . :   19393               Disponibles  . . :   157          
  Total  . . . . . :   70182                                                
  Maximum  . . . . :   163520                                                
                                                                            
            ------------------Postes utilisés-------------------            
                         File attente  File attente    Hist trav            
     Table       Actifs     travaux       sortie        instance            
         1           36             2         16271           38            
         2           11             0         15980          356            
         3          164             6         15182          100            
         4            0             0          2532          111            
         5            0             0             0            0      

     
                                                                              
Edit: jmpenasse, raison: mise en forme ecrans avec balise code

[jmpenasse]

Il peut y avoir plein de raisons bien sur et l'aspect "tables des travaux" n'en est qu'un. Il peut y avoir aussi la mémoire (Ram), etc...
Je vais juste continuer sur cette partie des tables de travaux car effectivement il y a un soucis.
Ce serait bien en effet d'avoir la même chose à un moment ou un maximum de jobs s'exécutent, mais on peut déjà dégrossir.

Tout d'abord il y a un "Red paper"  (assez court : 28 pages) qui explique tout ça en détail (et en anglais) :
http://www.redbooks.ibm.com/abstracts/redp4454.html

Le problème ici (et je vous rassure c'est un cas très fréquent) c'est le nombre de spoules conservés sur la machine.

Les jobs passent par 3 états principaux :

- en JOBQ : le job est en file d'attente de traitement avant exécution
- Actif : c'est la phase d'exécution réelle
- OUTQ : l'exécution est terminée, mais des spoules sont toujours reliés au job, empéchant sa "suppression".

Le soucis est que les jobs sont gérés dans une ou plusieurs tables (au sens "tableau", pas table sql) des travaux (qwcbtxx : work control block table)

Chaque élément ("poste de tableau" ) fait référence à un job quel que soit son état.
Quand un job est terminé (plus de spoules reliés) le poste est marqué comme réutilisable.

Une table est limitée à 16Mo, ce qui fait que quand une table est pleine, une autre est créée (5 dans votre cas.)

Un gros inconvénient est que ces tables ne sont pas vraiment indéxées. Donc quand le système à besoin d'accéder à la liste des jobs, il va devoir parcourir tout ou partie de la liste.

de même quand un nouveau job doit être créé, le système cherche un poste disponible dans les tables depuis le début.

Or ce que l'on voit sur votre système, c'est que vous avez un très grand nombre de jobs en OUTQ (49.965), pour 211 jobs actifs (normal pour un système au repos) et 7 jobs en jobq.

On voit également que les 2 premières tables n'ont chacune que 5 postes disponibles pour les nouveaux jobs qui seront créés dans l'avenir.
cela veut dire que les 5 prochains jobs iront dans la première table, mais que les 5 suivants iront dans la seconde APRES scannage complet de la première pour chercher un poste dispo. Le 11 eme travail ira dans la 3 eme table, etc.
Cela n'est vrai que si entre temps aucun poste ne se libère.

Bref et en résumé, moins on a de jobs connus du système (somme des jobq, actifs et outq) mieux le système se porte. Et la plus gande partie de ces jobs étant en OUTQ : moins on a de spools mieux le système se porte.
Mais comme il n'est pas toujours facile de supprimer des spools (leur conservation peut-être importante) il est maintenant possible (depuis les V5R2 et V5R4) de "détacher" des spools de leur jobs : le spool est conservé, mais il n'est plus relié à un job, libérant ainsi de la place dans la table.
Pour cela il y a la sysval QSPLFACN pour tous les futurs spoules, ou il est possible de changer les anciens jobs par :
CHGJOB JOB(999999/user/job) SPLFACN(*DETACH)

Faire le ménage dans les spoules serait l'idéal ...
et ensuite faire suivre un IPL en ayant préalablement demander la compression des tables de travaux dans l'IPLA :

CHGIPLA CPRJOBTBL(*NEXT)

Mais je vous renvoi encore à la lecture du Repaper cité plus haut pour plus de détails et de précisions

[jmmd]

Bonjour,
J'ai supprimé près de 50 000 spoules (des LOG) et relancé un IPL.
Ci-dessous le nouvel état des tables. (système toujours peu utilisé)
J'attend maintenant le début de semaine pour mesurer l'impact.
Merci pour cette piste très probable.

                                                             12/03/11  18:16:19
 Structures de travail permanentes:       Structures de travail temporaires:   
   Initiales  . . . :   30                  Initiales  . . . :   20           
   Supplémentaires  :   10                  Supplémentaires  :   10           
   Disponibles  . . :   9                   Disponibles  . . :   4             
   Total  . . . . . :   5258                                                   
   Maximum  . . . . :   163520                                                 
                                                                               
                                                                               
                          ----------------------Postes----------------------   
      Table       Taille        Total  Disponibles     Utilisés       Autres   
          1      5411584         5258            9         5249            0   

                                                            12/03/11  18:16:19
Structures de travail permanentes:       Structures de travail temporaires:   
  Initiales  . . . :   30                  Initiales  . . . :   20           
  Supplémentaires  :   10                  Supplémentaires  :   10           
  Disponibles  . . :   9                   Disponibles  . . :   4             
  Total  . . . . . :   5258                                                   
  Maximum  . . . . :   163520                                                 
                                                                             
            ------------------Postes utilisés-------------------             
                         File attente  File attente    Hist trav             
     Table       Actifs     travaux       sortie        instance             
         1          194             2          4382          671             

[Fabrice]

Bonjour,
J'ai supprimé près de 50 000 spoules (des LOG) et relancé un IPL.
Ci-dessous le nouvel état des tables. (système toujours peu utilisé)
J'attend maintenant le début de semaine pour mesurer l'impact.
Merci pour cette piste très probable.

Bonjour,

Le point sur lequel Jean-Michel t'a orienté, à savoir la table des travaux, est une notion souvent ignorée et pourtant importante, mais je ne pense pas que cela soit l'origine de tes problèmes.
S'il est important d'avoir une table des travaux saine, elle est rarement à l'origine de dégradation de performances, son état contribue en partie aux performances d'un système, mais ne l'influence pas tant que ça.
Il est vrai que chez toi, elle était visiblement assez conséquente par rapport à la taille de ton système.
Ce que l'on peut remarquer en fonction des infos que tu as transmises, c'est que les calibrages des valeurs systèmes de gestion des travaux sont "d'origine" et que l'accroissement du nombre de postes (pour travaux actifs ou travaux connus du système) se fait par paquet de 10. Si ton système créé de nombreux travaux, alors il peut y avoir une dégradation de performances lors de l'ajout des entrées dans la table. Il faut mieux faire un ajout de 100 que 10 ajouts de 10 postes par exemples.

Il y a de nombreuses autres pistes à explorer pour déterminer la cause de tes problèmes.

Peux tu nous donner les infos suivantes afin que l'on ai une meilleure compréhension de ton système :
 - nombre de bras de disques (je pense que tu dois avoir 4 disques de 70,5 Go en RAID-5 vu comme des disques de 52,9 Go) (WRKDSKSTS)
 - type de protection (probablement RAID-5, mais peut être s'agit-il de miroir) (WRKDSKSTS)
 - type de contrôleur (DSPHDWRSC *STG)
 - quantité de mémoire centrale (WRKSHRPOOL)
 - taille des pools mémoire *MACHINE et *BASE (WRKSYSSTS)
 - version de l'Operating System (DSPPTF)
 - niveau de cumulative et des groupes HIPER et DB2 (WRKPTFGRP)
 - modèle (probablement un 5xx ou 8xx) (DSPSYSVAL QPRCFEAT)
 - ...

Les problèmes de performances peuvent avoir plusieurs causes :
 - I/O disques
 - pagination (mémoire)
 - CPU (mais à priori pas ton cas, quoique ...)
 - problème de puissance OLTP
 - réseau
 - ...

A tout hasard, peux tu regarder le WRKDSKSTS puis F11 et nous donner le résultat s'il te plait ?

Quel type de workload tourne sur ton système ? Plutôt traditionnel (RPG/ILE et 5250) ou plutôt Java/SQL ?

Fabrice
 

[jmmd]

Bonjour,
Nous utilisons essentiellement des SQLRPGLE     sous 5250 Client Accès, quelques QRY et quelques extractions IFS/PC ou DB2/PC.

Ci-dessous les données de configuration (système au repos).
                                                         13/03/11  05:42:17
 Intervalle:   00:00:45                                                         
                                                                               
               Taill    %     Dem   Taille     Dem   Dem    Lect  Ecrit    %   
 Unit  Type     (Mo)  occu    E-S  dem (ko)   lect  écrit   (ko)   (ko)  util   
    1  4327    52923  34,4    0,1      4,5     0,0    0,1    8,0    4,0     0   
    2  4327    52923  34,4    0,6      4,6     0,0    0,5    4,0    4,7     0   
    3  4327    52923  34,4    0,9      8,9     0,3    0,6   16,5    4,8     0   
    4  4327    52923  34,4    0,9      4,3     0,0    0,8    4,0    4,4     0   
           --Protection--               
Unit  ASP  Type  Etat      Compression 
   1    1  DPY   ACTIVE                 
   2    1  DPY   ACTIVE                 
   3    1  DPY   ACTIVE                 
   4    1  DPY   ACTIVE                 
                                                                         
Ressource       Type  Etat                  Texte                       
CMB01           2844  Opérationnel          IOP à fonctions combinées   
  DC01          573D  Opérationnel          Contrôleur d'unités magnétiqu
  DC04          2749  Opérationnel          Contrôleur d'unités magnétiqu
CMB02           268C  Opérationnel          IOP à fonctions combinées   
  DC02          6B02  Opérationnel          Contrôleur d'unités magnétiqu
CMB04           2844  Opérationnel          Contrôleur d'unités magnétiqu
  DC03          571A  Opérationnel          Contrôleur d'unités magnétiqu
 

Taille de la mémoire                         
   principale (Mo)  . . . :        3885,01                                                                              
               Taille  Activ  Taille       ID            En     
Pool          définie   maxi  attribuée   pool  Définie  cours 
*MACHINE       239,25  +++++      239,25    1   *FIXED   *FIXED
*BASE         2620,81    187     2620,81    2   *CALC    *CALC 
*INTERACT      986,10     71      986,10    3   *CALC    *CALC 
*SPOOL          38,84     13       38,84    4   *FIXED   *FIXED
*SHRPOOL1        0,00      0                    *FIXED         
*SHRPOOL2        0,00      0                    *FIXED         
*SHRPOOL3        0,00      0                    *FIXED         
*SHRPOOL4        0,00      0                    *FIXED         
*SHRPOOL5        0,00      0                    *FIXED         
               Taille  Activ  Taille       ID            En     
Pool          définie   maxi  attribuée   pool  Définie  cours 
*MACHINE       234,46  +++++      234,46    1   *FIXED   *FIXED
*BASE         2379,07    187     2379,07    2   *CALC    *CALC 
*INTERACT     1232,62     71     1232,62    3   *CALC    *CALC 
*SPOOL          38,84     13       38,84    4   *FIXED   *FIXED
*SHRPOOL1        0,00      0                    *FIXED         
*SHRPOOL2        0,00      0                    *FIXED         
*SHRPOOL3        0,00      0                    *FIXED         
*SHRPOOL4        0,00      0                    *FIXED         
*SHRPOOL5        0,00      0                    *FIXED         
                                          ------Pages/seconde------
                      -----% taille-----            Unité           
Pool        Priorité  Minimale  Maximale  Minimale  exéc   Maximale
*MACHINE         1      4,40       100     10,00     0,00   10,00   
*BASE            1      4,99       100      5,00     0,50     200   
*INTERACT        2     10,00       100     10,00     2,00     100   
*SPOOL           2      1,00       100      5,00     1,00     100   
*SHRPOOL1        2      1,00       100     10,00     2,00     100   
*SHRPOOL2        2      1,00       100     10,00     2,00     100   
*SHRPOOL3        2      1,00       100     10,00     2,00     100   
*SHRPOOL4        2      1,00       100     10,00     2,00     100   
*SHRPOOL5        2      1,00       100     10,00     2,00     100   


                                                            13/03/11  05:53:19
% UC utilisée  . . . . . :        0,7    ASP système  . . . . . . :    211,6 G
% capacité BD  . . . . . :        0,4    % ASP système utilisé  . :    34,4932
Intervalle . . . . . . . :   00:00:13    Mémoire secondaire totale:    211,6 G
Travaux connus du syst . :       5270    Non protégée utilisée  . :     3648 M
% adresses permanentes . :      0,036    Non protégée maximale  . :     3663 M
% adresses temporaires . :      0,285                                         
                                                                             
Pool    Taille    Taille    Act  -Pagin BD--  --Non-BD---  Act->  Att-   Act->
syst     pool     réserv    Max  Taux  Pages  Taux  Pages  Att    Inelg  Inelg
  1     229,77    118,11  +++++    0,0   0,0    0,2   0,5    8,5    0,0    0,0
  2    2445,39      2,18    187    0,0   0,0    0,0   0,0  883,7    0,0    0,0
  3    1170,99      0,00     71    0,0   0,0    1,4   2,1    8,5    0,0    0,0
  4      38,84      0,00     13    0,0   0,0    0,0   0,0    0,0    0,0    0,0

ID produit  . . . . . . . . . . . . . :   5722999           
Source de l'IPL . . . . . . . . . . . :   ££MACH£B  ££SERV£T
Edition de l'option de base . . . . . :   V5R4M0 L00         

Groupe de PTF           Niv  Etat     
SF99540                8183  Installé
SF99539                  83  Installé
SF99504                  17  Installé

Valeur système . . . . :   QPRCFEAT               
Description  . . . . . :   Dispositif processeur 
                                                 
                                                 
Dispositif processeur  :   7143                   

[Fabrice]

Bonjour,
Nous utilisons essentiellement des SQLRPGLE     sous 5250 Client Accès, quelques QRY et quelques extractions IFS/PC ou DB2/PC.

Bonjour jmmd,

Je vais essayer de détailler quelques points pour tenter d'avancer sur ton problème de performances.

D'après les infos que tu viens de fournir, les grandes lignes de ton système sont les suivantes :
 - Modèle : 520
 - Processeur : POWER5+ à 1,9 GHz avec 1,88 Mo de cache L2 et 36 Mo de cache L3
 - Puissance CPW : 1200 dont 60 en interactif (OLTP), accélérateur non activé
 - Mémoire centrale : 4 Go
 - Disques : 4 bras de 70,5 Go en RAID-5
 - Contrôleur disque : 5727 avec 40 Mo de write cache et 0 Mo de read cache
 - Version IBM i : V5R4M0
 - Niveau de cumulative : C8183540

Code:

                                                                               
               Taill    %     Dem   Taille     Dem   Dem    Lect  Ecrit    %        --Protection--               
 Unit  Type     (Mo)  occu    E-S  dem (ko)   lect  écrit   (ko)   (ko)  util   ASP  Type  Etat      Compression   
    1  4327    52923  34,4    0,1      4,5     0,0    0,1    8,0    4,0     0     1  DPY   ACTIVE                 
    2  4327    52923  34,4    0,6      4,6     0,0    0,5    4,0    4,7     0     1  DPY   ACTIVE                 
    3  4327    52923  34,4    0,9      8,9     0,3    0,6   16,5    4,8     0     1  DPY   ACTIVE                 
    4  4327    52923  34,4    0,9      4,3     0,0    0,8    4,0    4,4     0     1  DPY   ACTIVE                 

       
Premier point important, que l'on pouvait craindre, c'était l'état de la batterie du contrôleur disque. Il n'y a pour le moment pas de problème en cours à ce niveau  .
En effet, l'état des disques est bien en "ACTIVE" et pas en "DEGRADEE" comme on aurait pu le supposer. La batterie est donc opérationnelle et par conséquent le write cache permettant les écritures asynchrones sur disque l'est également.
Si tel n'avait pas été le cas, tes performances s'en seraient ressenties car le write cache aurait été désactivé et les écritures disques auraient alors été synchrones rendant toutes les transactions plus lentes.
De plus, ton occupation disque est à un niveau plus que correct (37,2% sur le shoot écran de ton premier message).
Attention toutefois, cela n’exclu pas pour autant les disques comme cause possible de tes problèmes de performances, en effet si leur nombre n'est pas assez élevé pour répondre aux I/O générées par tes applications et si les 40 Mo du write cache ne sont pas suffisants, alors le système d’I/O peut être une cause des dégradations de performances, mais dans ce cas, seule une étude pourrait le mettre en évidence.

Code:

                                                                               
Ressource       Type  Etat                  Texte                       
CMB01           2844  Opérationnel          IOP à fonctions combinées   
  DC01          573D  Opérationnel          Contrôleur d'unités magnétiques
  DC04          2749  Opérationnel          Contrôleur d'unités magnétiques
CMB02           268C  Opérationnel          IOP à fonctions combinées   
  DC02          6B02  Opérationnel          Contrôleur d'unités magnétiques
CMB04           2844  Opérationnel          Contrôleur d'unités magnétiques
  DC03          571A  Opérationnel          Contrôleur d'unités magnétiques

       
Les informations ci-dessus correspondent à tes ressources de stockage (disques, contrôleurs, lecteur de bande, lecteur optique …)
Une petite remarque sur ce sujet, je constate que le contrôleur disque (573D/5727) est géré par le même IOP (le 2844 CMB01) qui gère également le contrôleur bande 2749. Ce dernier doit être un contrôleur destiné à supporter une vieille unité LTO ou 3570 ou quelque chose comme cela. J’espère que vous ne l’utilisez plus (le 2749) et surtout, si vous l’utilisez, que cela ne soit pas pendant la production car il peut y avoir des problèmes de performances sur l’IOP. Même si cette architecture est possible, on ne doit pas mettre un contrôleur bande, qui plus est, de vieille génération, sur le même IOP que le contrôleur disque.
Parenthèse terminée.

Code:

       
Taille de la mémoire                         
   principale (Mo)  . . . :        3885,01                                                                           
                                                                                    ------Pages/seconde------
               Taille  Activ  Taille       ID            En            -----% taille-----            Unité
Pool          définie   maxi  attribuée   pool  Définie  cours   Priorité  Minimale  Maximale  Minimale  exéc   Maximale
*MACHINE       234,46  +++++      234,46    1   *FIXED   *FIXED      1      4,40       100     10,00     0,00   10,00   
*BASE         2379,07    187     2379,07    2   *CALC    *CALC       1      4,99       100      5,00     0,50     200
*INTERACT     1232,62     71     1232,62    3   *CALC    *CALC       2     10,00       100     10,00     2,00     100
*SPOOL          38,84     13       38,84    4   *FIXED   *FIXED      2      1,00       100      5,00     1,00     100 
*SHRPOOL1        0,00      0                    *FIXED               2      1,00       100     10,00     2,00     100
*SHRPOOL2        0,00      0                    *FIXED               2      1,00       100     10,00     2,00     100
*SHRPOOL3        0,00      0                    *FIXED               2      1,00       100     10,00     2,00     100
*SHRPOOL4        0,00      0                    *FIXED               2      1,00       100     10,00     2,00     100
*SHRPOOL5        0,00      0                    *FIXED               2      1,00       100     10,00     2,00     100

       
Le système dispose de 3885 Mo (3,79 Go) sur les 4 Go installés. 0,21 Go sont affectés au Power Hypervisor, ce qui est tout à fait normal.
Je note, même si ce shoot écran a été pris hors pointe d’activité, que la quantité de mémoire affectée au pool *MACHINE est bien trop faible. On est à peine à 6%. Il faut impérativement mettre au moins 10% de la mémoire centrale pour ce pool, mais le conseil est plutôt d’en affecter 15%. On devrait donc environ 590 Mo de mémoire dans ce pool plutôt que 234 Mo. Il faut donc ajuster la taille mini de ce pool.
Il faut bien comprendre que le pool *MACHINE est le pool le plus important pour le système car les process système internes de gestion des disques, de la base de donnée … s’y exécutent.
Si ton système n’est pas à même de s’autogérer correctement, alors il ne pourra pas répondre à tes besoins pour l’exploitation quotidienne.
Il y aurait bien d’autres ajustements à mettre au niveau des pools de des taux de pagination, mais ils ne peuvent être réalisés qu’avec une étude performance.

Code:

                                                            13/03/11  05:53:19
% UC utilisée  . . . . . :        0,7    ASP système  . . . . . . :    211,6 G
% capacité BD  . . . . . :        0,4    % ASP système utilisé  . :    34,4932
Intervalle . . . . . . . :   00:00:13    Mémoire secondaire totale:    211,6 G
Travaux connus du syst . :       5270    Non protégée utilisée  . :     3648 M
% adresses permanentes . :      0,036    Non protégée maximale  . :     3663 M
% adresses temporaires . :      0,285                                         
                                                                             
Pool    Taille    Taille    Act  -Pagin BD--  --Non-BD---  Act->  Att-   Act->
syst     pool     réserv    Max  Taux  Pages  Taux  Pages  Att    Inelg  Inelg
  1     229,77    118,11  +++++    0,0   0,0    0,2   0,5    8,5    0,0    0,0
  2    2445,39      2,18    187    0,0   0,0    0,0   0,0  883,7    0,0    0,0
  3    1170,99      0,00     71    0,0   0,0    1,4   2,1    8,5    0,0    0,0
  4      38,84      0,00     13    0,0   0,0    0,0   0,0    0,0    0,0    0,0

Comme tu le dis, ces informations ont été prises hors activité, elles n’ont donc pas de grande valeur, ici, on constate que ce shoot écran a été fait après ton ménage sur les spools et peut être d’autres objets car l’occupation disque n’est plus à 37,2% mais à 34,5%. Toutefois, ce qui peut nous intéresser ici, c’est la mémoire non protégée (l’espace temporaire). Ici, on constate qu’il y a 3663 Mo d’espace temporaire, mais tu viens probablement d’effectuer un IPL alors elle n’a pas de signification particulière, en revanche en prenant ton chiffre du premier message (7749 Mo), on a une indication très importante sur ton activité.
On peut calculer que l’espace temporaire a eu une pointe à 3,66% de l’espace total, ça reste dans les normes pour l’indication sur le nombre de bras de disques nécessaires, car les guidelines indiquent qu’il ne faut pas dépasser 5%. En revanche, la seconde information est que cet espace était égal au double de ta quantité de mémoire centrale, et ça, ce n’est pas bon du tout (7749/3885=1,99).
On considère que la valeur indiquée dans la mémoire non protégée ne doit pas dépasser ou trop s’approcher du double de la valeur de la mémoire centrale configurée.
Même si cela reste non indiqué dans les guidelines officiels, il s’agit d’une préconisation connue des personnes s’occupant de l’optimisation d’un système.
Il est fort probable que ton système pagine trop, on ne peut le voir que sur une étude de performances. Tu nous indiques que tu fais principalement du SQLRPGLE, or le SQL est un fort consommateur en ressource mémoire car la taille de ses buffers sont plus importants que ceux utilisés par les I/O DDS. La taille des ODP (Open Data path) et donc du PAG (Process    Access Group) d’un job SQL est beaucoup plus élevée que celle d’un job classique.
Le premier sentiment que l’on pourrait avoir est que la quantité de mémoire soit un peu juste, 4 Go c’est peu lorsque l’on fait du SQL à grande échelle. Tout dépend réellement de l’activité sur ton système. Est-elle forte ou normale ? Combien de users ?

Code:

ID produit  . . . . . . . . . . . . . :   5722999           
Source de l'IPL . . . . . . . . . . . :   ££MACH£B  ££SERV£T
Edition de l'option de base . . . . . :   V5R4M0 L00         

On est donc en V5R4M0.

Code:

Groupe de PTF           Niv  Etat     
SF99540                8183  Installé
SF99539                  83  Installé
SF99504                  17  Installé

Alors là, je dis tout de suite que ce n’est pas bien du tout  . Tu as plus de deux ans de retard sur les PTFs. On pourrait avoir un débat sur faut-il ou pas mettre à jour régulièrement son serveur, ma conviction est : Oui, oui et oui !!!!!!!!!
Ces machines supportent généralement de nombreuses applications, certaines sont historiques et n’évoluent plus, d’autres utilisent les dernières technologies, et nécessitent donc d’être à jour pour se comporter correctement.
La cumulative C8183540 est obsolète. Il y a eut 5 cumulatives depuis la tienne, la dernière étant la C0292540 (octobre 2010).
Il faut impérativement se mettre à jour au moins une fois par an, c’est la base indispensable pour assurer les performances, la stabilité et la prise en compte des nouveautés et corrections de problèmes.
De même pour les HIPER, tu es au niveau 83 alors que le dernier est le 148 !
Idem pour la database, tu es au niveau 17 alors que le dernier est le 30. La mise à jour de ces niveaux est indispensable sur les environnements SQL.
J’espère que tu as également d’autres groupes de PTF installés, et que ceux que tu n’as collé que ceux que je t’avais demandé. As-tu les groupes, Java, TCP/IP, http, BRS … ?
Bilan, on n’est pas bien du côté des PTF.

Le point qu’il conviendrait également d’analyser est la capacité OLTP (On-Line Transaction Processing) appelée couramment puissance interactive. Ton serveur est un 520 à base de processeur POWER5+, sa puissance utilisable est de 1200 CPW (32% de la puissance réelle car le serveur est bridé par IBM) et la capacité interactive est de 60 CPW c'est-à-dire que cela représente 5% de la puissance utilisable (60/1200*100=5%).
Or cette valeur est peut être trop faible parfois dans ton exploitation quotidienne. Il suffit qu’un job interactif effectue de grosses requêtes pour totalement plomber un système. C’est très fréquent sur ce type de système à capacité OLTP limitée.

Peux-tu lancer une recherche dans l’historique de ton système sur le message de dépassement de la capacité interactive (CPI1479) ?
DSPLOG LOG(QHST) PERIOD(*AVAIL jjmmaa) MSGID(CPI1479)

Merci de nous indiquer si tu as des messages de ce type.

A suivre …

Fabrice

[jmmd]

Bonjour,
Oui, j'ai 24 occurences de ce message entre le 11/02 et le 11/03

Pour info, J'ai passé le pool machine à 600 MO

[Fabrice]

Bonjour,
Oui, j'ai 24 occurences de ce message entre le 11/02 et le 11/03

Pour info, J'ai passé le pool machine à 600 MO

Voila, on semble être sur la bonne piste, ton problème de performances doit probablement provenir de la capacité interactive.

24 dépassements en un mois, c'est donc un par jour. Si ce problème est réellement la cause des dégradations de performances alors tu as deux solutions :
 - changer de système
 - modifier tes programmes pour que ces dépassements de capacité soient exécutés en batch

Le dépassement du seuil maximum autorisé est 7/6ème de la valeur maximum. Comme tu as droit à 60 CPW sur cette machine, 7/6ème correspondent à 70 CPW. Donc, lorsque la somme des CPW des travaux interactifs dépasse 70 CPW, le governor plombe ton système. Tu verras une tâche système (dans le moniteur de performance ou via la commande WRKSYSACT) qui se nomme CFINT01.
Cette tâche est là pour vérifier que tu ne dépasses pas la capacité à laquelle tu as le droit, et si tu le fais, elle n'a aucune amertume, elle plombe volontairement ton système.

Ce mode de fonctionnement est valable pour tous les systèmes qui n'ont pas la capacité interactive égale à la puissance totale du processeur (7xx, 270, 8xx et les 520 d'avant 2007).

Fabrice

[jmmd]

Merci pour ce super travail.
Mes utilisateurs ouvrent plusieures sessions (parfois 5 ou 6 en même temps). Une limitation du nombre de ces sessions (si elle est possible) ne réduirait-elle pas le problème?

[Fabrice]

Mes utilisateurs ouvrent plusieures sessions (parfois 5 ou 6 en même temps). Une limitation du nombre de ces sessions (si elle est possible) ne réduirait-elle pas le problème?

La réduction du nombre de session par utilisateur n'aura aucune incidence pour ce problème. En effet, le système additionne la somme des puissances interactives utilisées en simultané, or par définition, un utilisateur ne peut pas être au four et au moulin en même temps, il ne peut donc pas faire deux tâches simultanées.
Une transaction interactive ne doit normalement pas excéder une certaine durée (elle est de l'ordre de quelques dixièmes de seconde sur une machine normale). Par contre, s'il s'avérait que certains travaux interactifs étaient très lourds (quelques secondes, voir quelques minutes) alors il faudrait en effet songer à éviter la multiplication des sessions de ce type.
De manière générale, une transaction normale ne doit pas excéder quelques dixièmes de seconde. Au delà, soit le système est mal sizé, soit l'application est mal conçue.

Parfois, on voit des transactions interactives durer plusieurs minutes, il s'agit généralement de requêtes SQL qui pourraient être exécutées en batch. Cela n'est pas normal, c'est exactement le type de travaux que l'on doit lancer en batch afin de soulager les systèmes limités en puissance interactive et surtout rendre le plus rapidement possible la main à l'utilisateur.

Fabrice