N\u00e9anmoins, les techniques utilis\u00e9es pour am\u00e9liorer les performances dans les syst\u00e8mes Numa et dans les paysages distribu\u00e9s se ressemblent.<\/p>\n
Puisque SAP<\/span>-Comme les applications g\u00e8rent souvent des centaines de gigaoctets, voire des t\u00e9raoctets de donn\u00e9es, un acc\u00e8s efficace \u00e0 la m\u00e9moire principale est essentiel. C'est sur cet aspect que se concentre cet article :<\/p>\n SAP<\/span> a pr\u00e9sent\u00e9 au salon Sapphire 2012 \u00e0 Orlando un syst\u00e8me qui permet d'effectuer des requ\u00eates analytiques sur une plateforme distribu\u00e9e. Hana<\/span>-La base de donn\u00e9es de 100 n\u0153uds est trait\u00e9e avec un total de 100 To de m\u00e9moire principale agr\u00e9g\u00e9e.<\/p>\n Typique de l'utilisation distribu\u00e9e Hana<\/span>-Les environnements de serveurs utilisent plut\u00f4t cinq \u00e0 dix n\u0153uds de serveurs. Il est toutefois \u00e9vident que dans un environnement de serveurs distribu\u00e9s, l'accent est mis sur une distribution efficace des donn\u00e9es et des requ\u00eates, ainsi que sur une communication r\u00e9seau efficace, plut\u00f4t que sur un acc\u00e8s efficace \u00e0 la m\u00e9moire principale.<\/p>\n Les syst\u00e8mes de serveur modernes ont plusieurs processeurs (ou CPU) sur leur carte \u00e9lectronique - typiquement, une \u00e0 quatre CPU dans les syst\u00e8mes de bureau de Intel<\/span>alors que dans Intel<\/span>-on trouve de deux \u00e0 huit CPU sur les serveurs. Les processeurs sont reli\u00e9s \u00e0 la carte via un socket.<\/p>\n Chacune de ces unit\u00e9s centrales contient g\u00e9n\u00e9ralement plusieurs c\u0153urs dans lesquels les calculs sont effectu\u00e9s. Les CPU Intel modernes contiennent entre deux et dix c\u0153urs. Au total, les grands serveurs disposent ainsi de jusqu'\u00e0 80 c\u0153urs pour le traitement des donn\u00e9es.<\/p>\n Comme il n'est plus possible d'augmenter la fr\u00e9quence d'horloge dans les c\u0153urs, notamment pour des raisons thermiques, le nombre de c\u0153urs dans les serveurs va encore augmenter dans les ann\u00e9es \u00e0 venir. Les unit\u00e9s centrales et la m\u00e9moire principale sont reli\u00e9es entre elles par un syst\u00e8me de bus.<\/p>\n Si les calculs pour une requ\u00eate peuvent \u00eatre r\u00e9partis sur de nombreux c\u0153urs, la question se pose de savoir comment les donn\u00e9es sont transport\u00e9es vers les c\u0153urs. En principe, il existe ici deux alternatives au niveau de l'architecture du processeur (Hennessy & Patterson, 2012) :<\/p>\n Comme dans les Intel<\/span>-Si un processeur contient plusieurs c\u0153urs, il en r\u00e9sulte une architecture Numa au niveau des processeurs, mais un SMP<\/span>-au niveau de chaque processeur.<\/p>\n Ce dernier est \u00e9galement appel\u00e9 Chip-Multi-Processor (CMP). Exemples de SMP<\/span>-Les syst\u00e8mes Intel Pentium D et Intel Itanium sont les plus r\u00e9pandus, IBM Power<\/span>Sun UltraSparc T2 ou SGI MIPS, tandis que les exemples d'architectures Numa sont les CPU Intel Nehalem ou les AMD<\/span> Les CPU Opteron (et leurs successeurs) sont<\/p>\n Le site SAP<\/span>-Hana<\/span>-DB a \u00e9t\u00e9 cr\u00e9\u00e9e en collaboration avec Intel<\/span> pour l'ex\u00e9cution sur des supports actuels Intel<\/span>-Xeon sont optimis\u00e9s. Par exemple, la Hana<\/span>-DB la SSE<\/span>-extensions de Intel<\/span>-Les processeurs de la s\u00e9rie C permettent de traiter plusieurs \u00e9l\u00e9ments en parall\u00e8le dans une instruction machine.<\/p>\n Comme ces Intel<\/span>-\u00e9tant bas\u00e9s sur une architecture Numa, le code des processeurs Numa doit \u00e9galement \u00eatre modifi\u00e9. Hana<\/span>-BDD pour cette architecture. Nous allons maintenant nous int\u00e9resser \u00e0 quelques sc\u00e9narios o\u00f9 les effets Numa sont pr\u00e9sents dans la Hana<\/span>-DB sont pertinentes et comment les Hana<\/span>-DB sait s'en servir.<\/p>\n Lorsqu'une demande concerne la Hana<\/span>-cette requ\u00eate est d'abord attribu\u00e9e \u00e0 un thread. En g\u00e9n\u00e9ral, les threads permettent un traitement parall\u00e8le l\u00e9ger de plusieurs requ\u00eates (par rapport aux processus du syst\u00e8me d'exploitation).<\/p>\n Les threads actifs sont affich\u00e9s \u00e0 un moment donn\u00e9 sur un seul et m\u00eame \u00e9cran. Core<\/span> est ex\u00e9cut\u00e9e. Pendant le traitement d'une requ\u00eate, la base de donn\u00e9es doit dans la plupart des cas allouer de la m\u00e9moire, par exemple pour collecter le r\u00e9sultat de la requ\u00eate pour l'application de la base de donn\u00e9es. La m\u00e9moire doit alors \u00eatre allou\u00e9e dans la zone de m\u00e9moire allou\u00e9e au processeur et \u00e0 l'application. Core<\/span> afin que les acc\u00e8s \u00e0 la m\u00e9moire ne soient pas retard\u00e9s par des acc\u00e8s \u00e0 la m\u00e9moire distante.<\/p>\n Les syst\u00e8mes d'exploitation modernes tiennent d\u00e9j\u00e0 compte des architectures Numa : tant les Microsoft Windows<\/span> 7 ou Windows Server 2008R2 ainsi que de Linux<\/span> (\u00e0 partir du noyau 2.5) tentent d'allouer la m\u00e9moire dans la zone attribu\u00e9e au processeur du thread ou au processus du syst\u00e8me d'exploitation. Les applications profitent ainsi automatiquement des optimisations du syst\u00e8me d'exploitation.<\/p>\n Il convient de noter ici que les solutions de virtualisation telles que VMware ESX font abstraction du mat\u00e9riel physique. Comme le logiciel fonctionne avec des CPU logiques et une couche de virtualisation pour la m\u00e9moire, les optimisations pour une architecture Numa sur un syst\u00e8me virtualis\u00e9 peuvent m\u00eame avoir des effets n\u00e9gatifs.<\/p>\n La gestion automatique de la m\u00e9moire par le syst\u00e8me d'exploitation peut avoir des effets ind\u00e9sirables lorsqu'une application g\u00e8re elle-m\u00eame la m\u00e9moire afin d'\u00e9viter des appels syst\u00e8me co\u00fbteux lors de l'allocation et de la lib\u00e9ration de la m\u00e9moire. La m\u00e9moire peut alors se trouver dans la mauvaise zone lors de la r\u00e9utilisation de la m\u00e9moire. Presque chaque base de donn\u00e9es met en \u0153uvre sa propre gestion de la m\u00e9moire, qui fonctionne au niveau de l'application.<\/p>\n Un autre effet est qu'un thread alloue de la m\u00e9moire (localement), mais que de nombreux autres threads veulent travailler avec cette m\u00e9moire.<\/p>\n Prenons l'exemple de la m\u00e9moire d'une colonne : Cette m\u00e9moire est allou\u00e9e une fois dans la m\u00e9moire principale lors du chargement de la colonne, mais de nombreuses requ\u00eates lisent les donn\u00e9es de la colonne.<\/p>\n Dans les deux sc\u00e9narios mentionn\u00e9s, la gestion de la m\u00e9moire au niveau de l'application et l'acc\u00e8s \u00e0 la m\u00e9moire par de nombreux threads, un ordonnancement efficace des threads peut aider. Ici aussi, les syst\u00e8mes d'exploitation modernes mettent en \u0153uvre des strat\u00e9gies visant \u00e0 ex\u00e9cuter les threads l\u00e0 o\u00f9 les donn\u00e9es utilis\u00e9es sont allou\u00e9es.<\/p>\n Cela peut aller jusqu'\u00e0 la cr\u00e9ation d'un fil de discussion par un Core<\/span> est d\u00e9plac\u00e9 vers un autre afin que les acc\u00e8s m\u00e9moire puissent \u00eatre trait\u00e9s \u00e0 partir de la m\u00e9moire locale. Le syst\u00e8me d'exploitation se heurte toutefois \u00e0 des limites o\u00f9, par exemple, les connaissances du syst\u00e8me de base de donn\u00e9es peuvent conduire \u00e0 de meilleurs r\u00e9sultats d\u00e9cisionnels.<\/p>\n Dans la section pr\u00e9c\u00e9dente, nous avons abord\u00e9 les strat\u00e9gies bas\u00e9es sur les architectures Numa, qui sont disponibles pour chaque application sur les serveurs modernes et les syst\u00e8mes d'exploitation modernes.<\/p>\n Toutefois, ces techniques seules conduisent \u00e0 des d\u00e9cisions sous-optimales, car les caract\u00e9ristiques sp\u00e9cifiques d'un syst\u00e8me de base de donn\u00e9es ne peuvent pas \u00eatre prises en compte. Les possibilit\u00e9s d'optimisation sp\u00e9cifiques aux bases de donn\u00e9es dans la Hana<\/span>-Cette section aborde la question de l'utilisation de la base de donn\u00e9es.<\/p>\n Comme nous l'avons vu plus haut, l'application de la Hana<\/span>-DB, pour des raisons d'efficacit\u00e9, une gestion de la m\u00e9moire qui s'appuie sur la gestion de la m\u00e9moire du syst\u00e8me d'exploitation. Dans ce contexte, la m\u00e9moire n'est normalement pas restitu\u00e9e au syst\u00e8me d'exploitation lorsqu'elle est lib\u00e9r\u00e9e dans le code de la base de donn\u00e9es.<\/p>\n En m\u00eame temps, la m\u00e9moire d\u00e9j\u00e0 allou\u00e9e est r\u00e9utilis\u00e9e. Cela doit permettre de r\u00e9duire la fragmentation de la m\u00e9moire principale, mais aussi le nombre d'appels du syst\u00e8me au syst\u00e8me d'exploitation. C'est ici que s'ouvrent les possibilit\u00e9s d'exploiter les propri\u00e9t\u00e9s sp\u00e9cifiques d'une architecture Numa :<\/p>\n 1. lorsqu'un thread demande de la m\u00e9moire, la m\u00e9moire locale du processeur est allou\u00e9e au thread afin que les acc\u00e8s \u00e0 cette m\u00e9moire soient effectu\u00e9s par la m\u00e9moire locale du processeur.Contr\u00f4leur<\/span> sont trait\u00e9es et que les bus de m\u00e9moire entre les processeurs sont d\u00e9charg\u00e9s. Cette strat\u00e9gie semble particuli\u00e8rement judicieuse dans les sc\u00e9narios o\u00f9 la m\u00e9moire est utilis\u00e9e par des threads sur le m\u00eame processeur.<\/p>\n 2. dans certains cas, il semble en revanche plus judicieux de r\u00e9partir la m\u00e9moire demand\u00e9e sur plusieurs processeurs. Dans les syst\u00e8mes actuels, il semble que, dans certains sc\u00e9narios, les ressources de m\u00e9moireContr\u00f4leur<\/span> constituer un goulot d'\u00e9tranglement. Dans ce cas, il est plus judicieux de r\u00e9partir la m\u00e9moire et les threads qui utilisent la m\u00e9moire sur diff\u00e9rents processeurs. De cette mani\u00e8re, le goulot d'\u00e9tranglement peut \u00eatre \u00e9vit\u00e9, par exemple lors de l'acc\u00e8s \u00e0 de grandes colonnes fr\u00e9quemment utilis\u00e9es.<\/p>\n Dans de nombreux cas, un syst\u00e8me d'exploitation moderne prend une bonne d\u00e9cision quant au choix des threads et de leur emplacement. Core<\/span> doivent \u00eatre ex\u00e9cut\u00e9s.<\/p>\n Lors de la d\u00e9cision, il est tenu compte du fait qu'il existe encore des c\u0153urs sur un processeur qui n'effectuent actuellement aucun calcul, de l'\u00e9tat d'activit\u00e9 de certains c\u0153urs et processeurs (pour \u00e9conomiser de l'\u00e9nergie, il vaut la peine de concentrer le travail sur certains processeurs et de d\u00e9sactiver d'autres processeurs), du fait que certains processeurs fonctionnent actuellement en \"overclocking\" (TurboBoost en cas de Intel<\/span>) ainsi que les donn\u00e9es auxquelles un thread acc\u00e8de.<\/p>\n Outre cette d\u00e9cision automatique du syst\u00e8me d'exploitation, un d\u00e9veloppeur d'applications peut influencer l'affectation des threads aux processeurs ou aux c\u0153urs.<\/p>\n En fait, les possibilit\u00e9s d'optimisation qui en d\u00e9coulent pour l'ordonnancement des threads dans le syst\u00e8me sont \u00e0 consid\u00e9rer en fonction de la gestion de la m\u00e9moire :<\/p>\nQu'est-ce que Numa ?<\/h3>\n
\n
\nDans cette architecture, le temps d'acc\u00e8s \u00e0 une adresse m\u00e9moire est le m\u00eame pour toutes les adresses et pour tous les c\u0153urs. Cette architecture est repr\u00e9sent\u00e9e dans la figure 2. Des caches sont attribu\u00e9s localement \u00e0 chaque processeur. L'acc\u00e8s \u00e0 la m\u00e9moire principale se fait via un Bus<\/span>que tous les processeurs se partagent. Dans cette architecture, le Bus de m\u00e9moire<\/span> devient un goulot d'\u00e9tranglement, car les op\u00e9rations de lecture qui ne peuvent pas \u00eatre servies par le cache local et toutes les op\u00e9rations d'\u00e9criture sont effectu\u00e9es sur le cache commun. Bus de m\u00e9moire<\/span> doivent acc\u00e9der.<\/li>\n
\nDans cette architecture (figure 3), les processeurs se voient attribuer localement \u00e0 la fois les caches et la m\u00e9moire. Pour un processeur, l'acc\u00e8s \u00e0 la m\u00e9moire locale est plus rapide que l'acc\u00e8s \u00e0 la m\u00e9moire d'un autre processeur, car les acc\u00e8s distants se font via un Bus de m\u00e9moire<\/span> doivent \u00eatre trait\u00e9s. Pour les programmes d'application, l'affectation de la m\u00e9moire physique aux diff\u00e9rents processeurs n'est pas directement perceptible - ils fonctionnent comme dans un SMP<\/span> avec un espace d'adressage homog\u00e8ne.<\/li>\n<\/ol>\nNuma est-il pertinent pour Hana ?<\/h3>\n
Support de Numa en Hana<\/span><\/h3>\n
Gestion de la m\u00e9moire<\/h3>\n
Planification des t\u00e2ches<\/h3>\n
\n