L’effet de la contention de mémoire

en mémoire après que leur bloc d’appartenance ait été transféré du disque. (Mais
gardez à  l’esprit les mises en garde précédentes à  propos des pools de mémoire
*Calc et du blocage des programmes.) Dans un environnement de production, la contention
de mémoire peut être si haute qu’une page de fichier transférée en mémoire sera
écrasée avant la prochaine demande de données sur la même page.

De même, si la totalité du fichier ne tient pas en mémoire, les pages amenées
par les transferts antérieurs risquent d’être écrasées par les transferts suivants.
Dans de telles conditions, de grandes tailles de transfert pourraient ne pas réduire
suffisamment le nombre de demandes de transfert pour compenser le temps supplémentaire
nécessaire pour transférer de gros blocs.

Pour tester ce principe, j’ai réduit la taille de pool *Interact à  100 Mo, afin
d’empêcher que la totalité du fichier ne se trouve en mémoire. De ce fait, après
qu’un nombre suffisant de transferts ait rempli la mémoire disponible, un transfert
suivant écraserait la mémoire contenant les données d’un transfert précédent.
L’effet obtenu n’est pas exactement le même que lors de la contention entre des
jobs simultanés, mais il est approprié pour montrer comment régler les I/O pour
obtenir les meilleures performances possibles au fur et à  mesure que la mémoire
disponible se raréfie. La figure 8 montre les performances RPG en utilisant les
pools de mémoire *Calc et pas de blocage d’enregistrement de programme.
On voit que le nombre de demandes de transfert ne diminue que légèrement alors
que la taille de transfert est presque du quadruple. Il en résulte que les performances
baissent également avec des valeurs croissantes pour NbrRcds. Comparez ces résultats
à  ceux de la figure 6, où l’absence de contention de mémoire a entraîné beaucoup
moins de transferts et où les performances se sont améliorées avec de plus grandes
tailles de transfert.

OpnQryF (Open Query File) utilise le même optimiseur de requête que SQL

Quand la contention de mémoire est haute, un tri ODP (comme décrit précédemment)
peut être plus performant parce que la durée du tri est compensée, et au-delà ,
par le transfert plus rapide des données provenant du disque et par la possibilité
de bloquer les enregistrements pendant leur transfert dans les mémoires-tampons
du programme. Parce qu’avec un tri ODP tous les enregistrements dans un bloc de
transfert ou de mémoire-tampon sont traités immédiatement après le transfert ou
la copie des données, les pages contenant les données risquent moins d’être écrasées
avant l’utilisation des données, que quand on utilise un accès par clé.
Mais comment faire utiliser un tri ODP au RPG ? Il s’avère que la commande OpnQryF
(Open Query File) utilise le même optimiseur de requête que SQL, et donc on peut
utiliser la commande suivante pour bénéficier d’un tri ODP en utilisant des opérations
RPG Read :

OpnQryF File((Master)) +
KeyFld(MasterId) +
AlwCpyDta(*Optimize)

Bien entendu, il faut aussi utiliser une commande OvrDbf avec Share(*Yes) pour
partager l’ODP du fichier de requête quand on ouvre le fichier dans le programme
RPG. (Voir DB2 for AS/400 Database Programming, SC41-5701-03, pour des informations
sur l’utilisation de la commande OpnQryF). Lorsque j’ai utilisé cette méthode
avec le petit pool de mémoire, le débit était de 17.100 enregistrements par minute,
soit plus de deux fois les meilleures performances obtenues avec un accès par
clé. Souvenez-vous de la petite astuce suivante, peu connue, pour améliorer les
performances d’I/O RPG dans certaines situations :

On peut utiliser OpnQryF avec RPG I/O pour profiter du même optimiseur de requête
que SQL utilise pour optimiser les performances.

Signalons au passage que, quand la mémoire est abondante, l’utilisation de OpnQryF
pour ce test produit un débit maximum légèrement supérieur à  25.000 enregistrements
par minute, soit moins de la moitié du chiffre obtenu avec un chemin d’accès par
clé et une grande taille de transfert.
Quand j’ai exécuté les tests SQL dans un petit pool de mémoire, le résultat ODP
trié était de 18.600 enregistrements par minute et le résultat avec le chemin
d’accès par clé dépassait légèrement 12.000 enregistrements par minute. En général,
avec RPG ou SQL, il est important de bien comprendre l’environnement d’exécution
avant de choisir la technique d’accès.