[SQL Server] Un peu de théorie sur la mémoire…

Ce billet présente différents aspects théoriques relatifs à la mémoire sous SQL Server. Il aborde également l’importance du performance tuning dans l’univers de SQL Server.

Concepts généraux

          Importance de la mémoire

Au sein d’une instance SQL Server relationnelle (OnLine Transaction Processing, ou OLTP), une base de données se compose de peu de choses : un fichier de données MDF, un fichier de logs LDF, un moteur relationnel SQL Server, un moteur de stockage et un mécanisme d’écriture dans le journal qui assure la bonne marche des transactions.

Lorsqu’un utilisateur veut extraire des données, il lance indirectement une commande SELECT. Cet ordre SQL, qui est en fait une transaction, est alors enregistré par le journal de transactions LDF, puis le relais est donné au moteur transactionnel qui va inspecter la mémoire afin de savoir si les lignes des tables concernées par la requête de l’utilisateur sont en mémoire. Si elles le sont, la requête est exécutée en lisant les données en mémoire, ce qui conduit à l’extraction puis l’envoi des résultats à l’utilisateur. Dans le cas échéant (i.e., données non en mémoire), il est alors demandé, par le moteur de stockage, au moteur relationnel d’avoir à les y placer, et tant que cette demande n’est pas totalement satisfaite, elle est mise en sommeil. C’est donc pourquoi, avoir les pages de données toujours en mémoire est recommandé[1].

Lorsque le moteur de stockage a fini son travail, le moteur relationnel reprend le sien. Et quand les données sont délivrées (suite à la demande de l’utilisateur), une trace est laissée dans le journal pour signaler la terminaison (ou non) de la transaction.

Quand un utilisateur veut effectuer des mises-à-jour dans une base de données, il utilise indirectement la commande UPDATE, INSERT ou DELETE. Et à l’instar de la commande SELECT, la commande de mise-à-jour employée est enregistrée dans le journal des transactions, mais toutefois, une question subsiste : la donnée est-elle présente en RAM ? A fortiori, oui.

En effet, sous SQL Server Management Studio (SSMS) ou Enterprise Manager (EM), ou tout autre client d’administration de SQL Server, en modifiant une donnée (au hasard, via un UPDATE) en mémoire, et en positionnant un flag pour indiquer que celle-ci a changé, la transaction, alors, réalisée est marquée comme terminée dans le journal. Dans les processus, toujours sous SSMS ou EM, on peut noter la présence d’un processus particulier qui inspecte la mémoire à la recherche des données modifiées. Il possède, pour cela, de flags et va regrouper les modifications pour en optimiser le stockage sur disque. Ce processus s’appelle lazy writer dont le rôle principal est de s’assurer qu’il y ait assez de pages en mémoire, au sein de SQL Server, pour accueillir de nouvelles données (ou plans).

Toutes ces constatations relativement simples permettent de déduire que :

  • La lecture des données s’effectue toujours en mémoire.
  • L’écriture de données s’effectue d’abord en mémoire, puis est différée et regroupée.

Si l’utilisateur décide de renouveler la même requête SELECT qu’il a entreprise précédemment, que constatera-t-il ? Qu’elle est exécutée plus rapidement que la première fois. Et comment se fait-il ? La réponse est simple : non seulement les données sont déjà en mémoire, mais surtout la requête est, elle aussi, en cache, vu que la façon de la traiter (autrement dit, son plan d’exécution) a déjà été établi.

Sous SQL Server, la mise en cache d’une requête consiste tout simplement à enregistrer la chaîne de caractère qui représente l’exécution de l’ordre SQL, avec la référence de son
plan d’exécution. Cela nous mène donc au constat suivant : concernant les requêtes réutilisées, leur syntaxe est mise en cache avec leur plan d’exécution.

Comment fonctionne concrètement un cache sous SQL Server ? Sous deux angles : celui des procédures T-SQL et celui des données. Et que ce soit l’une ou l’autre, SQL Server utilise un algorithme appelé LRU (Least Recently Used), qui va lui permettre de déterminer l’espace mémoire le plus anciennement utilisé afin qu’il puisse faire place à une nouvelle mise en place. Autrement dit : les procédures (ou plans d’exécution, plus logiquement) ou les données les moins utilisées s’exposent à une suppression possible du cache de SQL Server.

En vérité, LRU ne va être utilisé par SQL Server que si celui-ci manque de mémoire[3]. En effet, tant qu’il y a encore de la RAM, SQL Server va continuer à stocker des données au mépris des autres applications présentes au sein du système d’exploitation où il se trouve.

C’est donc pourquoi il n’est non seulement de bon ton de toujours paramétrer la mémoire de l’instance SQL Server de sorte qu’au moins 2 Go de données soient laissés à l’OS mais également de disposer de suffisamment de RAM.

Mathématiquement parlant, plus le système d’exploitation a de la mémoire, plus la base de données est petite, moins le SGBD aura besoin de faire appel à LRU. Et dans un tel cas, des données vieilles (i.e., datant de plusieurs années) peuvent rester en mémoire jusqu’à l’arrêt du serveur. Néanmoins, cela n’empêche pas une chose : plus la mémoire en cache diminue, moins les performances du SGBD sont au rendez-vous. Et moins il y a de la RAM, plus il y a des chances que l’OS prenne l’initiative de stocker les pages de données au sein de la mémoire virtuelle, réalisant ainsi ce qu’on appelle une pagination (ou swapping).

C’est pour ces différentes raisons qu’il est souhaitable de non seulement toujours s’assurer qu’il y ait suffisamment de RAM pour SQL Server et l’OS mais également de verrouiller les pages de données en RAM afin d’éviter leur pagination, qui aura pour effet de faire perdre le contrôle à SQL Server concernant la gestion de ses pages de données.

La section suivante va aborder le cas de l’utilité de l’optimisation et du performance
tuning d’un SGBD comme SQL Server.


          Notions de performance tuning et d’optimisation de la mémoire

Avant d’aborder l’utilité de l’optimisation d’un SGBD comme SQL Server, il serait intéressant de faire un bref parallèle avec nous-mêmes, humainement parlant, en ce qui concerne notre mémoire. Lorsque, dans une conversation, nous devons citer des chiffres, une anecdote lue dans un article, prononcer le mot qui décrit précisément notre pensée, y parvenons-nous sans hésiter ? Si nous y arrivons la plupart du temps de manière satisfaisante, n’y a-t-il pas, parfois, des mots qui nous échappent, des informations qui nous restent sur le bout de la langue, jusqu’à ce que nous nous en souvenions subitement, lorsqu’il est bien trop tard ?

Parfois, notre mémoire est plus qu’un outil de conversation : lorsque nous devons retrouver notre chemin dans les rues d’une ville, ou nous souvenir s’il faut couper le fil jaune ou le fil orange pour désamorcer une bombe prête à exploser… Même si nous ne sommes pas souvent confrontés à ce dernier cas, nous comprenons que parfois, accéder à nos souvenirs rapidement, de façon fluide, sans à-coups, est une nécessité.

Or, justement, un SGBD est comme une mémoire : il contient des données importantes, sinon vitales, pour l’entreprise, et la capacité donnée aux acteurs de cette entreprise de pouvoir y accéder efficacement, rapidement, avec des temps de réponse consistants, est essentielle. Et l’efficacité du bon fonctionnement d’une base de données passe par une bonne optimisation du moteur SQL.

La sous-section précédente a permis de remarquer l’importance de la mémoire au sein d’un SGBD. En effet, sous SQL Server, les données comme les requêtes (i.e., tout code T-SQL, y compris les requêtes SQL simples) sont mises en cache. C’est donc ce qui nous amène à accorder une place importance à la notion de mémoire, en général, à celle de cache en particulier.

Arrivés à ce stade de notre réflexion, beaucoup penseraient que pour optimiser une base de données, par exemple, il suffirait simplement d’ajouter de la RAM. Cela n’est pas forcément faux, dans le sens où un SGBD aura besoin d’une RAM conséquente pour gérer un nombre exponentiel de données de façon optimisée… mais « bêtement » coûteux, en admettant que le modèle de données soit déjà correct quand il y a la possibilité de pouvoir effectuer de grandes économies (notamment financières) en optimisant une base de données plutôt qu’à investir régulièrement dans l’achat de nouveaux composants informatiques (barrettes de RAM,…), plus sophistiqués, dans cette optique.

En effet, en accordant plus d’importance à l’optimisation et au performance
tuning, une base de données gagnerait non seulement en efficacité technique, mais surtout effectuerait de grandes économies d’argent sur le long terme.

Un performance
tuning de l’OS et de la base est souvent indispensable en préambule de toute optimisation, car les mesures de consommation de l’ordre SQL seront faussées par les réactions de la base. C’est donc pourquoi il est conseillé de lire le document relatif aux bonnes pratiques d’utilisation de SQL Server (SQL Server-Best-practices) et d’installation et exploitation de SQL Server (SQL Server – Normes d’installation et d’exploitation).

Architecture de la mémoire interne de SQL Server

Un focus particulier sera fait sur le SQLOS[2] (et donc sur les versions de SQL Server supérieures ou égales à 2005).

          Présentation des différents types de pages de mémoire et fonctionnement

SQLOS gère la mémoire de façon hiérarchisée selon trois niveaux. La base de la hiérarchie est constituée des nœuds de mémoire. Le niveau suivant est constitué des clercs de mémoire, des caches mémoire et des pools de mémoires. Le niveau supérieur comprend les objets de mémoire.

Les nœuds de mémoire sont les principaux allocateurs de ressources des composants SQL Server. Ils sont constitués d’allocateurs de pages (single page allocator, multi-page allocator, large page allocator et reserved page allocator[4]), d’un allocateur de mémoire virtuelle (virtual memory allocator, qui utilise l’API Windows VirtualAlloc pour l’allocation de pages de mémoires hors-buffer pool) et d’un allocateur de mémoire partagée (shared memory allocator, qui utilise l’API Windows FileMapping pour l’allocation de pages de mémoire partagées).

Les clercs sont des mécanismes utilisés pour accéder aux nœuds de mémoire. Ainsi, quand un composant a besoin de mémoire, il questionne son clerc correspondant qui va alors lui allouer de la mémoire grâce à un allocateur fournit par un nœud de mémoire. Ainsi, par exemple, si un composant a besoin d’allouer de la mémoire à une procédure stockée, c’est au clerc associé au cache des procédures, appelé CACHESTORE_OBJCP, qu’il va s’adresser. Et ce clerc s’appelle MEMORYCLERK_OBJCP. Ce dernier va alors utiliser un allocateur de pages pour allouer de la mémoire. Dans le cas où des pages de mémoire doivent être prises dans le buffer pool par le clerc, c’est l’allocateur single page allocator qui sera utilisé. Tandis que pour ce qui est des autres allocateurs de pages, ces derniers prendront de la mémoire hors du buffer pool en utilisant, notamment, l’API Windows appelée VirtualAlloc via le virtual memory allocator.

Les objets de mémoire sont des « tas », et il existe 3 types de « tas » : objets de mémoire variable, objets de mémoire incrémentale et objets de mémoire de taille fixe. En d’autres termes, les objets de mémoire sont utilisés par les composants de mémoire (caches,…) pour le (re)dimensionnement, suivant une taille arbitraire, de leur mémoire interne. Un objet de mémoire possède également son propre clerc qui accède aux nœuds.

Le schéma ci-dessous résume de façon synthétisée l’architecture de la mémoire interne de MSSQL :

          Présentation du buffer pool

                    Qu’est-ce que le buffer pool

Le buffer pool (ou buffer cache) est un type de mémoire de niveau intermédiaire qui est utilisé par l’instance SQL Server comme source de mémoire pour ses données. Le buffer pool est très utile au sens qu’il permet d’améliorer les performances du moteur SQL en permettant l’accès des données en mémoire.

La taille standard des pages de mémoire stockées au sein du buffer pool est de 8 Ko, dans la mesure où cela correspond à la taille des pages de données de SQL Server. De ce fait, il valide/annule des blocs de mémoire de 8 Ko de façon granulaire.

Comme vu précédemment, le buffer pool, de part la taille de ses pages de mémoire, utilise le single page allocator (via son clerc de mémoire correspondant) pour s’allouer des pages quand il peut. Et en tant que principale source de mémoire de SQL Server, c’est au sein du buffer pool que les autres composants de mémoire de SQL Server (i.e., cache des requêtes,…) puissent des ressources mémoire, lorsqu’ils veulent s’allouer 8 pages de mémoire. Les pages « puisées » sont appelées Stolen pages.

Le schéma ci-dessus résume le comportement du buffer pool en cas de besoin de pages de mémoire :


Légende :

1 : Demande d’allocation de nouvelles pages de mémoire par le buffer pool à son clerc correspondant.

2 : Le clerc de mémoire correspondant au buffer pool transmet la demande au nœud de mémoire qui sélectionne alors le single page allocator.

3 : Le singe page allocator fournit, alors, de la mémoire au buffer pool.


                    Fonctionnement général du buffer pool

Au sein d’une architecture 32 bits, lors du démarrage d’une instance SQL Server, le buffer pool décide toujours de la quantité de mémoire (virtual address space, ou VAS) à s’allouer pour son utilisation. Il base sa décision sur la quantité de RAM présente au sein de la machine où tourne SQL Server. Si la quantité de RAM est supérieure ou égale à l’ensemble du VAS qu’il peut utiliser, il laissera 256 Mo de VAS aux composants externes[5] plus le nombre de threads que SQL Server est configuré pour utilisé multiplié par 512 Ko (qui est la taille de la pile de thread SQL Server[6]). Le nombre de threads par défaut de SQL Server varie selon les versions de SQL Server (128 pour SQL Server 7.0, 255 pour SQL Server 2000 et, pour SQL Server 2005 et plus valeur dynamique dépendant du nombre d’ordonnanceurs (processeurs) configurés[7]).

Par défaut, avec un VAS supérieur à 2 Go, le buffer pool laissera 256 Mo + 256×512 Ko=384 Mo de VAS. Et c’est ce VAS qu’on appelle (peu conventionnellement) MemToLeave que l’on peut bien sûr configurer manuellement (dans les paramètres de démarrage de SQL Server), si nécessaire, en spécifiant l’option de traceflag -g suivie de la valeur à affecter en Mo (i.e., -g 512).

Le calcul de la quantité de mémoire allouée au buffer pool (après réservation du VAS ou non, selon l’architecture de SQL Server), s’effectue selon un certain nombre de facteurs, à commencer par l’état d’activation d’AWE (Address Windowing Extension, voir plus loin) ou non. Si AWE n’est pas activé, alors le buffer pool est dimensionné selon le VAS qui lui est initialement réservé (via Min Server Memory et Max server memory) moins le VAS alloué aux composants externes (calculé précédemment si architecture 32 bits). Par exemple, si SQL Server est sur un OS de 4 Go ou plus, alors, la taille du buffer pool sera la suivante :

  • Si le commutateur /3GB (ou /USERVA) est désactivé (comportement par défaut) :

2048 Mo (2 Go) – 384 Mo= 1664 Mo.

  • Si le commutateur /3GB (ou /USERVA) est activé :

3072 Mo (3 Go) – 384 Mo= 2688 Mo.

Si AWE est activé, la taille maximale du buffer pool correspondra à celle de l’OS (ou du Max server memory s’il est correctement configuré).

Au sein d’une architecture 64 bits, la notion de « MemToLeave » (ou plutôt, de VAS Reservation pour les composants hors-buffer pool) expliquée ci-dessus n’existe plus. En effet, le VAS pour SQL Server 64 bits n’est pas aussi limité que pour sa version 32 bits (dont le VAS est de 2 Go) dans la mesure où il est de 8 To (7 To pour les architectures IA), ou 2 To dans le cas de Windows Server 2008, ce qui fait qu’il n’est, à l’heure actuelle, pas encore possible d’adresser au maximum tout le VAS de l’OS 64 bits au sein duquel tourne SQL Server.

De ce fait, lors de l’initialisation d’une instance SQL Server en environnement 64 bits, la réservation de VAS n’arrive pas du fait de la (grande) quantité de VAS déjà disponible au sein d’un système 64 bits.

C’est pour cette raison qu’il est préférable de privilégier l’utilisation d’une architecture 64 bits plutôt que 32 bits. D’autant plus que :

  • Cela permet de se prémunir au maximum contre la fameuse erreur « There is not enough memory to run the query » quand SQL Server est amené à exécuter des requêtes « hors-normes » dont le niveau de consommation des pages mémoire est supérieur au VAS qui leur est réservé (MemToLeave), et préalablement configuré ou non (384 Mo par défaut, pour rappel).
  • De ne pas avoir à réduire la taille du buffer pool dans le but de laisser un peu de VAS aux composants externes « hors-normes ».
  • En architecture 32 bits, le risque de fragmentation de VAS est particulièrement présent. En effet, cela peut arrive quand un bloc de mémoire est alloué à partir du MemToLeave, puis libéré plus tard laissant ainsi de très petits blocs de mémoire contiguës disponibles. Cela signifie que l’on peut disposer de 200 Mo de mémoire disponible, mais si le plus gros bloc de mémoire contiguë vaut seulement 4 Mo et qu’une demande d’allocation de 8 Mo est demandée, alors la requête peut échouer.

Remarquons d’ailleurs que la taille de pile par défaut, pour SQL Server 64 bits, n’est non plus de 512 Ko mais 2 Mo.

Après l’initialisation d’une instance SQL Server, le buffer pool valide les pages à la demande, selon l’état de la mémoire interne et le niveau de pression de la mémoire externe. Il calcule la quantité de pages de mémoire qu’il pense devoir valider avant toute pression potentielle de mémoire. Un tel calcul, qu’il réalise fréquemment durant tout le cycle de vie d’une instance, lui permet d’agir de manière proactive en limitant, au maximum, les risques de pagination.

La quantité de pages de mémoire qu’il pense valide avant pression externe s’appelle, dans le jargon de SQL Server, Target pages ou Target memory. La valeur de Target memory ne peut excéder le Max server memory spécifié au sein d’une instance pour le buffer pool. Et même si le Min Server Memory est configuré de façon à égaler le Max server memory, le buffer pool ne validera de la mémoire qu’à la demande.

                    Valeurs de paramétrage du buffer pool

Concernant l’allocation de la taille maximale de la mémoire pour l’instance SQL Server, en règle générale, la bonne pratique est de spécifier une valeur maximale de sorte qu’au moins 2 Go soient laissés à l’OS. Le tableau ci-dessous donne un résumé analytique des paramétrages pouvant être effectués pour le Max server memory d’une instance OLTP :

Mémoire totale du serveur (en Go) Maximum server memory adéquat (en Mo)
2 1500
4 3200
6 4800
8 6400
12 10000
16 13500
24 21500
32 29000
48 44000
64 60000
72 68000
96 92000
128 124000

Les valeurs sont, ici, arbitraires. De ce fait, elles doivent être adaptées au cas par cas.

                    Interactions entre le buffer pool et AWE (SQL Server 32 bits seulement)

Au sein d’une instance SQL Server 32 bits, l’activation des commutateurs de mémoire /3GB et/ou de /USERVA et/ou de /PAE (tous les 3 au niveau Windows) ne permettant pas à SQL Server de profiter pleinement de la RAM supplémentaire (au-delà de 4 Go), c’est là qu’intervient toute l’utilité d’AWE (Address Windowing Extensions).

AWE est une fonctionnalité qui permet à des systèmes, basés sur une architecture 32 bits, d’accéder à de grandes quantités de mémoire.

Dans le cas de SQL Server, AWE n’est utile que si la mémoire physique disponible est supérieure à l’espace d’adressage virtuel en mode utilisateur, et que plus de 4 Go de RAM est demandé par l’instance SQL Server.

Quand AWE est activé, il y a principalement 2 choses à savoir concernant le comportement du buffer pool :

  • Le buffer pool utilise son clerc de mémoire correspondant pour allouer de la mémoire à travers le mécanisme AWE. Cela signifie que toutes les pages allouées via le single page allocator seront allouées à travers AWE.
  • Au vu des remarques du point précédent, l’utilisation du Task Manager n’est d’aucune utilité pour récupérer des informations pertinentes sur la quantité de mémoire allouée à SQL Server.
Au sein de SQL Server, le seul composant de mémoire interagissant avec AWE est le buffer pool.
Notons, d’ailleurs, qu’AWE est inutile au sein de SQL Server 64 bits.

Notion d’architecture NUMA

NUMA (Non-Uniform Memory Access) est une architecture qui permet de regrouper des noeuds de processeurs, utilisant leur propre mémoire locale, et de les relier entre eux par des bus capable de délivrer plusieurs Go par seconde. Au sein d’une architecture NUMA, un processeur n’accédera pas dans les mêmes délais à une page de données en mémoire si celle-ci fait partie d’une mémoire locale ou distante.

NUMA est régit par différents concepts :

  • Nœud NUMA (NUMA node) : il s’agit d’un groupe de processeurs qui possèdent leur propre mémoire (et éventuellement leur propre canal I/O). En temps normal, chaque CPU peut accéder à la mémoire associée à d’autres groupes, de manière cohérente. Le nombre de CPUs au sein d’un groupe NUMA dépend du matériel, mais notons toutefois qu’il est plus rapide d’accéder à la mémoire locale qu’à la mémoire associée à d’autres groupes NUMA (d’où le nom Non-Uniform Memory Access).
  • Mémoire locale (Local memory) : il s’agit de la mémoire dans le même nœud que le CPU actuellement en train de lancer un thread.
  • Mémoire étrangère/externe/distante (Foreign memory, ou Remote memory) : il s’agit de la mémoire n’appartenant pas au nœud au sein duquel le thread est en cours de traitement.
  • Taux NUMA (NUMA ratio) : il s’agit du ratio Coût de l’accès à la mémoire étrangère/Coût de l’accès à la mémoire locale.

L’idée générale d’une architecture NUMA est de dépasser les limitations propres à une architecture SMP (Symmetric Multi-Processing) ou UMA (Uniform Memory Access) grâce à sa scalabilité. En effet, au sein d’une architecture non-NUMA, tous les accès mémoire sont postés dans le même bus de mémoire partagée. Cela fonctionne bien pour une machine avec un petit nombre de CPUs (< 8), mais pas dans le cas contraire où un très grand nombre de goulots d’étranglements peuvent intervenir.

NUMA permet donc d’éviter cela en limitant le nombre de CPUs sur n’importe quel bus mémoire et en les reliant à des nœuds possédant leur propre mémoire locale. D’où l’intérêt d’installer SQL Server sur une machine supportant NUMA quand un grand nombre de CPUs sont destinés à être utilisés.
Pour plus de détails sur l’architecture NUMA (et l’utilisation de Soft-NUMA qui permet de regrouper des CPUs en nœuds, ce qui peut être utile dans le cas d’un matériel non-NUMA), vous pouvez vous référez au lien BOL suivant : http://msdn.microsoft.com/fr-fr/library/ms178144.aspx.

Pour connaître le nombre de nœuds NUMA disponibles pour SQL Server, il est possible de questionner les clercs de mémoire via les DMV (Dynamic Management Views). Vous pouvez lancer la requête suivante (compatible SQL Server 2005 minimum) :

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks
GO

Si SQL Server retourne un seul nœud de mémoire (nœud 0), cela indique que soit l’instance ne tourne pas sur du matériel NUMA, soit le matériel est configuré comme non-NUMA.

Pour aller plus loin…

Ce billet a été l’occasion de mieux comprendre l’essentiel du fonctionnement de la mémoire au sein de SQL Server. Dans de prochains billets, nous aborderons quelques éléments d’audit de la mémoire, ainsi que les différentes améliorations apportées à partir de SQL Server 2012 au niveau du management de la mémoire.

Références



[1]Le Security Policy de Windows permet de les mettre en mémoire en ajoutant le compte d’exécution de l’instance SQL Server parmi les comptes autorisés.

[2]Le SQLOS (amélioration du défunt UMS apparu avant SQL Server 2005) est un mini-OS propre à SQL Server permettant de centraliser et gérer les couches développées pour optimiser SQL Server. Les deux principales fonctions du SQLOS est la planification de tâches internes (scheduling) et la gestion de la mémoire interne. Il met également à disposition les Dynamic Management Objects (DMO) dont les DMVs (Dynamic Management Views) permettant de récupérer des informations sur l’état interne de SQL Server.

[3]Remarquons que la suppression automatique d’un plan d’exécution du cache par le lazy writer pour faire face à un manque de mémoire de SQL Server est sujet à 2 critères : sa non-utilisation en cours et son coût (ou « âge ») qui doit être proche de zéro. Son « âge » est calculé en effectuant la multiplication de son coût d’exécution estimé par le nombre de fois où il a été référencé par une (ou des) requête(s), sachant qu’à chaque analyse périodique du plan par le lazy writer, ce dernier effectue la soustraction de son âge par 1. De ce fait, moins souvent un plan est utilisé, plus rapidement son coût atteint zéro et inévitablement il s’expose à toute suppression du cache. Par ailleurs, lorsque l’âge d’un plan atteint zéro, ce dernier n’est pas tout de suite supprimé. Il faut, pour cela, que : 1) il y ait une forte pression de mémoire et que 2) le lazywriter soit en train d’analyser ledit plan (ce qu’il peut faire plus fréquemment en cas de manque de mémoire).

[4]Le large page allocator est utilisé pour les structures de données hors-normes, notamment au sein d’une architecture 64 bits ou IA. Le reserved page allocator est utilisé pour réserver des pages de mémoire spéciales utilisables en cas d’urgence (i.e., au cas où SQL Server manque de mémoire).

[5]Il s’agit notamment des composants suivants: Linked servers, procédures étendues, objets CLR (Common Language Runtime), drivers OLEDB, requêtes avec des plans d’exécution complexes et surdimensionnés, etc…

[6]Formule mathématique : (MaxWorkerThreads x StackSize)+ DefaultReservationSize.

[7]Formule mathématique de calcul dynamique : ((NumberOfSchedulers – 4)x8)+ BaseThreadCount. Où BaseThreadCount vaut 256 pour SQL Server 32 bits et 512 pour SQL Server 64 bits. Si NumberOfSchedulers est inférieur ou égal à 4, BaseThreadCount devient la valeur par défaut de MaxWorkerThreads.

Publicités

2 commentaires sur “[SQL Server] Un peu de théorie sur la mémoire…

  1. I reckon something really interesting about your blog so I saved to bookmarks .

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s