Faire en sorte que le trafic soit fluide

autres approches. L’une consiste à ajuster la priorité des tâches d’envoi du journal à distance SLIC en coulisse. L’autre demande d’être plus efficace et d’employer la mémoire principale de la machine source comme zone de maquettage.

Ajuster la priorité peut être utile si vous devez équilibrer l’agressivité de votre tâche d’envoi asynchrone du journal à distance SLIC par rapport à un autre travail lui aussi en quête de ressources sur la machine de production. Bien que la priorité de cette tâche soit haute par défaut, vous pouvez l’ajuster en assortissant la commande HGRMTJRN du mot-clé SKPTY.

En outre, l’utilisation de la mémoire principale côté source comme zone de staging peut être intéressante pour maintenir la fluidité de l’écoulement dans le tuyau, parce qu’elle réduit le nombre de requêtes que le journal à distance sous-jacent doit honorer. Comparez-le à la voie pour véhicules rapides (à plusieurs passagers) sur votre autoroute urbaine favorite. En installant dans chaque véhicule plus d’un passager, le nombre total de véhicules en concurrence pour se placer dans cette voie est moindre. Et la voie rapide est fluide alors qu’on se traîne sur la voie normale.

Pour les utilisateurs du journal à distance, le cache de journal (validé par le mot-clé JRNCACHE sur la commande CHGJRN) est votre autorisation à utiliser la voie rapide. Il permet à plusieurs entrées de journal d’emprunter le fil à l’unisson et de se regrouper pour effectuer le trajet. Cette fonction contribue au bon écoulement du trafic.

La figure 5 illustre le principe. Elle montre trois jobs batch s’exécutant simultanément qui n’ont rien en commun (ils ne mettent même pas à jour le même fichier !) si ce n’est que l’ensemble total des objets mis à jour sur les trois jobs se trouve être associé avec le même journal. Une fois que l’option voie rapide a été validée, i5/OS fait le reste. Il détecte l’opportunité de partager le véhicule et regroupe toutes les entrées de journal qui font la queue à l’arrêt du bus (bien qu’elles soient associées avec des objets différents) dans le même paquet pour un voyage partagé sur le fil de communication.

Les résultats positifs sont multiples : meilleures performances côté source, meilleur point de référence sur le disque, utilisation plus efficace du tuyau de communication et moins d’overhead côté cible. Tout le monde est gagnant et il est difficile de faire mieux !

La figure 5 illustre le comportement du mode cache journal (notre voie rapide). Un buffer de mémoire principale (libellé A) accumule les entrées du journal au fur et à mesure qu’elles arrivent pour le compte de jobs multiples, toutes destinées au même journal. La chaîne d’entrée de journal résultante (libellée B) traverse le cache d’écriture IOA et va finalement vers le disque, à l’unisson.

Sans le comportement de cache induit du journal de mémoire principale, chacune de ces entrées de journal voyagerait seule vers le disque. Le même lot regroupé d’entrées de journal adjacentes (libellé C) qui voyageait vers le disque comme un ensemble, voyage aussi sur la ligne de communication en route vers le domicile éventuel de l’entrée sur la machine cible. Sans l’utilisation du cache de journal (une fonction facultative d’i5/OS connue comme option 42), chaque entrée du journal ferait individuellement le voyage sur le fil de communication, avec beaucoup moins d’efficacité. On voit donc que l’utilisation du cache logiciel journal améliore l’efficacité aux trois niveaux (A, B, C) et est particulièrement utile dans un environnement de journal à distance.

Qu’il s’agisse de séparer les moutons des chèvres, de placer une bifurcation sur la route, de réduire ce qui est envoyé, de surveiller les embouteillages, ou de tirer parti de la voie rapide, i5/OS vous apporte la réponse. Il propose un large éventail de choix pour peaufiner votre environnement de journal à distance afin de fabriquer du muscle et de perdre du gras.