Comment donc augmenter l’utilisation de la CPU ?

n’utilisant pas le multi-threading ne peut
utiliser qu’une CPU à  la fois. En supposant, pour l’instant, que le job puisse
occuper le processeur à  100 %, il manquerait 1.400 secondes (500.000 enregistrements
à  0,010 secondes/enregistrement représentent 5.000 secondes). Une heure comportant
3,600 secondes, la machine est en l’occurrence trop juste.

Toujours en supposant que le job peut utiliser le processeur à  100 %, il faut
réduire l’utilisation de la CPU et passer de 0,010 secondes par enregistrement
CC à  0,0072 secondes par enregistrement CC (c’est à  dire réduire de 28 %) pour
répondre aux besoins. Si cette réduction de l’utilisation de la CPU n’est pas
possible, il faudra davantage de temps CPU pour tenir le délai. Il faut donc qu’une
machine soit au moins 28 % plus rapide afin de disposer en une heure de l’équivalent
de 5.000 secondes du temps de CPU du système actuel.

Notre principal postulat est que le job en question peut occuper la CPU à  100
%. C’est rarement le cas (tout au moins au départ) en traitement batch de la base
de données : la plupart des travaux batch utilisent entre 2 et 8 % de la CPU.
Dans notre exemple, le job a utilisé 1.000 secondes de temps CPU en une heure,
soit un taux d’utilisation de 27,7%.

Comment donc augmenter l’utilisation de la CPU ? Réponse : en exécutant simultanément
de multiples jobs (grâce au parallélisme des jobs batch) en restructurant l’environnement
d’exécution de manière à  exécuter plus d’une copie du job en même temps.

Si le job unique utilise un certain pourcentage de CPU dans un environnement monojob
et si l’on veut augmenter le débit de l’application, l’objectif est d’exécuter
k copies du job, où k est égal à  100 divisé par l’utilisation CPU du job. Dans
l’exemple précédent, la CPU était utilisé à  27,7% (1000/3600), k serait donc d’environ
quatre (100/27,7). Il faut répartir la charge du traitement (les données en entrée,
par exemple) de manière égale entre les quatre jobs et les laisser s’exécuter.
Pour certaines applications, c’est possible à  réaliser avec la commande OVRDBF
(Override Database File) ; dans d’autres, il faut analyser et remanier l’application.

Et qu’adviendra-t-il si la valeur de k est tellement grande que l’on surcharge
le processeur en essayant de le faire fonctionner à  150 % ou plus ? Dans ce cas,
il faut disposer de davantage de temps de CPU, et donc passer à  un processeur
à  n voies. Les processeurs à  n voies ont de multiples CPU, ce qui donne n x 3.600
secondes de temps de CPU par heure (ou n secondes de temps de CPU par seconde).

Par conséquent, avec une demande de 5.000 secondes de temps de CPU pour effectuer
le job en une heure, il faut au moins un biprocesseurs, disposant de 7.200 secondes
de temps CPU par heure (3.600 secondes par heure et par CPU, multiplié par deux
CPU). Si l’on exécute cinq copies du job simultanément, le tout devrait s’exécuter
dans le délai prescrit et utiliser environ 70 % de la CPU (5.000/7.200).