38
Chapitre 3. Optimisation du matériel
JOIN sys.partitions p
ON p.partition_id = a.container_id
WHERE bd.database_id = DB_ID('AdventureWorks') AND
object_name(p.object_id) NOT LIKE 'sys%'
GROUP BY object_name(p.object_id), bd.page_type
ORDER BY ObjectName, page_type;
max server memory
Vous pourriez vous interroger : SQL Server ne va-t-il pas s’accorder trop de
mémoire, au détriment du bon fonctionnement du système d’exploitation ? Évidemment non, la prise de mémoire est pensée au niveau de l’OS. Par défaut, SQL Server
acquiert autant de mémoire possible sans mettre en danger le système. Il utilise pour
ce faire l’API de notification mémoire (Memory Notification API) de Windows.
En réalité, SQL Server peut rendre au système la mémoire physique utilisé par le
buffer dans un cas : lorsque, fonctionnant sur une plate-forme 32 bits de version au
moins équivalente à Windows XP ou Windows 2003, et lorsque AWE est activé,
SQL Server permet une allocation dynamique (dynamic memory allocation) du buffer.
L’instance continue à acquérir de la mémoire physique jusqu’à ce que la limite
indiquée dans l’option de serveur max server memory 1 soit atteinte, ou que Windows signale qu’il n’a plus de mémoire disponible pour les applications. Lorsque
Windows signale un manque de mémoire vive, SQL Server restitue de la mémoire
(si les conditions vues précédemment sont remplies) jusqu’à atteindre la limite
inférieure indiquée dans l’option min server memory. Cette dernière option ne
signifie pas que, au démarrage, SQL Server va immédiatement occuper cette quantité de mémoire. Dans tous les cas, SQL Server acquiert sa mémoire graduellement. Elle donne simplement une limite en dessous de laquelle il n’y aura pas de
restitution de mémoire à l’OS.
Faut-il fixer la mémoire ?
Un conseil de performance remontant aux précédentes versions de SQL Server était de fixer
la mémoire, c’est-à-dire de donner une valeur identique à min server memory et max server
memory. SQL Server 2005 et 2008 gèrent dynamiquement la mémoire dans SQLOS de
façon optimale : il peut être contre performant de fixer la mémoire, et c’est inutile.
Dans le cas d’une allocation dynamique de mémoire, SQL Server ajuste sa consommation selon les disponibilités de la RAM. Autrement dit, si d’autres processus
acquièrent et libèrent de la mémoire, SQL Server en rend et en reprend en miroir.
SQL Server peut ainsi s’ajuster au rythme de plusieurs Mo par seconde.
1. Ces options sont activables avec sp_configure ou graphiquement dans SSMS.
Chapitre 3. Optimisation du matériel
JOIN sys.partitions p
ON p.partition_id = a.container_id
WHERE bd.database_id = DB_ID('AdventureWorks') AND
object_name(p.object_id) NOT LIKE 'sys%'
GROUP BY object_name(p.object_id), bd.page_type
ORDER BY ObjectName, page_type;
max server memory
Vous pourriez vous interroger : SQL Server ne va-t-il pas s’accorder trop de
mémoire, au détriment du bon fonctionnement du système d’exploitation ? Évidemment non, la prise de mémoire est pensée au niveau de l’OS. Par défaut, SQL Server
acquiert autant de mémoire possible sans mettre en danger le système. Il utilise pour
ce faire l’API de notification mémoire (Memory Notification API) de Windows.
En réalité, SQL Server peut rendre au système la mémoire physique utilisé par le
buffer dans un cas : lorsque, fonctionnant sur une plate-forme 32 bits de version au
moins équivalente à Windows XP ou Windows 2003, et lorsque AWE est activé,
SQL Server permet une allocation dynamique (dynamic memory allocation) du buffer.
L’instance continue à acquérir de la mémoire physique jusqu’à ce que la limite
indiquée dans l’option de serveur max server memory 1 soit atteinte, ou que Windows signale qu’il n’a plus de mémoire disponible pour les applications. Lorsque
Windows signale un manque de mémoire vive, SQL Server restitue de la mémoire
(si les conditions vues précédemment sont remplies) jusqu’à atteindre la limite
inférieure indiquée dans l’option min server memory. Cette dernière option ne
signifie pas que, au démarrage, SQL Server va immédiatement occuper cette quantité de mémoire. Dans tous les cas, SQL Server acquiert sa mémoire graduellement. Elle donne simplement une limite en dessous de laquelle il n’y aura pas de
restitution de mémoire à l’OS.
Faut-il fixer la mémoire ?
Un conseil de performance remontant aux précédentes versions de SQL Server était de fixer
la mémoire, c’est-à-dire de donner une valeur identique à min server memory et max server
memory. SQL Server 2005 et 2008 gèrent dynamiquement la mémoire dans SQLOS de
façon optimale : il peut être contre performant de fixer la mémoire, et c’est inutile.
Dans le cas d’une allocation dynamique de mémoire, SQL Server ajuste sa consommation selon les disponibilités de la RAM. Autrement dit, si d’autres processus
acquièrent et libèrent de la mémoire, SQL Server en rend et en reprend en miroir.
SQL Server peut ainsi s’ajuster au rythme de plusieurs Mo par seconde.
1. Ces options sont activables avec sp_configure ou graphiquement dans SSMS.