L’utilisation d’ALLOCATE(*YES) peut réduire sensiblement le temps d’exécution du job

d’ALLOCATE(*YES) peut réduire sensiblement le temps d’exécution
du job.

Lorsque de multiples jobs ajoutent simultanément des enregistrements au même fichier,
le débit en souffre énormément. Les fonctions d’attribution d’espace de l’ASM
(Auxiliary Storage Management) du système passent un temps considérable à  augmenter
l’espace d’un fichier sur disque, au fur et à  mesure qu’on lui ajoute des enregistrements.
Pendant qu’un job étend un fichier base de données, les éventuelles requêtes d’autres
jobs pour étendre le même fichier doivent attendre la fin de la ou des requêtes
précédente(s) (indépendamment de la priorité). Le traitement d’extension d’espace
est, nécessairement, une fonction SLIC à  une seule file. Le parallélisme de traitement
est donc impossible ou presque.

Les outils de performances de l’AS/400 ne peuvent pas détecter explicitement ce
type de goulot d’étranglement. En cas d’extension d’espace simultanées multiples,
les données échantillons de Performance Monitor indiquent simplement que le job
a rencontré un temps d’attente supérieur à  la normale. Si on exécute la fonction
de trace de Performance Monitor, le « Lock Report » indiquera le problème comme
un blocage sur le fichier physique. Malheureusement, le même type de blocage peut
se produire pour de nombreuses raisons.

Selon le type de traitement exécuté, on a le choix entre deux procédures pour
éviter cet overhead. Dans le premier cas, on crée un nouveau fichier base de données
en sachant qu’il contiendra un nombre d’enregistrements donné. Quand on crée le
fichier avec CRTPF, on indique le nombre maximum d’enregistrements qu’il est supposé
contenir et on attribue la valeur (*YES) au paramètre ALLOCATE. On ordonne ainsi
au système d’allouer l’espace disque total requis par le fichier dés sa création
et on évite aux jobs de traitement de perdre du temps dans les routines d’extension
de fichier pendant l’exécution.

ALLOCATE(*YES) peut accélérer l’exécution de jobs batch simples et multiples.
Un récent test batch a fait grimper l’utilisation globale de la CPU de 7 % à  50
% simplement en utilisant ALLOCATE(*YES) au moment de la création des fichiers
base de données.

La seconde méthode pour diminuer l’overhead de l’extension d’espace s’applique
aux programmes applicatifs qui ajoutent des enregistrements à  un fichier base
de données existant. Il faut d’abord ajouter une seconde description du fichier
pour le programme de traitement et ouvrir cette description de fichier pour la
sortie uniquement. Ensuite, avant d’appeler le programme, émettre une commande
CL OVRDBF (Override Database) en précisant SEQONLY(*YES nnnn), où nnnn est le
facteur bloquant de sortie (c’est-à -dire 128 Ko divisés par la longueur d’enregistrement
égale nnnn). Le facteur de blocage doit avoir une valeur la plus proche possible
de 128 Ko sans toutefois dépasser ce nombre.

Si vous êtes en V4R4, vous pouvez installer la PTF MF24287 et IPLer la machine.
Cette PTF base de données permet aux fonctions d’allocation d’espace base de données
d’étendre les fichiers physiques d’un nombre supérieur au 1 Mo prévu par défaut.
La PTF ne fonctionne que si le programme applicatif utilise un traitement de sortie
séquentiel bloqué.

La PTF MF24287 provoque l’extension des fichiers inférieurs à  256 Mo de 10 % avec
un maximum de 2 Mo. Les fichiers de plus de 256 Mo sont étendus de 4 Mo à  chaque
fois qu’il faut de l’espace supplémentaire. Un test utilisant cette technique
a montré une augmentation de 50 à  80 % d’occupation. (Remarque : Si on pré-alloue
les fichiers physiques à  leur taille maximale au moment de leur création (c’est-à -dire
en indiquant ALLOCATE(*YES) sur la commande CRTPF), la PTF n’est pas nécessaire.)

A venir

Nous verrons dans un prochain article, faisant suite à  celui-ci:

? l’utilisation de SMP pour le traitement de la maintenance d’index
? l’utilisation de la fonction base de données « holey insert » pour améliorer le
traitement des ajouts d’enregistrements à  des jobs simultanés
? l’accélération du traitement avec SMAPP (System Managed Access Path Protection)
? l’utilisation de la commande OS/400 Sort (ou Format Data (FMTDTA))
? un nouvel axe de développement de la base de données de Rochester appelé QJOSPEED
(également connu sous le nom de « Joe Speed »)

L’ancien IBMer Rick Turner est un Consultant internationalement connu et spécialisé
sur les performances des systèmes AS/400. Il est co-auteur de l’ouvrage Mastering
AS/400 Performance (NEWS/400 Books, 1996).