35
3.1 Choix de l’architecture matérielle
SQL Server a assez de mémoire pour conserver ses pages dans le cache. Plus le nombre de pages volées est faible et mieux c’est.
Pour observer les caches, vous disposez des objets de compteur SQL:Cache,
SQL:Memory, SQL:Memory Manager et SQL:Plan Cache. Si vous voyez des fluctuations (à
la baisse) du nombre d’objets dans le cache, vous avez affaire à une pression mémoire
(sauf si vous avez exécuté des commandes qui vident le cache de plans, comme un
attachement de base de données, ou une commande DBCC).
Vous pouvez aussi utiliser les vues de gestion dynamique pour surveiller la
mémoire. Cette requête vous donne la taille des différents caches :
SELECT
Name,
Type,
single_pages_kb,
single_pages_kb / 1024 AS Single_Pages_MB,
entries_count
FROM sys.dm_os_memory_cache_counters
ORDER BY single_pages_kb DESC
Nous vous renvoyons aux ressources suivantes pour entrer dans les détails :
– Troubleshooting Performance Problems in SQL Server 2005 : http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
– Vous trouverez des informations utiles dans cette entrée de blog : http://
blogs.msdn.com/slavao/archive/2005/02/19/376714.aspx
3.1.3 Utilisation de la mémoire vive par SQL Server
Les administrateurs s’étonnent souvent de la manière dont SQL Server occupe la
mémoire vive. Certains semblent s’inquiéter de l’augmentation progressive et sans
retour de l’occupation en RAM du processus sqlservr.exe, et craignent une fuite de
mémoire et une consommation exagérée de ressources. Il s’agit au contraire d’un
comportement souhaitable. Il faut comprendre que SQL Server est conçu pour être
seul, sans concurrence d’autres applicatifs, sur un serveur. Ainsi, par défaut (vous
pouvez limiter la mémoire disponible, nous le verrons plus loin), il s’approprie toutes
les ressources raisonnablement disponibles. Si vous lisez ce livre, vous cherchez sans
doute à assurer un fonctionnement optimal de SQL Server. Vous ne pouvez le faire
réellement qu’en lui dédiant une machine, et en lui permettant de s’attribuer la
RAM dont il a besoin. Dans une configuration par défaut, une instance SQL Server
ne se limite pas en RAM. Au démarrage, elle calcule la quantité de mémoire
réservée pour ses différents éléments, et s’attribue ensuite physiquement (elle
« valide ») la mémoire réservée selon ses besoins. Comme le comportement diffère
selon les utilisations de la mémoire, nous allons détailler le comportement des
éléments importants pour les performances.
SQL Server utilise la RAM pour différents caches, dont les plus importants concernent les pages de données, et le plan d’exécution des requêtes.
3.1 Choix de l’architecture matérielle
SQL Server a assez de mémoire pour conserver ses pages dans le cache. Plus le nombre de pages volées est faible et mieux c’est.
Pour observer les caches, vous disposez des objets de compteur SQL:Cache,
SQL:Memory, SQL:Memory Manager et SQL:Plan Cache. Si vous voyez des fluctuations (à
la baisse) du nombre d’objets dans le cache, vous avez affaire à une pression mémoire
(sauf si vous avez exécuté des commandes qui vident le cache de plans, comme un
attachement de base de données, ou une commande DBCC).
Vous pouvez aussi utiliser les vues de gestion dynamique pour surveiller la
mémoire. Cette requête vous donne la taille des différents caches :
SELECT
Name,
Type,
single_pages_kb,
single_pages_kb / 1024 AS Single_Pages_MB,
entries_count
FROM sys.dm_os_memory_cache_counters
ORDER BY single_pages_kb DESC
Nous vous renvoyons aux ressources suivantes pour entrer dans les détails :
– Troubleshooting Performance Problems in SQL Server 2005 : http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
– Vous trouverez des informations utiles dans cette entrée de blog : http://
blogs.msdn.com/slavao/archive/2005/02/19/376714.aspx
3.1.3 Utilisation de la mémoire vive par SQL Server
Les administrateurs s’étonnent souvent de la manière dont SQL Server occupe la
mémoire vive. Certains semblent s’inquiéter de l’augmentation progressive et sans
retour de l’occupation en RAM du processus sqlservr.exe, et craignent une fuite de
mémoire et une consommation exagérée de ressources. Il s’agit au contraire d’un
comportement souhaitable. Il faut comprendre que SQL Server est conçu pour être
seul, sans concurrence d’autres applicatifs, sur un serveur. Ainsi, par défaut (vous
pouvez limiter la mémoire disponible, nous le verrons plus loin), il s’approprie toutes
les ressources raisonnablement disponibles. Si vous lisez ce livre, vous cherchez sans
doute à assurer un fonctionnement optimal de SQL Server. Vous ne pouvez le faire
réellement qu’en lui dédiant une machine, et en lui permettant de s’attribuer la
RAM dont il a besoin. Dans une configuration par défaut, une instance SQL Server
ne se limite pas en RAM. Au démarrage, elle calcule la quantité de mémoire
réservée pour ses différents éléments, et s’attribue ensuite physiquement (elle
« valide ») la mémoire réservée selon ses besoins. Comme le comportement diffère
selon les utilisations de la mémoire, nous allons détailler le comportement des
éléments importants pour les performances.
SQL Server utilise la RAM pour différents caches, dont les plus importants concernent les pages de données, et le plan d’exécution des requêtes.