DPS

très près de la vérité. Mais, ce qui n’est pas dit, et ne peut pas être dit, est que tous les jobs obtiendront leur part originellement prévue de la CPU, sans file d’attente excessive.

Avantage 2 de DPS. Le deuxième avantage de DPS est que les jobs de faible priorité, de type batch, auront une chance de progresser. C’est vrai mais cela n’atteint pas les objectifs de performances client de Company aBc. Pendant les périodes de charge de production de très haute priorité, les clients ne veulent pas, et ne peuvent pas, permettre que les 50 jobs batch de plus faible priorité obtiennent du temps de CPU au détriment du travail transactionnel de priorité supérieure.

Beaucoup d’utilisateurs considèrent la priorité des jobs comme un paramètre de contrôle leur permettant de définir quel job obtient la CPU en premier, lequel l’obtient ensuite, et ainsi de suite. DPS bat en brèche cet objectif en essayant de donner l’accès CPU à tous les jobs sans considérer l’importance relative du job telle que définie par l’utilisateur.

Avantage 3 de DPS. Le troisième avantage de DPS est que les jobs qui utilisent trop de CPU verront leur priorité réduite. Qu’entend-on par trop et comment le définir ? Le système d’exploitation estime qu’il y a trop d’utilisation de CPU quand un job a dépassé sa tranche de temps externe avant d’entrer dans un long état d’attente et quitte le niveau d’activité. Dans ce cas, DPS augmente la valeur de priorité du job, pour le déplacer en bas de la bande de priorité DPS suivante.
Autrement dit, le job est rétrogradé à une priorité de moindre importance. Quand cela s’applique aux jobs de Company aBc, un job de priorité 19 ou 20 qui utilise trop de temps de CPU est relégué à la priorité 23. Quand un job sort de sa longue attente suivante, sa valeur de temps de CPU de la tranche de temps externe est remise à zéro, sa priorité est remise à sa valeur d’exécution originale et, en ce qui concerne DPS, l’usage par la CPU de la tranche de temps externe du job recommence.

Il y a ici un point intéressant qui s’applique aux applications de Company aBc. Vous vous souvenez que les applications de la firme utilisent les files d’attente des utilisateurs pour communiquer entre les jobs. Son application de l’accès aux files d’attente des utilisateurs ne force pas un job à entrer dans une longue attente quand le job fait une instruction MI DEQ sans un message de retrait de la file d’attente. Dans une telle situation, le job attend à son niveau d’activité jusqu’à ce qu’un message arrive. Par suite d’une instruction DEQ de file d’attente des utilisateurs non satisfaite, le job n’entre jamais dans une longue attente.

Quand un message arrive dans la file d’attente, il en est retiré et traité, une réponse est envoyée et le job attend le message suivant. Le job utilise la CPU quand il traite le message et DPS rétrograde le job quand il dépasse sa tranche de temps externe (la valeur par défaut standard est de deux secondes). Pour Company aBc, le DPS change la priorité du job de traitement de sortie de 19 à 23. Comme les jobs pilotés par file d’attente des utilisateurs n’entrent jamais dans une longue attente, ils ne reviennent jamais à leur priorité originale de 19. Cette disparité chez Company aBc provoque une nette dégradation des performances quand le système est confronté à la forte charge de travail.

La dégradation des performances se manifeste parce que beaucoup des jobs de traitement de sortie de priorité 19 originaux fonctionnent en réalité en priorité 23 et, par conséquent, rencontrent des délais de file d’attente de CPU inacceptables dès lors que des jobs de plus haute priorité (comme les jobs de traitement d’entrée de priorité 19 et 20) obtiennent l’accès à la CPU avant que le job de traitement de sortie n’en ait la possibilité.

Le critère du temps de réponse de traitement de la sortie chez Company aBc se situe au niveau des millisecondes. Compte tenu de la nature des transactions client de la société, 50 millisecondes d’attente pour une réponse est souvent trop long. Pendant la période de forte demande, Company aBc constate une distribution des temps de réponse allant de 100 millisecondes à 3 secondes : beaucoup trop long.

Avantage 4 de DPS. Le quatrième avantage de DPS est que le temps de réponse/débit des jobs se comportera à beaucoup d’égards comme la planification à priorité fixe. Ce n’est pas toujours le cas, comme la discussion précédente le montre, particulièrement quand la CPU fonctionne à pleine capacité.

Compte tenu de tout cela, quelle est la meilleure approche ? Vous pourriez choisir de ne rien changer, changer les priorités des jobs dans la plage non ajustable, ou désactiver DPS. Ne rien changer n’est pas très judicieux parce que le système continuera à souffrir de ralentissements inacceptables. Pour ce qui est de désactiver DPS, je ne pense pas que ce soit une solution. Je ne l’ai jamais recommandé et je ne vais pas le faire ici. L’une des raisons pour laisser DPS actif est qu’il a une fonction « detect the runaway job » (détecter le job emballé) qui n’existe que s’il est actif – par conséquent, laissez-le activé.

Réattribuer aux jobs de traitement de sortie une priorité de 9 au lieu de 19 corrige le problème de priorité de CPU de Company aBc. Cette approche fonctionne parce que DPS ne s’intéresse pas aux jobs dont les priorités sont de 9 ou moins et les laisse livrés à eux-mêmes. Cette solution permet aux jobs de traitement de s’exécuter selon les besoins avec presque pas de temps de file d’attente de CPU, quelle que soit la charge du système. Conjointement à ce changement, Company aBc a réattribué les priorités du System Operator de 10 à 5. Cela préserve le standing relatif de l’opérateur dans la hiérarchie des priorités de CPU non ajustée.