par James Steward et Dan Cruikshank
Le parallélisme donne un réel coup de pouce aux performances. Certes, mais est-ce
toujours dans la bonne direction ?
Peu après les problèmes systèmes survenus chez e-Gads (voir l'article "The Case
of the Missing Index", NEWS/400, août 2000), nous avons discuté, Dan et moi-même,
la nécessité de publier quelques informations de base à propos du parallélisme
sur AS/400. Il faut se souvenir que les dysfonctionnements d'e-Gads étaient provoqués
(en partie) par le parallélisme des requêtes. La valeur système QQRYDEGREE était
définie pour utiliser le parallélisme des I/O (*IO). La requête à problème tournait
en haute priorité et le gros fichier d'historique financier détaillé existait
sur la plupart (si ce n'est sur tous) des bras disque. Ainsi, la mise en oeuvre
de la requête de l'optimiseur des requêtes lisait de manière dynamique depuis
ces bras en parallèle, et provoquait la dégradation des autres travaux du système.
La situation d'e-Gads est un parfait exemple de la manière dont le parallélisme
peut entraîner des difficultés si on ne prend aucune précaution.
La stratégie de croissance d'IBM pour les AS/400 haut de gamme a été de mettre
en place des systèmes plus grands, utilisant plusieurs processeurs. Cette approche
améliore considérablement le traitement interactif et les taux de transmission
des transactions associés. En revanche, pour les traitements classiques des travaux
par lot à une seule unité de traitement, cela signifie des systèmes largement
sous-utilisés.
Le parallélisme peut entraîner des difficultés si on ne prend aucune précaution
Lorsque les systèmes bi-processeurs sont apparus, Dan et moi avons commencé à
répondre à des questions du genre : "Pourquoi ne puis-je pas exploiter mon système
à plus de 50 % d'utilisation de CPU pendant les heures creuses ?" Nous avons encouragé
les traitements parallèles et nos analyses sur la conception d'applications étaient
centrées sur l'utilisation de cette fonctionnalité. Avec des systèmes à 4, 8 et
12 processeurs, les traitements parallèles deviennent encore plus judicieux. Nous
recevons encore des appels mais, aujourd'hui, avec un système à 12 processeurs,
les questions ressemblent à ceci : "Pourquoi ne puis-je pas exploiter mon système
à plus de 10 % d'utilisation de CPU pendant les heures creuses ?"
Les demandes des requêtes impliquent en général, le traitement de gros volumes
d'I/O. Ainsi, le parallélisme, tout comme les traitements par lot, profite du
traitement des requêtes sur AS/400. Les améliorations récentes apportées au système
ont été centrées sur les traitements parallèles ; il existe même une fonction
OS/400 téléchargeable permettant d'étendre l'utilisation du parallélisme du système.
Si elle est installée, la fonction SMP (Symmetrical Multiprocessing) permet de
diviser automatiquement certains travaux de requête en plusieurs tâches pouvant
être traitées simultanément par plusieurs processeurs. J'entends, par travaux
de requête, toutes les requêtes utilisant l'optimiseur de requêtes. Par conséquent,
SQL, Query/400, OPNQRYF, ODBC, l'API de requêtes, DRDA (Distributed Relational
Database Architecture) et JDBC figurent parmi les interfaces tirant profit de
SMP.
| Méthodes d'accès utilisant le parallélisme | |
| Méthodes d'accès aux données sans clés Parallel table scan Parallel skip sequential Parallel pre-fetch Parallel table pre-load Méthodes d'accès aux données avec clé Key positionning and parallel key positionning Key selection and parallel key selection Parallel index pre-load |
Parallélisme SMP SMP I/O I/O Parallélisme SMP SMP I/O |
La tâche de l'optimiseur de requêtes consiste à développer l
