Stratégies et gestion du stockage

Néanmoins, les techniques utilisées pour améliorer les performances dans les systèmes Numa et dans les paysages distribués se ressemblent.

Puisque SAP-Comme les applications gèrent souvent des centaines de gigaoctets, voire des téraoctets de données, un accès efficace à la mémoire principale est essentiel. C'est sur cet aspect que se concentre cet article :

SAP a présenté au salon Sapphire 2012 à Orlando un système qui permet d'effectuer des requêtes analytiques sur une plateforme distribuée. Hana-La base de données de 100 nœuds est traitée avec un total de 100 To de mémoire principale agrégée.

Typique de l'utilisation distribuée Hana-Les environnements de serveurs utilisent plutôt cinq à dix nœuds de serveurs. Il est toutefois évident que dans un environnement de serveurs distribués, l'accent est mis sur une distribution efficace des données et des requêtes, ainsi que sur une communication réseau efficace, plutôt que sur un accès efficace à la mémoire principale.

Qu'est-ce que Numa ?

Les systèmes de serveur modernes ont plusieurs processeurs (ou CPU) sur leur carte électronique - typiquement, une à quatre CPU dans les systèmes de bureau de Intelalors que dans Intel-on trouve de deux à huit CPU sur les serveurs. Les processeurs sont reliés à la carte via un socket.

Chacune de ces unités centrales contient généralement plusieurs cœurs dans lesquels les calculs sont effectués. Les CPU Intel modernes contiennent entre deux et dix cœurs. Au total, les grands serveurs disposent ainsi de jusqu'à 80 cœurs pour le traitement des données.

Comme il n'est plus possible d'augmenter la fréquence d'horloge dans les cœurs, notamment pour des raisons thermiques, le nombre de cœurs dans les serveurs va encore augmenter dans les années à venir. Les unités centrales et la mémoire principale sont reliées entre elles par un système de bus.

Si les calculs pour une requête peuvent être répartis sur de nombreux cœurs, la question se pose de savoir comment les données sont transportées vers les cœurs. En principe, il existe ici deux alternatives au niveau de l'architecture du processeur (Hennessy & Patterson, 2012) :

1. Multiprocessus symétrique (SMP):
   Dans cette architecture, le temps d'accès à une adresse mémoire est le même pour toutes les adresses et pour tous les cœurs. Cette architecture est représentée dans la figure 2. Des caches sont attribués localement à chaque processeur. L'accès à la mémoire principale se fait via un Busque tous les processeurs se partagent. Dans cette architecture, le Bus de mémoire devient un goulot d'étranglement, car les opérations de lecture qui ne peuvent pas être servies par le cache local et toutes les opérations d'écriture sont effectuées sur le cache commun. Bus de mémoire doivent accéder.
2. Accès à la mémoire non uniforme :
   Dans cette architecture (figure 3), les processeurs se voient attribuer localement à la fois les caches et la mémoire. Pour un processeur, l'accès à la mémoire locale est plus rapide que l'accès à la mémoire d'un autre processeur, car les accès distants se font via un Bus de mémoire doivent être traités. Pour les programmes d'application, l'affectation de la mémoire physique aux différents processeurs n'est pas directement perceptible - ils fonctionnent comme dans un SMP avec un espace d'adressage homogène.

Comme dans les Intel-Si un processeur contient plusieurs cœurs, il en résulte une architecture Numa au niveau des processeurs, mais un SMP-au niveau de chaque processeur.

Ce dernier est également appelé Chip-Multi-Processor (CMP). Exemples de SMP-Les systèmes Intel Pentium D et Intel Itanium sont les plus répandus, IBM PowerSun UltraSparc T2 ou SGI MIPS, tandis que les exemples d'architectures Numa sont les CPU Intel Nehalem ou les AMD Les CPU Opteron (et leurs successeurs) sont

Numa est-il pertinent pour Hana ?

Le site SAP–Hana-DB a été créée en collaboration avec Intel pour l'exécution sur des supports actuels Intel-Xeon sont optimisés. Par exemple, la Hana-DB la SSE-extensions de Intel-Les processeurs de la série C permettent de traiter plusieurs éléments en parallèle dans une instruction machine.

Comme ces Intel-étant basés sur une architecture Numa, le code des processeurs Numa doit également être modifié. Hana-BDD pour cette architecture. Nous allons maintenant nous intéresser à quelques scénarios où les effets Numa sont présents dans la Hana-DB sont pertinentes et comment les Hana-DB sait s'en servir.

Lorsqu'une demande concerne la Hana-cette requête est d'abord attribuée à un thread. En général, les threads permettent un traitement parallèle léger de plusieurs requêtes (par rapport aux processus du système d'exploitation).

Les threads actifs sont affichés à un moment donné sur un seul et même écran. Core est exécutée. Pendant le traitement d'une requête, la base de données doit dans la plupart des cas allouer de la mémoire, par exemple pour collecter le résultat de la requête pour l'application de la base de données. La mémoire doit alors être allouée dans la zone de mémoire allouée au processeur et à l'application. Core afin que les accès à la mémoire ne soient pas retardés par des accès à la mémoire distante.

Les systèmes d'exploitation modernes tiennent déjà compte des architectures Numa : tant les Microsoft Windows 7 ou Windows Server 2008R2 ainsi que de Linux (à partir du noyau 2.5) tentent d'allouer la mémoire dans la zone attribuée au processeur du thread ou au processus du système d'exploitation. Les applications profitent ainsi automatiquement des optimisations du système d'exploitation.

Il convient de noter ici que les solutions de virtualisation telles que VMware ESX font abstraction du matériel physique. Comme le logiciel fonctionne avec des CPU logiques et une couche de virtualisation pour la mémoire, les optimisations pour une architecture Numa sur un système virtualisé peuvent même avoir des effets négatifs.

La gestion automatique de la mémoire par le système d'exploitation peut avoir des effets indésirables lorsqu'une application gère elle-même la mémoire afin d'éviter des appels système coûteux lors de l'allocation et de la libération de la mémoire. La mémoire peut alors se trouver dans la mauvaise zone lors de la réutilisation de la mémoire. Presque chaque base de données met en œuvre sa propre gestion de la mémoire, qui fonctionne au niveau de l'application.

Un autre effet est qu'un thread alloue de la mémoire (localement), mais que de nombreux autres threads veulent travailler avec cette mémoire.

Prenons l'exemple de la mémoire d'une colonne : Cette mémoire est allouée une fois dans la mémoire principale lors du chargement de la colonne, mais de nombreuses requêtes lisent les données de la colonne.

Dans les deux scénarios mentionnés, la gestion de la mémoire au niveau de l'application et l'accès à la mémoire par de nombreux threads, un ordonnancement efficace des threads peut aider. Ici aussi, les systèmes d'exploitation modernes mettent en œuvre des stratégies visant à exécuter les threads là où les données utilisées sont allouées.

Cela peut aller jusqu'à la création d'un fil de discussion par un Core est déplacé vers un autre afin que les accès mémoire puissent être traités à partir de la mémoire locale. Le système d'exploitation se heurte toutefois à des limites où, par exemple, les connaissances du système de base de données peuvent conduire à de meilleurs résultats décisionnels.

Support de Numa en Hana

Dans la section précédente, nous avons abordé les stratégies basées sur les architectures Numa, qui sont disponibles pour chaque application sur les serveurs modernes et les systèmes d'exploitation modernes.

Toutefois, ces techniques seules conduisent à des décisions sous-optimales, car les caractéristiques spécifiques d'un système de base de données ne peuvent pas être prises en compte. Les possibilités d'optimisation spécifiques aux bases de données dans la Hana-Cette section aborde la question de l'utilisation de la base de données.

Gestion de la mémoire

Comme nous l'avons vu plus haut, l'application de la Hana-DB, pour des raisons d'efficacité, une gestion de la mémoire qui s'appuie sur la gestion de la mémoire du système d'exploitation. Dans ce contexte, la mémoire n'est normalement pas restituée au système d'exploitation lorsqu'elle est libérée dans le code de la base de données.

En même temps, la mémoire déjà allouée est réutilisée. Cela doit permettre de réduire la fragmentation de la mémoire principale, mais aussi le nombre d'appels du système au système d'exploitation. C'est ici que s'ouvrent les possibilités d'exploiter les propriétés spécifiques d'une architecture Numa :

1. lorsqu'un thread demande de la mémoire, la mémoire locale du processeur est allouée au thread afin que les accès à cette mémoire soient effectués par la mémoire locale du processeur.Contrôleur sont traitées et que les bus de mémoire entre les processeurs sont déchargés. Cette stratégie semble particulièrement judicieuse dans les scénarios où la mémoire est utilisée par des threads sur le même processeur.

2. dans certains cas, il semble en revanche plus judicieux de répartir la mémoire demandée sur plusieurs processeurs. Dans les systèmes actuels, il semble que, dans certains scénarios, les ressources de mémoireContrôleur constituer un goulot d'étranglement. Dans ce cas, il est plus judicieux de répartir la mémoire et les threads qui utilisent la mémoire sur différents processeurs. De cette manière, le goulot d'étranglement peut être évité, par exemple lors de l'accès à de grandes colonnes fréquemment utilisées.

Planification des tâches

Dans de nombreux cas, un système d'exploitation moderne prend une bonne décision quant au choix des threads et de leur emplacement. Core doivent être exécutés.

Lors de la décision, il est tenu compte du fait qu'il existe encore des cœurs sur un processeur qui n'effectuent actuellement aucun calcul, de l'état d'activité de certains cœurs et processeurs (pour économiser de l'énergie, il vaut la peine de concentrer le travail sur certains processeurs et de désactiver d'autres processeurs), du fait que certains processeurs fonctionnent actuellement en "overclocking" (TurboBoost en cas de Intel) ainsi que les données auxquelles un thread accède.

Outre cette décision automatique du système d'exploitation, un développeur d'applications peut influencer l'affectation des threads aux processeurs ou aux cœurs.

En fait, les possibilités d'optimisation qui en découlent pour l'ordonnancement des threads dans le système sont à considérer en fonction de la gestion de la mémoire :

1. Si les données utilisées par un thread sont affectées localement à un processeur, le thread devrait également être exécuté sur ce processeur. De manière assez surprenante, il est parfois intéressant d'exécuter plus de threads sur un processeur que ce dernier ne peut en traiter (nombre de cœurs, théoriquement deux fois le nombre de cœurs avec l'hyperthreading). C'est notamment le cas lorsque ces threads accèdent à une mémoire partagée et que cette mémoire est alors déjà disponible dans les caches.
2. Certaines opérations complexes de la base de données lisent et écrivent de grandes quantités de données, ce qui surcharge la mémoire.Contrôleur Si les données pour ces opérations sont déjà réparties sur la mémoire locale de plusieurs processeurs, les threads pour l'accès aux données doivent être répartis sur plusieurs processeurs. Cela permet d'éviter les problèmes de mémoire individuelle.Contrôleur et la charge de travail est répartie sur plusieurs connexions de stockage et de mémoire.Contrôleur distribués.
3. Dans certains cas, les opérations de base de données telles que les opérations de jointure devraient être implémentées en accordant une attention particulière à l'architecture Numa. Les premières "directives" pour de telles implémentations sont discutées dans la littérature de recherche (Albutiu, Kemper & Neumann, 2012).

Avenir de Numa

Pendant plusieurs décennies, les logiciels de base de données n'ont pas été les seuls à être créés en partant du principe que la vitesse de traitement augmenterait avec la prochaine génération de processeurs, notamment parce que la fréquence d'horloge augmentait. Pour des raisons techniques, cet automatisme n'est plus valable depuis le début du millénaire.

Des fournisseurs comme Intel ou AMD propagent des systèmes dans lesquels le travail est réparti sur plusieurs processeurs, chacun avec plusieurs cœurs. Comme il en est question dans l'article, une architecture semble s'imposer, dans laquelle l'accès à la mémoire est plus ou moins complexe - en fonction de l'endroit où la mémoire a été physiquement allouée (désigné par Numa).

Les logiciels d'application doivent donc être revus afin de pouvoir exploiter le parallélisme qui a accompagné la disponibilité des architectures multicœurs. Corollairement, les logiciels doivent prendre en compte les spécificités de l'architecture Numa et optimiser l'allocation et l'accès à la mémoire.

Alors que les systèmes d'exploitation modernes fournissent certaines optimisations dans ce domaine, les applications critiques en termes de performance, comme les Hana-DB permet de réaliser des améliorations allant bien au-delà.

Dans la Hana-La base de données Numa intègre déjà un certain nombre de ces améliorations. Néanmoins, l'implémentation de bases de données sur les architectures Numa n'en est qu'à ses débuts et d'autres améliorations sont attendues.