Etant donné qu'une tâche SMP est susceptible d'accaparer les ressources du système, il faudra peut-être activer SMP uniquement pour les tâches hautement prioritaires. On peut contrôler l'utilisation de SMP d'un job au niveau individuel du job par le biais du paramètre DEGREE (la figure 3 présente les valeurs DEGREE possibles)
Contrôler SMP
de la commande CHGQRYA (Change Query Attributes) ou dans la V4R4 avec le fichier
QAQQINI et l’entrée PARALLEL_DEGREE de ce fichier (se reporter au manuel DB2 for
AS/400 SQL Programming (SC41-5611) pour obtenir de plus amples informations à
propos de la nouvelle fonction QAQQINI). On peut également contrôler SMP pour
toutes les tâches système à l’aide de la valeur système QQRYDEGREE.
Lorsqu’on utilise la valeur *OPTIMIZE au paramètre DEGREE, l’optimiseur de requêtes
choisit le niveau de parallélisme (en partie) selon la part de mémoire occupée
par la tâche dans le système sur lequel elle est exécutée. La « juste part » de
mémoire de la tâche équivaut à l’ensemble de la mémoire divisé par le niveau d’activité
de la mémoire. Les implications sont importantes lorsqu’on configure des sous-systèmes
et des pools mémoire pour les requêtes. Pour éviter ces problèmes :
· Exécuter les travaux de requête dans un pool mémoire séparé, prévu spécialement
pour le traitement des requêtes.
· Minimiser le niveau d’activité de l’ensemble en diminuant sa valeur Max Act.
· Utiliser des pools mémoire AS/400 partagés, avec l’option de mise en page définie
à *CALC.
· Si on utilise une forme quelconque d’auto-ajustement, il faut minimiser les
variations de taille à travers lesquelles l’ensemble peut être ajusté.
Un exemple
Imaginons qu’une requête impliquant la jointure de deux fichiers soit
soumise trois fois avec respectivement les conditions suivantes :
· CHGQRYA DEGREE(*NONE)
· CHGQRYA DEGREE(*NBRTASKS 3)
· CHGQRYA DEGREE(*MAX)
La requête est plus rapide mais utilise plus de ressources CPU
Etant donné qu’il n’existe aucun index permanent pointant sur le champ utilisé
pour la jointure, l’optimiseur de requêtes crée un index temporaire pour mettre
en oeuvre une jointure imbriquée en boucle des deux fichiers. Les tâches sont exécutées
en mode déboguage (STRDBG) ; ainsi, on reçoit les messages de l’optimiseur associés
à la requête. Le message CPI4321 de l’optimiseur, renvoyé dans le journal des
tâches, donne quelques indications sur le temps et les ressources utilisées dans
les trois cas CPI4321 : Access path built for ITEM_FACT.
Ce message indique la création d’un index temporaire pour traiter la jointure.
Cette création a utilisé SMP au niveau autorisé pour chaque tâche. La figure 4
illustre le fait que, lorsqu’on intègre plus de parallélisme, la requête est plus
rapide mais utilise plus de ressources CPU. Les ressources d’I/O disponibles sont
également importantes lorsqu’on augmente le niveau de parallélisme (en général,
les colonnes Disk I/O présentent également les chiffres des I/O accrus à mesure
que le parallélisme augmente. Cela dépend, bien sûr, de la quantité de données
résidant dans la mémoire. La figure 5 illustre les chiffres ayant l’effet inverse
dans la colonne Async I/O.
La figure 6 illustre le résultat de la commande Work With System Activity (WRKSYSACT)
pendant l’exécution du cas CHGQRYA DEGREE(*NBRTASKS 3). Les tâches DBL3Basexx
sont les tâches parallèles permettant d’assurer le traitement de la requête.
Figure 4 Plus de parallélisme = des requêtes plus rapides mais une utilisation plus importante de la CPU DEGREE(*NONE) DEGREE(*NBRTASKS 3)
DEGREE(*MAX) |
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.