> Tech > SMP et traitements parallèles sur AS/400

SMP et traitements parallèles sur AS/400

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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

SMP et traitements parallèles sur AS/400

Lorsqu’on ajoute des enregistrements à  un fichier sur lequel pointe un certain
nombre d’index, le système doit mettre à  jour les index pour prendre en compte
les données ajoutées. Avant la V4R3, cette maintenance était réalisée par le biais
d’une seule tâche.

Ainsi, l’ajout de gros volumes d’enregistrements à  un fichier base de données
possédant de nombreux index pouvait alors provoquer une baisse des performances
et ce, en raison de la nature séquentielle de la maintenance des index. Depuis
la V4R3, le système peut gérer les index en parallèle pendant que les tâches d’arrière-plan
du serveur de base de données exécutent une tâche de maintenance d’index concurrente.
Pour bénéficier de cette nouvelle fonction de gestion d’index, il faut :

§ Effectuer des insertions par blocs (avec un minimum de huit enregistrements)
dans le programme ou l’instruction SQL. Plus le facteur de blocage est grand,
plus on tire profit de la maintenance parallèle d’index
§ avoir au moins deux index définis sur le fichier base de données
§ installer et activer SMP via le paramètre QQRYDEGREE ou CHGQRYA
§ disposer d’un espace mémoire approprié et d’une CPU de puissance adéquate pour
traiter la charge de travail accrue

Téléchargez gratuitement cette ressource

Guide de Cloud Privé Hébergé

Guide de Cloud Privé Hébergé

Comment permettre aux entreprises de se focaliser sur leur cœur de métier, de gagner en agilité, réactivité et résilience en s’appuyant sur un socle informatique performant, évolutif et sécurisé ? Découvrez les avantages des solutions de Cloud Privé hébergé de la CPEM.

Tech - Par iTPro.fr - Publié le 24 juin 2010