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

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

-

Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
11 pages
Français
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

Description

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 ...

Sujets

Informations

Publié par
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.
  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents