Utiliser l’Expert Cache

pagination du pool de stockage pour une performance optimale », selon IBM. Cependant, ma propre recherche a dévoilé un secret peu connu de ce paramètre : avec *CALC, vous pouvez utiliser toute mémoire disponible du pool partagé pour stocker les données requises pour un job. Plus il y aura de mémoire disponible, mieux l’Expert Cache fonctionnera. Quand vous utilisez l’Expert Cache, considérez votre système comme « l’expert » capable de reconnaître les données qu’un job devra garder en mémoire.

Toutefois, la tâche d’ajustement de performance automatique ne reconnaîtra nullement la mémoire utilisée par l’Expert Cache ; et donc le système peut enlever de la mémoire du pool partagé pendant que les jobs s’exécutent. Pour éviter cela, augmentez les tailles de pools minimales de vos pools partagés suffisamment pour empêcher le tuner automatique d’enlever le cache supplémentaire. Généralement, l’Expert Cache aura l’effet le plus bénéfique sur un job unique de longue exécution ou sur une suite de jobs batch s’exécutant dans le même pool partagé. Si ces jobs se déroulent en dehors des heures d’ouverture normales, vous pouvez ajuster la configuration de la charge de travail de manière à favoriser les pools partagés intervenant dans les jobs batch en question.

Initialement, je redoutais le coût en CPU de l’utilisation de l’Expert Cache. Mais j’ai constaté qu’il n’y a pas d’impact, aussi vous pouvez utiliser *CALC sans vous soucier d’une perte de performances. Si vous configurez votre système pour utiliser l’Expert Cache et si vous ne voyez pas d’amélioration du débit de vos jobs batch, essayez d’augmenter fortement la quantité minimale de mémoire disponible dans un pool partagé exécutant des jobs batch (comme pour tout changement de la performance système, ne modifiez qu’une chose à la fois, évitez d’effectuer des changements uniques d’une importance telle qu’ils puissent réduire gravement la performance, et définissez les priorités afin que la production normale reste satisfaisante).