Améliorer et ajuster la performance de l’IFS, 1ère partie

Les conseils généraux suivants sont un bon point de départ pour améliorer les performances du système de fichiers et peut-être même les performances globales du système.

1. Utiliser les UDFS sur les ASP
Les UDFS sont similaires aux systèmes de fichiers racine et QOpenSys en ce qu’ils sont tous construits sur la même architecture physique sous-jacente. Ils sont d’ailleurs tellement semblables que beaucoup d’utilisateurs ne savent pas exactement ce qu’est un UDFS, ce qu’il fait, ou pourquoi ils devraient l’utiliser. Cela explique pourquoi les UDFS sont généralement sousutilisés, malgré leurs fonctions uniques et importantes. Pour commencer, ils offrent plus de souplesse et de contrôle parce que les utilisateurs peuvent les créer à leur goût et les monter pratiquement n’importe où. Ils sont aussi le seul moyen d’accéder aux fichiers stream et aux répertoires qui se trouvent dans les ASP (auxiliary storage pools) utilisateur et indépendants. Mieux encore, les UDFS peuvent bénéficier aux performances..

La sous-utilisation des UDFS fait que les données utilisateur du système de fichiers sont souvent situées dans le système de fichiers racine sur l’ASP système (c’est-à-dire, l’ASP numéro un). De plus, la plupart des données du système d’exploitation sont aussi sur l’ASP système. La présence de toutes ces données sur un seul ASP signifie que la contention de lecteur disque entre les données utilisateur et les données système est fort probable, résultant généralement en un ralentissement des performances système..

En général, il y a contention de lecteur de disque quand plusieurs jobs lisent ou écrivent des données simultanément. Dans ce cas, un ou plusieurs des jobs peuvent être contraints d’attendre en ligne que leurs données soient lues ou écrites, parce que le disque peut être occupé à satisfaire d’autres requêtes. Ainsi, si un disque est en train d’écrire des données système et si vous demandez une lecture de données utilisateur, il vous faudra peut-être attendre. Généralement, l’attente est courte, mais de petites attentes mises bout à bout peuvent diminuer les performances globales du système.

Le fait de déplacer vos données à haute utilisation dans un UDFS sur un ASP (2-255) plutôt que l’ASP système (1) consacre le(s) lecteur(s) de disque(s) pour l’ASP à vos données et améliore par conséquent les performances. Et cela empêche les autres activités du système d’exploitation de lutter pour l’usage des lecteurs de disques, ce qui améliore les performances du système de fichiers et du système en général. Pour bénéficier des performances supérieures de l’UDFS, vous devez équiper votre système d’un ASP supplémentaire (2-255). Cela étant fait, il est facile de travailler avec un UDFS. Vous devez d’abord créer l’UDFS, puis le monter. Une fois l’UDFS monté (le remontage est nécessaire après chaque IPL), les opérations IFS standard peuvent être effectuées sur les données de l’UDFS. Vous pouvez aussi démonter les UDFS pour empêcher les utilisateurs d’intervenir sur les données. La création, le montage et le démontage de l’UDFS peuvent s’effectuer à partir d’iSeries Navigator ou avec les commandes CRTUDFS (Create User-Defined File System), MOUNT (Add Mounted File System) et UNMOUNT (Remove Mounted File System).

Par exemple, dans la figure 1, j’ai créé un UDFS (example. udfs) dans le répertoire /dev/QASP02. Cela place les données UDFS sur ASP 2. La propriété Where Mounted indique que l’UDFS est monté sur le répertoire /foo. Il s’en suit que toute opération IFS effectuée sur le répertoire /foo ou sur les objets dans sa sous-arborescence, agit en fait sur les objets présents dans l’UDFS sur ASP 2.

Pour plus d’informations sur les UDFS, visitez le V5R3 iSeries Information Center (publib.boulder.ibm.com/html/ as400/infocenter.html) (dans la barre de navigation, cliquez sur Files and file system|Integrated file system|Work with file systems|User-defined file systems) et ASP (cliquez sur Systems management|Disk management|Disk management concepts|Disk pools).

2. Minimiser la contention des objets du système de fichiers
La contention des objets du système de fichiers se produit quand deux, ou plus, files de jobs demandent simultanément la même ressource interne du système de fichiers. Cela se produit couramment quand de multiples files opèrent en même temps sur des données du même système de fichiers.

L’exemple suivant permet de mieux comprendre une même contention d’objets.

Dans la figure 2, nous supposons que le répertoire /Build est utilisé dans une application multifile. Chaque file dans l’application crée, écrit, ferme et supprime rapidement son propre ensemble de fichiers stream dans le répertoire /Build pour construire rapidement une base de données d’informations client. Cette situation se traduit par une contention d’objets sur le répertoire /Build. Il y a contention quand les fichiers stream sont créés et supprimés, parce que ces opérations requièrent les mêmes ressources internes du système de fichiers sur le répertoire /Build pour effectuer une mise à jour de lien. La lutte pour ces ressources impose aux files d’attendre leur tour avant d’effectuer une mise à jour de lien. Cet engorgement ralentit bien sûr le déroulement de l’application.

Le répertoire /BuildBetter de la figure 2 présente une meilleure conception. Ici, chaque file opère dans son propre répertoire, /Thread X, sous le répertoire /BuildBetter. Cette structure empêche les files de s’affronter pour obtenir les ressources d’un répertoire parent commun et, par conséquent, élimine la contention d’objets, supprime l’engorgement et, par voie de conséquence, rend l’application plus performante.

Un test de performances a révélé que le fait de supprimer la contention d’objet avec le modèle de répertoire /BuildBetter a amélioré les performances de l’application exemple d’environ 23 % en moyenne. Le test de performances a mis en oeuvre cinq files dont chacune créait, écrivait (16 Ko de données), fermait et supprimait 1 000 fichiers stream. Dans le test de contention d’objets, les files travaillaient toutes dans le même répertoire, /Build. Pour le test sans contention, les files travaillaient chacune dans leur propre répertoire sous /BuildBetter. Pour réduire la contention d’objets, la première étape consiste à analyser le mode d’utilisation des données du système de fichiers. Si vous trouvez des données sur lesquelles plusieurs files pourraient opérer simultanément (par exemple, des files multiples lisant/ écrivant les mêmes octets dans un fichier stream simultanément ou des files multiples ajoutant, supprimant ou renommant des liens dans le même répertoire simultanément), la contention d’objets est très probable.

Il est plus difficile de réduire la contention que de la trouver. La correction première consiste à s’assurer que les files n’opèrent pas sur les données du même système de fichiers en même temps. Mais c’est plus facile à dire qu’à faire. Parfois, comme dans l’exemple précédent, une légère restructuration des données du système de fichiers suffit pour régler le problème. D’autres cas nécessiteront des changements applicatifs. Mais il est clair que la réduction de la contention d’objets du système de fichiers est un pas décisif vers l’amélioration des performances.

3. Optimiser les performances de la journalisation et de l’audit utilisateur
La journalisation et l’audit utilisateur du système de fichiers sont souvent des fonctions critiques inévitables. Mais ce sont des fonctions lourdes qui affectent les performances du système de fichiers et du système tout court. C’est pourquoi il est important de soigner tout particulièrement la journalisation et l’audit utilisateur. En général, on peut y parvenir en réduisant ce qui est journalisé et audité par l’utilisateur et en prenant des mesures susceptibles d’améliorer les performances de journalisation utilisateur.

Pour améliorer les performances de journalisation utilisateur, on pourrait omettre les entrées de journal open, close et fsync [c’est-à-dire, OMTJRNE(*OPNCLOSYN)] sur la commande STRJRN (Start Journal), parce que ces entrées contribuent peu à la récupération d’un objet. Egalement, réfléchissez- y à deux fois avant de mettre à Yes l’attribut new objects inherit journaling, parce que cela pourrait aboutir à un grand nombre d’objets journalisés sur le même journal, avec pour conséquence la contention du lecteur de disque. En outre, pour contribuer à réduire la contention du lecteur de disque, il est bon d’isoler le récepteur du journal de son propre ASP.

Pour l’audit, veillez à ce que seules les opérations dignes d’intérêt y soient soumises. L’audit généralisé crée de nombreuses entrées et beaucoup d’overhead.

L’application de ces conseils spécifiques devrait déjà améliorer les performances. Attention tout de même à ne pas réduire la journalisation et l’audit utilisateur jusqu’au point où ils ne répondraient plus aux critères de haute disponibilité et de sécurité.

Pour plus d’informations sur les performances de la journalisation utilisateur, visitez le V5R3 iSeries Information Center (cliquez sur Systems management|Journal management|Local journal management|Journal management concepts|Journal management and system performance) et d’audit (cliquez sur Systems management|System values |System value categories|Auditing).

4. Optimiser les performances de sauvegarde et de restauration
Au fur et à mesure que les systèmes de fichiers contiennent plus de données, les performances de sauvegarde et restauration (S/R) des données deviennent plus importantes. C’est pourquoi les ingénieurs IBM ont beaucoup travaillé sur ce sujet. Tout d’abord, pour savoir à quoi vous attendre raisonnablement en matière de performances S/R du système de fichiers, reportez-vous au chapitre 15 de la V5R2 et V5R3 iSeries Performance Capabilities Reference (ibm.com/servers/ eserver/iseries/perfmgmt/resource.htm). Ces manuels de référence contiennent un large éventail de données sur les performances S/R des systèmes de fichiers.

Si votre niveau de performance n’atteint pas les chiffres présentés dans les manuels, vous avez probablement une certaine marge d’amélioration. Vous pouvez commencer par utiliser des répertoires *TYPE2 (sur lesquels je reviendrai dans la suite de cet article) et par réduire ou éliminer l’audit et le scanning pendant les opérations de S/R. Par ailleurs, vous devriez suivre les conseils de performances S/R des systèmes de fichiers tels qu’ils figurent dans l’IFS backup experience report dans le V5R3 iSeries Information Center (cliquez sur Files and file system|Integrated file system|Related information|Experience reports|Backing up the Integrated File System). Si aucun de ces conseils n’apporte l’amélioration souhaitée, il faudra peut-être envisager un matériel plus rapide (lecteurs de disques ou de bandes).