Knowledge-on-Demand HP-UX 11i : découvrez, auprès de nos ...

Laforge

Sujets

• Orbite cristallographique
• Linternaute.com
• Résultats électoraux de l'extrême gauche en France
• V382 Velorum
• Temps de réponse (électronique)
• Dialogue territorial

Informations

• Publié par: Unjya
• Nombre de lectures: 65
• Langue: Français

Extrait

Knowledge-on-Demand HP-UX 11i :

découvrez, auprès de nos laboratoires, les meilleures pratiques

pour optimiser vos performances

Série pour le personnel de déploiement

Configuration de HP-UX 11i v3 pour les installations SAP --

Transcription d'un sujet de webcast

Bienvenue dans Knowledge on Demand. Je m'appelle Bob Wynne et je vais vous expliquer comment tirer le

meilleur parti des serveurs HP-UX avec le logiciel SAP. Comme le montre cette diapositive d'introduction, j'évolue

au sein du laboratoire de recherche sur le noyau HP-UX de Cupertino, en Californie. Voilà plusieurs années que

je travaille ici et depuis environ six ans, je m'occupe principalement des performances SAP avec pour objectif

d'atteindre les meilleurs résultats de benchmark sur HP-UX.

[DIAPOSITIVE SUIVANTE]

Pour commencer, je vais présenter ce dont nous allons parler aujourd'hui. Les performances SAP constituent un

vaste sujet et j'aimerais me concentrer sur les processeurs Itanium et les systèmes HP-UX, notamment les grands

systèmes à cellules. Les données contenues dans cette présentation reposent essentiellement sur des expériences

que nous avons menées en laboratoire ainsi que sur notre expérience du benchmark. De toute évidence, il existe

d'importantes différences entre l'univers des benchmarks et celui des installations clients. Le fait qu'en matière de

bencharking nous utilisions des charges de travail très uniformes et bien comprises en est l'une des principales.

Cela permet de parfaitement dimensionner et configurer les bases de données et d'obtenir un très faible taux

E/S. Cela permet également de répartir la charge de travail de manière très uniforme vers les différents

processeurs pour en tirer le meilleur parti ainsi que de leur mémoire cache. Je me rends bien compte que ce n'est

pas le cas de la plupart des applications commerciales dont la charge de travail varie considérablement au fil du

temps et ne s'avère pas toujours prévisible. Ceci dit, je sais que tout ce que nous apprenons en matière de

performances peut être utilisé pour améliorer les performances réelles sur le terrain. En ce qui concerne les

grosses machines dotées d'accès mémoire non-uniformes, notamment, l'optimisation des processeurs et de la

mémoire permet d'en améliorer considérablement les performances. Sur le grand benchmark à deux niveaux

réalisé sur un Superdome 128 c

œ

urs voilà un an, et qui regroupe toujours, en date de janvier 2008, les résultats

SD à deux niveaux les plus complets jamais publiés, même les goulets d'étranglement de base de données et

d'entrées/sorties ont été éliminés, nous avons atteint une utilisation des processeurs proche de 100 % et réussi à

améliorer les performances de près de 50 % en tirant pleinement parti de la mémoire locale de cellule et en

optimisant l'efficacité des processeurs Itanium. Au cours de cette présentation, je ne vous parlerai pas des outils

visant à mesurer les performances ni de la manière de dimensionner les applications SAP.

Je ne vous parlerai pas non plus de l'analyse des goulets d'étranglement SAP ou HP-UX ni de la configuration de

la base de données. De nombreux éléments de référence couvrent déjà ces sujets.

[DIAPOSITIVE SUIVANTE]

Pour cette présentation, je partirai du principe que les systèmes sur lesquels nous nous penchons ont déjà été

configurés en termes d'entrées/sorties du disque, de configuration de la base de données et d'utilisation des

processeurs. De toute évidence, votre utilisation ne situera pas entre 95 et 100 % comme lors de nos

benchmarks, mais plutôt à un niveau compris entre 20 et 30 %, niveau auquel vous ne devriez pas rencontrer de

problèmes de performances. Je vais partir du principe que vous comprenez bien votre application. Ce point

semble évident, mais avant de consacrer, par exemple, des processeurs donnés à une instance SAP, vous devez

connaître le volume de travail généré par cette instance, le nombre d'utilisateurs qu'il doit prendre en charge,

savoir si la charge de travail varie considérablement à certains moments de la journée ou du mois. Il vous faut

bien comprendre votre application. Je vais également partir du principe que vous disposez de connaissances de

base sur l'administration et les outils d'analyse SAP, sur l'administration et la configuration du système HP-UX

ainsi que sur l'architecture de l'ordinateur.

[DIAPOSITIVE SUIVANTE]

Cette présentation a pour principal sujet l'optimisation de l'efficacité du processeur. Elle doit vous permettre

d'exécuter le plus d'instructions possible par cycle d’horloge pour réduire le cycle par instruction tout en veillant à

ce que les instructions exécutées vous soient particulièrement utiles. D'une manière plus spécifique, je vous

parlerai des défauts de TLB, de la manière de les réduire et de leurs effets sur les performances. Ensuite, je

détaillerai les questions de latence de la mémoire. Je passerai alors en revue quelques consignes en matière de

configuration des instances SAP reposant sur ces principes avant de vous parler succinctement de la

configuration du système d'exploitation HP-UX pour SAP. Enfin, je me pencherai sur la configuration des

applications multithread. Pour le moment, le noyau R3 n'est pas multithread. Aussi, cette dernière section

s'adressera plus particulièrement aux utilisateurs d'applications SAP liveCache ou java, comme les portails SAP.

[DIAPOSITIVE SUIVANTE]

Je vais donc commencer par vous expliquer comment limiter les défauts de TLB et vous donner quelques

informations générales sur le sujet. Lorsqu'un processeur exécute des instructions, les opérandes d'adresses des

instructions correspondent, bien évidemment, aux adresses virtuelles et doivent être traduits en adresses de

mémoire réelle avant d'être exécutées. Pendant des années, bien avant que je n'exerce ce métier, le concept de

Translation Look-aside Buffer (TLB) a été implémenté pour accélérer le processus de traduction des adresses. Les

processeurs Montecito actuels sont dotés de 64 entrées TLB de premier niveau dans lesquels les traductions

d'adresses les plus récemment utilisées sont mises en mémoire cache par pages de 4K. Elles sont réparties entre

32 adresses pour les instructions et 32 adresses pour les données. De plus, il existe 256 entrées de TLB de niveau

un réparties de manière uniforme : 128 pour les données et 128 pour les instructions. . Il est intéressant de noter

que chacune de ces entrées correspond à une page virtuelle et que 12 tailles de pages différentes sont prises en

charge, s'échelonnant de 4 Ko à 4 Go.

Bien évidemment, plus la taille de la page est importante, moins il vous faut d'entrées pour mapper une plage de

mémoire physique. Vous pouvez vous attendre à trouver 90 % d'informations non trouvées dans le premier

niveau, et plus de 99 % dans les deux premiers niveaux combinés. Même si le processeur ne trouve pas

l'adresse dans le TLB, vous avez 75 % de chances de trouver la traduction avec le matériel dans une table de

page hachée.

Mais si le processeur doit utiliser le logiciel pour effectuer la traduction, les performances en sont affectées.

D'après des mesures prises lors de l'exécution de SAP sur un rx6600 à huit c

œ

urs, un taux de défaut de TLB

s'élevant à deux pour 1 000 instructions, ce qui semble peu, peut contraindre le système à utiliser 7 % de son

temps dans le gestionnaire de déroutement des informations non trouvées. En réduisant ce taux d'informations

non trouvées à, disons une pour 10 000 instructions, ainsi que le temps consacré au gestionnaire de déroutement

des informations non trouvées en conséquence, les performances en sont considérablement affectées. Petite

remarque : chaque programme exécutable est accompagné d'une indication pour le système d’exploitation

concernant ses tailles de pages préférées pour les données et les instructions. Ceci est défini lors de la

compilation du programme, vous pouvez modifier cette indication à l'aide de la commande chatr.

Le tableau bleu répertorie les résultats issus de l'exécution du benchmark SAP SD à l'aide d'indications de tailles

de pages différentes pour le programme exécutable principal, disp+work. Là encore, ces données proviennent

d'un rx6600 à huit c

œ

urs affichant une charge relativement élévée de 2 050 utilisateurs SD. Lorsque disp+work

est utilisé pour des pages de 4 Ko, les performances s'avèrent des plus médiocres. Le système passe plus de

7 % de son temps dans le gestionnaire de déroutement ; le temps de réponse tourne autour de quatre secondes

et le débit est légèrement inférieur à 9 000 SAP, ce qui correspond à environ 150 étapes de dialogue seconde.

A l'inverse, si vous consultez la dernière colonne de ce tableau, vous constatez que lorsque le programme

exécutable est utilisé pour des pages plus volumineuses, le temps de réponse passe à

1,4 seconde et le débit augmente de 20 %. Heureusement, avec HP-UX 11i v3, la taille des pages virtuelles par

défaut est passée de 4 Ko à 16 Ko. Ainsi, si vous compilez un programme sans indication de taille de page,

par défaut, comme indiqué dans le programme exécutable, le système d'exploitation utilise des pages de 16 Ko

au moment du chargement en mémoire du programme.

Mais surtout, à partir de la version 620 ou 640, le noyau R3 SAP pour HP-UX a été compilé avec des indications

correspondant à des instructions de 4 MO et des tailles de pages de données de 16 Mo. Pour les benchmarks,

nous utilisons des pages plus volumineuses, mais comme vous pouvez le constater dans les deux dernières

colonnes de ce tableau, cela ne change pas grand-chose. En revanche, si vous exécutez une version antérieure

de HP-UX, de même qu'une version antérieure de SAP, veillez à vérifier la taille des pages. (Exécutez la

commande chatr sur une copie de disp+work qui n'est pas en cours d'exécution.)

Vous pouvez également surveiller l'efficacité des TLB pour un processus spécifique ou le système entier à l'aide

de Caliper. Si vous utilisez des tailles de pages par défaut, le recours à la commande chatr pour modifier ces

indications peut vous être d'une aide précieuse. Mais attention, l'utilisation de la mémoire et la taille des pages

virtuelles imposent un compromis, comme vous pouvez le constater dans la colonne la plus à droite illustrant le

pic d'utilisation de la mémoire. Quelle que soit l'indication en matière de taille des pages, les entrées/sorties ne

tentent jamais d'utiliser une page virtuelle plus volumineuse que celle que peut utiliser l'application, mais il arrive

souvent qu'un processus ne fasse pas référence à tout son segment de données privées ou aux segments de

mémoire partagée qui lui sont associés. Ainsi, les entrées/sorties allouent d'importants segments de données à un

moment, et tous n'étant pas indispensables, la mémoire peut en être affectée.

Dans le cas de SAP, le recours à disp+work pour les pages les plus volumineuses requiert environ 25 % de

mémoire en plus que les pages de 16 Ko. Cette mesure a été prise sur le benchmark SD avec une charge

élevée. Sur un système relativement inactif, la différence en termes d'utilisation de la mémoire s'avère

généralement plus nette.

Permettez-moi une autre remarque : pour une bonne gestion de la mémoire, surveillez toute utilisation élevée de

la mémoire étendue de SAP avec la transaction ST02. Si elle affiche une valeur nettement inférieure à 100 %,

essayez de réduire le paramètre em/initial_size_MB pour économiser de la mémoire.

Vous pouvez également économiser de la mémoire en combinant les différentes réserves de chaque instance d'un

même segment de mémoire partagée. Il est enfin possible de réduire le volume de mémoire étendue requis par

une instance en limitant le nombre de processus métier, de même que le paramètre em/block_size_KB. Essayez

surtout de réduire le nombre de processus métier, sujet sur lequel je reviendrai un peu plus tard.

[DIAPOSITIVE SUIVANTE]

Penchons-nous à présent sur les informations non trouvées dans le cache. Souvenez-vous qu'il est ici question

d'essayer d'améliorer l'efficacité du processeur en exécutant des instructions utiles, et non pas, par exemple,

celles du gestionnaire d'informations non trouvées, et en limitant les arrêts du processeur le nombre de fois où le

processeur s’arrête. Ces blocages sont, bien sûr, essentiellement dus aux délais de chargement des données et

instructions à partir de la mémoire ainsi qu'aux délais de stockage des données dans la mémoire. Si les données

se trouvent déjà dans la hiérarchie du cache du processeur, le nombre de cycles gaspillés, en attente de mémoire

ou en cas d'hyper-threading et de basculement vers un autre thread matériel, est limité. Dans le cas des

installations SAP, même celles à deux niveaux pour lesquels des processus métier SAP et des processus de

données SAP partagent les mêmes processeurs, le cache d'instructions ne présente pas de problème. En effet,

disp+work dispose d'une excellente localité de référence. Pour le meilleur comme pour le pire, un important

pourcentage des cycles processeur exécutant SAP est utilisé dans quelques modules d'interprétation ABAP et

routines de données de libc, comme memcmp() et memcpy().

Notez que le moteur SAP R3 passe le plus clair de son temps à interpréter le code ABAP. Dès lors, du point de

vue des performances, la question à se poser est la suivante : « Comment limiter les informations non trouvées

dans le cache de données ? » Bien évidemment, la manière dont l'application est conçue et compilée y joue un

rôle important. En tant qu'administrateur système, vous disposez de différents moyens visant à optimiser

l'efficacité du cache du processeur.

Tout d'abord, essayez de limiter le nombre de processus sur un même processeur. Exécutez ensuite les processus

partageant des données communes sur le même processeur ou ensemble de processeurs. Je vous expliquerai, un

peu plus tard, comment déterminer le nombre de processus métier adapté à une instance. Le regroupement des

tâches répond à un principe relativement simple : veillez à exécuter les processus d'une même instance sur un

même processeur ou ensemble de processeurs.

Pour ce faire, dans HP-UX, utilisez des ensembles de processeurs ou psets. Les psets présentent l'avantage de

pouvoir être créés, modifiés ou supprimés à la volée et ce, avec peu, voire pas d'effets résiduels. De même, un

processus peut être ajouté ou supprimé à partir d'un pset sans entraîner de surcharge. Les psets ont pour unique

fonction de déterminer les zones où les processus peuvent ou pas être exécutés. Nous avons pris quelques

mesures sur un système sans cellule, un rx6600 doté de quatre processeurs Montecito à double c

œ

urexécutant 2

050 utilisateurs SD, pour connaître la différence entre l'exécution de chaque instance SAP dans son propre pset

et l'exécution de tous les processus librement sur tout sur le système.

Les résultats qui en découlent sont répertoriés dans ce tableau bleu. Ces résultats sont intéressants. Comme vous

pouvez le constater, en définissant des psets, nous avons réduit de près de 15 % le nombre d'informations non

trouvées dans le cache. Nous avons également réduit d'environ 20 % le délai de requête de la base de

données. J'aimerais pouvoir vous dire que ce faisant, vous constaterez systématiquement une amélioration du

temps de réponse de 23%. Mais ce temps de réponse est celui du benchmark et peut varier en situation réelle. En

matière de benchmark, lorsque vous intervenez sur un système inactif et augmentez le nombre d'utilisateurs, le

temps de réponse reste relativement constant à son niveau minimum et aux alentours du pic de charge de travail

supporté par le système pour ensuite augmenter rapidement avec la mise en concurrence des ressources. 2 050

utilisateurs constituent une charge un peu trop élevée pour cette démonstration, car elle est inférieure d'environ 5

% à ce que le système supporte.

Nous avons donc agir sur la courbe du temps de réponse au niveau où celui-ci augmente rapidement. A ce

stade, une légère différence en termes de performances se traduit par un changement relativement important du

temps de réponse. L'amélioration du temps de processeur par étape de dialogue d'un peu plus de 2 % s'avère

cohérente avec les mesures prises sur un Superdome à une cellule, mesures qui nous ont permis de constater que

l'ajout de psets pouvait se traduire par environ 3 à 5 % d'utilisateurs en plus.

La différence en termes de temps de requête de la base de données est intéressante. En effet, lorsqu'un processus

SAP sollicite la base de données, gérée ici par le processus serveur Oracle, le processus métier transmet des

données au processus de la base de données. Et lorsque le processus serveur Oracle est exécuté, les données

résident, vraisemblablement, toujours dans le cache du processeur où le processus métier a été exécuté pour la

dernière fois. Si vous programmez les deux processus de manière à ce qu'ils soient exécutés dans le même pset,

il y a fort à parier qu'ils s'exécutent sur le même processeur, ce qui améliore les performances du processus de la

base de données, ce qui correspond, à mon sens, 20 % constatés ici. D'une manière générale, les psets

n'entraînent pas de nette amélioration, sauf sur les systèmes exécutant des caches plus petits. Là encore, ces

données sont issues d'un système de benchmark doté d'un cache maximum de 12 Mo par c

œ

ur. Le bénéfice lié

à l'utilisation de psets est plus important sur les systèmes exécutant une charge de travail plus hétérogène. Et bien

sûr, les psets sont encore plus utiles sur les systèmes plus anciens et plus grands, systèmes sur lesquels la latence

de la mémoire, et donc les problèmes liés aux informations non trouvées dans le cache, est plus marquée.

[DIAPOSITIVE SUIVANTE]

Penchons-nous à présent sur la latence de la mémoire. A l'aide des diapositives suivantes, je vais vous présenter

des informations générales sur la latence de la mémoire des machines à cellules. Puis, je vous parlerai des

données de benchmark qui illustrent la manière dont la différence de latence de la mémoire affecte les

performances. Et pour finir, je vous donnerai quelques conseils pratiques qui, je l'espère, vous seront bien utiles.

[DIAPOSITIVE SUIVANTE]

Cette diapositive illustre un système type à deux cellules. Pour plus de simplicité, nous ne montrons que 4

processeurs, même si un processeur Montecito à double c

œ

ur vous permet de disposer de huit c

œ

urs par cellule.

[DIAPOSITIVE SUIVANTE]

La plus courte latence d'accès aux données en dehors du processeur, qui doit être bien inférieure à 100

nanosecondes, est possible que si ces données se trouvent dans un autre cache du processeur, sur le même bus

frontal que la cellule. Les temps que je vais vous présenter sur ces diapositives ne sont pas précis. Ils reposent sur

des machines à cellules récentes. Mais les ratios entre les différents temps affichent, quant à eux, une certaine

précision. Ils sont assez représentatifs de ce que vous pourriez constater sur le récent chipset sx2000.

[DIAPOSITIVE SUIVANTE]

La deuxième meilleure latence, qui se situe autour de 200 nanosecondes, correspond aux données situées dans

la mémoire locale de cellule. Cette latence augmente de 50 % si les données se trouvent dans le cache d'un

processeur situé sur un autre bus frontal mais dans le même la cellule.

[DIAPOSITIVE SUIVANTE]

Cependant, s'il vous faut faire appel à une autre cellule pour accéder aux données, le coût minimum d'accès à

ces données à partir de la mémoire d'une autre cellule est multiplié par deux par rapport à celui de la mémoire

locale de cellule.

[DIAPOSITIVE SUIVANTE]

Et si les données se trouvent dans le cache d'un processeur distant, ce coût est quasiment multiplié par deux et

demi par rapport à celui de la mémoire locale.

Sur les plus grands systèmes, il est possible de franchir deux crossbars pour accéder à une donnée. Un accès à

la mémoire en deux sauts est deux fois et demie plus coûteuse que la mémoire locale et un cache distant peut être

multiplié par 3,25, soit 650 nanosecondes. 650 nanosecondes, cela semble peu, mais si vous fonctionnez à un

taux MIPS normal conforme à une installation SAP bien configurée sur un processeur Montecito d'environ 1 825

millions d'instructions par seconde, vous pouvez exécuter près de 1 200 instructions pendant ces 650

nanosecondes. Il convient dès lors de limiter le nombre de fois qu'il vous faut attendre après la mémoire.

[DIAPOSITIVE SUIVANTE]

Pour ce faire, la meilleure solution consiste à recourir à la mémoire locale de cellule.

Ce tableau répertorie les résultats de plusieurs tests d'extension menés à l'aide du benchmark SD sur un grand

système Superdome. Notez que l'hyper-threading y a été désactivé. Les nombres situés sur l'axe Y correspondent

au nombre d'utilisateurs SD pouvant exécuter un temps de réponse moyen inférieur à deux secondes.

C'est là une condition requise en matière de certification de benchmark, de même que pour la manière dont SAP

calcule SAPS. Pour chaque configuration testée, à savoir 2, 4, 8 et 16 cellules, nous vous présentons trois

ensembles de résultats. La colonne bleue correspond aux résultats générés lorsque toute la mémoire est entrelacée

sur toutes les cellules et que les processus sont libres de s’exécuter sur tous les processeurs disponibles. Il s'agit là

de la configuration par défaut pour HP-UX et, sauf intervention de votre part, c'est ce que vous pouvez constater

sur un grand système. La colonne du milieu, de couleur marron sur mes diapositives, répertorie les résultats

lorsque presque toute la mémoire est locale, par opposition à la mémoire entrelacée, et toutes les instances SAP

et tous les processus serveur de la base de données sont limités à des cellules uniques. Les meilleurs résultats, en

jaune, sont obtenus en affinant une restriction des processus aux ensembles de processeurs.

Bien sûr, le coût le la mémoire entrelacée augmente en fonction du nombre de cellules. La différence entre les

trois colonnes est plus prononcée sur les systèmes les plus grands. Sur une configuration à deux cellules, même

avec toute la mémoire entrelacée, vous avez 50 % de chances de trouver la ligne de mémoire que vous

recherchez dans la mémoire locale. Sur une configuration à deux cellules, la mémoire locale de cellule et les

psets se traduisent par un bénéfice respectif de 12 % et 4 %. Si vous passez au système à 16 cellules, les

performances par défaut portent sur 19 760 utilisateurs et 27 550 utilisateurs avec mémoire locale de cellule let

psets, soit un gain de près de 40 %.

[DIAPOSITIVE SUIVANTE]

Penchons-nous sur un autre exemple d’un plus petit rx8640 à quatre cellules. Ce système est doté de 120 Go de

RAM et, pour les besoins de cette expérience, nous avons configuré quatre partitions virtuelles distinctes, chacun

exécutant HP-UX 11i v3. Chaque partition s'est vue allouer tous les processeurs d’une des quatre cellules ainsi

qu'un quart de la mémoire totale, soit 30 Go chacune. Nous avons installé un système SAP ECC 6.0 sur trois des

quatre vPars, chacune dotée de bases de données Oracle 10G identiques. Pour cette expérience, nous avons

utilisé la version unicode de SAP et configuré deux instances par système. Nous avons testé deux configurations

de mémoire différentes. Pour la première série de tests, illustrés ici, l'ensemble de la mémoire a été entrelacée sur

les quatre cellules et chaque vPar s'est vue allouer 30 Go de cette mémoire.

[DIAPOSITIVE SUIVANTE]

Pour la deuxième série de tests, chaque vPar s'est vue allouer 30 Go de mémoire locale de cellule, comme le

montre le présent schéma. Pour mieux simuler la réalité d'un environnement client, nous avons exécuté une

combinaison de benchmarks SAP standard. La charge de travail était composée d'éléments de vente, de

distribution, de finance, de planning de production et de gestion. Malheureusement, s'agissant d'un benchmark

SAP, il présente un nombre limité d'entrées/sorties, mais l'exécution de cette combinaison de charges de travail,

nous avons examiné de plus près la base du code R3. Nous avons également opté pour une exécution inférieure

à celle du pic de charge de travail pour mieux refléter les attentes des clients. Toutes ces mesures ont été prises

avec une charge de travail identique de 750 utilisateurs. Nous avons donc simultanément utilisé 750 utilisateurs

sur trois des quatre vPars, trois des quatre systèmes HP-UX ; la quatrième cellule étant restée inactive.

[DIAPOSITIVE SUIVANTE]

Les résultats sont répertoriés dans ce tableau bleu. Là encore, comme nous utilisons des outils de benchmark SAP

standard, il s'ensuit un temps de réflexion de dix secondes entre les étapes de dialogue. Après examen du temps

de réponse et des étapes de dialogue par seconde, vous constatez un delta 4X du temps de réponse contre

seulement 10 % en ce qui concerne les étapes de dialogue par seconde. En fait, ces deux chiffres sont

étroitement liés. N'oubliez pas qu'il existe un temps de réflexion de dix secondes entre chaque étape de

dialogue, et en présence de 750 utilisateurs, le meilleur débit que vous pouvez espérer, avec une réponse

instantanée, est de l'ordre de 75 étapes de dialogue par seconde. Dès lors, le temps CPU par étape de dialogue

et l'utilisation totale du processeur constituent, à mon sens, de meilleures mesures de comparaison des

performances et affichent, dans le cas présent, une différence de l'ordre de 25 à 30 %.

[Diapositive suivante] (reprendre la diapositive précédente)

Il est intéressant de noter que ces résultats sont cohérents avec les résultats des quatre cellules mesurées

précédemment sur le benchmark SD du Superdome. Pour ce qui est de la configuration à quatre cellules, le

nombre d'utilisateurs avec mémoire locale de cellule et psets a augmenté d'environ 25 % pour passer de 5 960

à 7 450 utilisateurs SD.

[DIAPOSITIVE SUIVANTE]

Que peut-on en déduire ? Bien sûr, il est plus facile de configurer la mémoire locale de cellule et les psets pour

un benchmark doté de charges de travail prévisibles et uniformes que pour un système de production réel. Mais

je pense que ces gains de performances, de l'ordre de 25 à 30 %, sont trop importants pour être négligés. Au

minimum, vous devez pouvoir définir, un peu de mémoire locale de cellule. 10 % suffisent à toutes les données

privées des processus et peuvent gérer plus d'un niveau de toutes les références mémoire. Si vous utilisez 11i v3,

cela profite également aux structures de données du noyau conçues pour la mémoire locale de cellule.

L'utilisation de la mémoire locale de cellule, même à faible volume, implique que les instances SAP soient reliées

à des cellules individuelles. J'aimerais ajouter à cela qu'une seule instance SAP ne doit en aucun cas être trop

volumineuse pour solliciter la puissance de traitement de plus que tous les processeurs ou toute la mémoire d'une

cellule. J'y reviendrai dans quelques instants. Idéalement, pour tirer pleinement parti de la mémoire locale de

cellule, des segments de mémoire partagés SAP doivent aussi être alloués en dehors de la mémoire locale de

cellule. Malheureusement, aucun élément analysable SAP ne le permet.

Ceci dit, avec HP-UX 11i v3, il est possible de définir un drapeau pour indiquer au noyau HP-UX d'allouer de la

mémoire partagée en dehors de la mémoire locale de cellule, le cas échéant. Cet élément analysable, appelé

numa_policy, peut être dynamiquement défini sur un système en cours d'exécution avec la commande kctune.

Enfin, si vous exécutez la base de données sur le même serveur que les instances SAP, ce qu'en termes de

benchmarking on appelle configuration à deux niveaux, il est préférable que les processus de la base de

données soient exécutés sur la même cellule que les processus métier SAP auxquels ils correspondent.

Pour ce faire, Oracle propose deux moyens simples. Le moyen le plus efficace, pour diverses raisons, consiste à

utiliser le protocole bequeath que vous définissez dans le fichier tnsnames.ora. Ce faisant, vous ignorez

totalement la pile réseau en communiquant entre le processus métier SAP et le processus serveur Oracle.

Le processus serveur Oracle est, en fait, créé en tant qu'enfant du processus métier et hérite, à ce titre, de sa

politique d'ordonnancement. Vous pouvez également créer plusieurs écouteurs (listeners), un pour chaque cellule

où vous allez exécuter une instance SAP. Je sais que DB2 dispose d'un mécanisme similaire. Je n'en suis pas

certain pour les autres systèmes de gestion de bases de données.

[DIAPOSITIVE SUIVANTE]

Dans la section suivante, nous allons nous pencher sur les implications de notre discussion en matière de

configuration SAP. Là encore, il convient de se poser la question suivante : « Comment configurer SAP de

manière à utiliser le plus efficacement possible la puissance de traitement disponible ?»

[DIAPOSITIVE SUIVANTE]

Les points de cette diapositive sont à mettre en corrélation avec les principes décrits précédemment : définissez

les conditions requises en termes de processeur et de mémoire pour chaque instance SAP, puis affectez-les au

plus petit ensemble de processeurs disponible. Combien d'instances dois-je utiliser et quel doit être le volume de

chacune ? Combien de processus métier chacune doit-elle comporter ? Penchons-nous sur ces questions.

[DIAPOSITIVE SUIVANTE]

En la matière, il n'existe aucune règle adaptée à tous les cas de figure. D'après mon expérience, la tendance

générale consiste à surdimensionner des instances. Il est conseillé de disposer d'un plus grand nombre de petites

instances et cela, pour deux raisons. Premièrement, le répartiteur ne se traduit pas par un goulet d'étranglement.

Deuxièmement, et cela se vérifie notamment sur les grands systèmes, les petites instances permettent d'obtenir une

meilleure localité de la mémoire et du processeur, ce qui augmente l’efficacité des caches de ce dernier et, plus

important encore, réduit la latence de la mémoire. En règle générale, il convient d'adopter une instance pour

deux à quatre c

œ

urs. Par exemple, si vous utilisez un processeur rx4640 à quatre c

œ

urs en tant que serveur

d'applications, définissez un minimum de deux instances. Bien sûr, sur les systèmes à plusieurs cellules, si

possible, veillez à ce que les instances ne s’étendent pas sur plusieurs cellules.

[DIAPOSITIVE SUIVANTE]

Déterminer le nombre de processus métier qui convient exige un minimum de travail, car il vous faut bien

connaître votre application. Le principe de base est assez simple : utilisez le moins de processus métier possible

et cela, pour diverses raisons. Chaque processus métier utilise de la mémoire, pas seulement pour sa région de

données privées, mais aussi dans la mémoire étendue de l'instance. Mis bout à bout, chaque processus métier

supplémentaire que vous ajoutez peut nécessiter jusqu'à 100 Mo de RAM en plus. Plus il y a de processus

métier sur un processeur, plus la pression exercée sur ses caches est forte, plus les changements de contexte sont

importants et plus il y a contention dans SAP et dans le code de la base de données.

N'oubliez pas que chaque processus métier est doté d'un processus ou thread de base de données qui lui est

propre. Et plus ils sont nombreux à être exécutés simultanément, plus la contention des ressources de la base de

données est importante. En matière de mises à jour, notamment, nous avons pu constater des améliorations en

termes de temps de requête de la base de données moyennant la diminution du nombre de processus métier mis

à jour et donc du nombre de processus serveur mis à jour accédant aux mêmes tables de la base de données. Je

pense également qu'on a tendance à oublier la manière dont les requêtes sont gérées par le noyau R3. Si un

processus métier gérant une requête utilisateur doit attendre les entrées/sorties, ce processus normalement ne se

bloque pas. En fait, le contexte utilisateur est enregistré dans la zone de travail de la mémoire étendue et le

processus métier récupère l'unité de travail suivante dans la file d'attente du répartiteur avant de poursuivre sa

lancée. Ainsi, vous n'avez pas besoin d'autant de processus métier qu'il n'y paraît.

Certes, faute de processus métier suffisants, les ressources processeur sont inactives alors que le travail

s'accumule dans la file d'attente du répartiteur. Veillez à régulièrement surveiller l'utilisation du processeur ainsi

que les files d'attente du répartiteur. Pour surveiller ces files d'attente, j'ai recours à dpmon, un utilitaire SAP

générant peu de surcharge. Cet utilitaire lit directement les segments de mémoire partagés et ignore le noyau R3.

Vous pouvez également vous pencher sur le noyau SAP via la transaction sm51.

Si vous jugez le temps de réponse trop élevé, de même que les files d'attente, et pensez disposer de suffisamment

de mémoire et de processeur inactif, ajoutez un autre processus métier et voyez si la situation s'améliore.

Cependant, si vous jugez que la file d'attente du répartiteur est rarement encombrée et que certains processus

métier n'accumulent que peu de temps de processeur (pour ce faire, utilisez régulièrement la commande ps),

réduisez le nombre de processus métier. Les processus métier inutiles gaspillent des ressources et affectent les

performances.

Je vais à présent vous parler de la configuration des mises à jour. Quel est le meilleur moyen de procéder ? En

la matière, il existe de nombreuses possibilités. Je pense que dans le cas d'une configuration à trois niveaux, la

configuration de serveurs de mise à jour distincts présente un certain nombre d'avantages et d'inconvénients

théoriques et il convient également de se pencher sur l'exécution de mises à jour sur l'instance centrale. En effet,

les communications entre les serveurs de dialogue et de mise à jour sont indirectes et transitent par l'instance

centrale. Veillez à ne pas trop surcharger l'instance centrale.

Elle doit être en mesure d'effectuer ses tâches de verrouillage et de traiter les files d'attente très rapidement. Mais

la théorie est logique. Je dispose actuellement de trop peu d'éléments pour privilégier l'un ou l'autre moyen

d'effectuer des mises à jour sur une configuration à trois niveaux. Et j'aimerais ajouter qu'en termes de

performances, cela n'a pas grande importance.

Ceci dit, si l'on considère de grands systèmes dotés de serveurs d'applications configurés sur le même serveur

que la base de données, votre configuration à deux niveaux classique, il est intéressant d'affecter les mises à jour

à une instance exécutée sur la même cellule que les processus dialogue et leurs processus serveur. La raison à

cela : le taux de réussite du cache s'améliore, de même que la latence de la mémoire, surtout pour les processus

serveur de la base de données. D'un point de vue pratique, cela signifie que vous ne configurerez probablement

pas d'instances de mise à jour dédiées, car la charge d'une même cellule ne suffit pas à le justifier. Définissez

plutôt deux, voire trois ou quatre processus de mise à jour en fonction de vos besoins, veillez à les affecter à une

des instances d'une cellule et à faire en sorte cette instance fasse office de serveur de mise à jour pour toutes les

autres instances exécutées sur cette même cellule.

Paramètres du profil. Curieusement, compte tenu du grand nombre de paramètres SAP configurables, je me suis

rendu compte que la plupart ne s'accompagnent pas de réel impact sur les performances. Vous n'êtes pas tenu

de vérifier que les différents tampons et réserves de SAP sont correctement dimensionnés. Examinez régulièrement

l'utilisation de la mémoire interne via la transaction st02 et vérifiez qu'il n'existe pas d'échanges. L'écran st02

permet de facilement le voir : vérifiez qu'aucun champ n'apparaît en rouge.

Au-delà de cela, je crois que deux paramètres dont les valeurs sont définies par SAP affectent les performances.

Tout d'abord, vérifiez que SAP utilise le registre d'horloge de résolution HP-UX gethrtime pour les statistiques de

temps et non gettimeofday qui se révèle nettement moins efficace. Le code SAP est doté d'importants volumes

d'instrumentation. Ils chronomètrent tout et enregistrent ces mesures. En utilisant un chronomètre suffisamment

efficace, vous pouvez préserver une grande part des performances. Le paramètre à prendre en considération

s'appelle « stat/clock » et il doit être défini sur « sap_clock ». ; « gettimeofday », sa valeur par défaut, étant

à éviter. Le deuxième paramètre est, je crois, une nouveauté de la version 620.

Pour préserver l'espace du tampon du programme, SAP a compressé la portion de données initialisée des

programmes ABAP au moment de leur chargement dans la mémoire tampon. Trois paramètres permettent de

régler le degré de compression : zéro, un et deux pour une compression minimum, normale ou maximum. Un

correspond au paramètre par défaut. Pour de plus amples détails, consultez la note SAP 559874. L'espace et le

temps de processeur font l'objet d'un compromis.

En définissant le paramètre initrc_degree sur zéro, nous avons réussi à économiser 5 à 6 % d'utilisation totale

processeur par processus métier avec une sollicitation accrue de la mémoire dans la mémoire tampon du

programme. Pour les benchmarks, l'augmentation de l'espace s'est avérée minime et ce, compte tenu du fait que

le nombre de programmes ABAP exécutés est relativement faible. Là encore, il convient de bien surveiller la

situation, mais cela peut s'avérer intéressant en présence d'un système test ou AQ capable de savoir si ce

compromis en vaut la peine, ce qui s'est vérifié dans le cas des benchmarks.

[DIAPOSITIVE SUIVANTE]

Dans cette section, nous allons brièvement décrire la configuration du noyau HP-UX pour SAP.

[DIAPOSITIVE SUIVANTE]

Ici, la recommandation la plus importante consiste à toujours se référer à la note SAP 172747 : « HP-UX

Operating System Kernel Parameter Recommendations » (Recommandations relatives aux paramètres du noyau

du système d'exploitation HP-UX) qui détaille les paramètres autres que ceux utilisés par défaut requis pour SAP.

Ils ont principalement trait à la communication entre processus. Heureusement, cette question requiert moins

d'attention que par le passé. Sur les versions plus anciennes de HP-UX, bon nombre de ressources du noyau

étaient allouées en fonction des paramètres et il fallait veiller à ne pas trop configurer ces tables pour ne pas

gaspiller la mémoire. Avec 11i, la plupart des tables du noyau sont dynamiques. Le fait de définir de nombreux

paramètres sur leur valeur maximum n'entraîne que peu, voire pas de pénalités et, en fait, et ces valeurs sont

utilisées pour bon nombre de paramètres. De même, de nombreux paramètres ajustables sont eux-mêmes

dynamiques. Ils peuvent être modifiés à la volée sans nécessiter de redémarrage. Dans un tel contexte, une

mauvaise configuration du noyau porte moins à conséquence. Veillez cependant à allouer suffisamment de

ressources à ce noyau pour éviter que SAP ne se heurte à des erreurs si certaines ressources viennent à manquer.

Si vous suivez les recommandations formulées dans la note SAP, vous ne devriez pas rencontrer de problèmes.

Ceci dit, j'aimerais attirer votre attention sur le fait qu'il vous faut veiller à ne pas gaspiller d'espace en

configurant le cache de tampon plus qu'il ne le faut. Je crois que la note SAP recommande de définir

filecache_max— sur 11i v3 ; sur les versions antérieures de HP-UX, les paramètres équivalents étaient les

suivants : dbc_max_pct sur 8 % et filecache_min sur 5 %. Dans ce contexte, vous devez installer SAP sur le

même serveur que la base de données, exécuter la base de données via le système de fichiers et ne pas utiliser

d'entrées/sorties directes. Ainsi, surtout si vous configurez votre système en tant que serveur de l'application SAP,

vous n'êtes pas tenu de consacrer 5 % de la mémoire au cache de fichiers, 1 % devant suffire. Si vous hésitez,

vous pouvez opter pour la valeur la plus élevée et laissez le cache de fichiers augmenter, mais commencez par

une valeur minimum très basse. Vous économiserez ainsi de la mémoire.

Je vous conseille également de toujours configurer un important espace d'échange (swap). En effet, il vous faudra

certainement bien dimensionner vos applications pour optimiser la mémoire. Si votre mémoire est limitée au point

qu'il vous soit nécessaire de procéder à un échange, les performances en seront considérablement affectées.

Aucun système d'exploitation n'est conçu pour être échangé de manière continue. Il est important de disposer de

suffisamment de stockage de sauvegarde pour créer et faire évoluer vos processus ainsi que votre mémoire

partagée. Nous vous conseillons d'allouer deux à trois fois la taille de la mémoire réelle pour l'espace

d'échange. Il ne doit pas nécessairement s'agir de périphériques rapides et coûteux. L'important, c'est que vous

disposiez de cette espace disque. Vous ne devez pas être amené à l'utiliser, mais en cas de besoin, vous pouvez

compter sur la solution de stockage de sauvegarde.

Enfin, pour revenir sur un point soulevé précédemment, la mémoire locale de cellule permet de renforcer les

performances, sur les grands systèmes notamment. Sur 11i v3, vous pouvez demander au système d'exploitation

d'utiliser la mémoire locale de cellule comme mémoire partagée en définissant le paramètre numa_policy sur un.

[DIAPOSITIVE SUIVANTE]

Le dernier sujet porte sur les performances de pthreads. Le noyau SAP n'est pas multithread. Mais d'autres

produits, comme liveCache basé sur MaxDB, le sont. Si vous envisagez d'exécuter des applications multithread,

nous vous conseillons vivement d'opter pour la dernière version du système d'exploitation. En termes de

performances des threads, 11i v2 et, dans une plus grande mesure, 11i v3 affichent de réelles améliorations par

rapport aux versions antérieures de HP-UX. Si vous consultez cette présentation après mars 2008, la version

fusionnée 0803 de 11i v3 a été encore améliorée pour pthreads. Quelle que soit la version, la variable

d'environnement PTHREAD_FORCE_SCOPE_SYSTEM doit être définie sur un. Elle indique au noyau que vous

n'utiliserez pas les threads MxN, ce qui permet de limiter la surcharge sur la plupart des appels des

bibliothèques pthreads. Si vous utilisez 11i v2 et que vous souhaitez améliorer les performances des threads, je

commencerais par vous dire d'opter pour 11i v3. Installez parallèlement le correctif de pthreads PHCO_36323

ainsi le correctif de performances ksleep, PHKL_36826. Le premier correctif contient des améliorations destinées

aux variables de condition et le deuxième, plus important encore, accélère les mécanismes de veille et de réveil

de toutes les opérations pthreads, pour les mutex et les variables de condition.

Je sais que cela peut paraître incroyable, mais nous avons récemment mené des tests sur un système PA à 64

c

œ

urs, un programme de tests synthétiques qui simule le mécanisme de basculement des threads utilisé par

liveCache et ces tests ont démontré que la dernière version de 11i v3 pouvait prendre en charge un taux de

basculement des threads deux fois plus élevé que celui de la version 11i.

Il faut bien admettre que l'ancienne implémentation affichait quelques problèmes d’évolutivité, mais la nouvelle

s'avère particulièrement rapide.

[DIAPOSITIVE SUIVANTE]

Nous voici à la dernière diapositive. Je vais vous résumer brièvement les différents points que nous avons

développés. Tout d'abord, il est extrêmement important de bien comprendre votre charge de travail avant de

pouvoir agir sur les performances. Vous devez connaître l'utilisation que vous faites des ressources moyennes et

du pic de ressources pour bien allouer les ressources de votre ordinateur. Vous devez également veiller à utiliser

des grandes pages pour votre application, ce qui devrait être aisément possible si vous utilisez une des dernières

versions de SAP et HP-UX. Pour le vérifier, utilisez la commande chatr. Si vous n'utilisez pas de grandes pages,

tirez immédiatement parti de disp+work et réduisez les défauts de TLB. Essayez ensuite d'améliorer le taux de

réussite du cache en limitant les processus ainsi que leur transfert d'un processeur à un autre. Plus important

encore, sur les grands systèmes, utilisez la mémoire locale de cellule. Le fait de réduire la latence de la mémoire,

comme nous avons pu le constater, s'accompagne d'une très nette incidence sur les performances dans leur

ensemble. Enfin, lorsque vous configurez SAP, ne limitez pas le nombre d'instances, mais limitez le nombre de

processus métier de chaque instance. Utilisez toutes les instances dont vous avez besoin pour atteindre l'équilibre

et la granularité de votre choix, mais pour chaque instance, réduisez au minimum le nombre de processus métier.

[DIAPOSITIVE SUIVANTE]

J'espère que ces informations vous seront utiles. Si vous avez des questions ou suggestions sur les points

développés dans cette présentation, n'hésitez pas à m'écrire à l'adresse indiquée sur le site Web. Merci pour

votre attention.

Pour de plus amples informations, visitez le site suivant :

www.hp.com/go/kod

© 2009 Hewlett-Packard Development Company, L.P. Les informations contenues dans le présent document sont

sujettes à modification sans préavis. Les seules garanties applicables aux produits et services HP sont celles

énoncées dans les déclarations de garantie expresses qui accompagnent lesdits produits et services. Aucun élément

du présent contenu ne peut être interprété comme constituant une garantie supplémentaire. HP ne saurait être tenue

responsable des erreurs ou omissions de nature technique ou rédactionnelle contenues dans le présent document.