Taille mémoire du processus sqlsrvr.exe

[ccambier]

Bonjour,

Là où je travaille, j'ai un client qui s'inquiète de la taille qu'occupe le service SQL Server en mémoire.
Le serveur est un Windows 2008 (dernières mises à jour) 64bits avec 32Go de Mémoire RAM, le serveur SQL est un SQL 2008 R2 Standard et il n'y a qu'une seule base de donnée qui fait +/- 2,5Go

Le service prend +/- 6,5Go en mémoire (je sais qu'il en reste pas mal pour les autres programmes mais qd mm...

Le nombre d'utilisateur pour cette base de donnée (en concurrence) c'est environ 3 à 6 utilisateurs maximum.

Quelqu'un aurait une piste ou une explication, sachant qu'il s'agit d'un 64bits donc l'option AWE n'est pas activée.

D'avance je remercie tous les experts qui pourront me répondre et les autres bien évidemment .

[mikedavem]

Bonjour,

Ce comportement est tout à fait normal.
Tout d'abord en architecture 64 bits on peut accéder à 2^64 octects d'espace mémoire contrairement à un système 32bits où on est limité à 4Go.
Ce que vous voyez là c'est l'espace mémoire utilisé par SQL Server pour sa propre utilisation et les différents caches utilisés.

Un serveur de bases de données, de part sa nature, essaye de prendre toutes les ressources que lui sont nécessaires pour fonctionner de manière optimale et il ne rendra ces ressources que s'il y est contraint.

Vous pouvez toute fois limiter la mémoire accaparée en agissant sur l'option de serveur 'max server memory'

++

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par ccambier

Le service prend +/- 6,5Go en mémoire (je sais qu'il en reste pas mal pour les autres programmes mais qd mm...

J'ajouterais qu'un serveur de bd est uniquement dédié à la base de données, donc l'installation d'autres choses dessus est à proscrire.

[SQLpro]

Et les 6.5 Go de RAM utilisés comparé au 2.5 Go de données de la base s'expliquent généralement assez bien par le fait de développements d'application peu orthodoxe ou la tempdb va souffrir (utilisation de tables temporaires ou de variables table, recours massif aux curseurs...).

A +

[7gyY9w1ZY6ySRgPeaefZ]

Envoyé par SQLpro

Et les 6.5 Go de RAM utilisés comparé au 2.5 Go de données de la base s'expliquent généralement assez bien par le fait de développements d'application peu orthodoxe ou la tempdb va souffrir (utilisation de tables temporaires ou de variables table, recours massif aux curseurs...).

J'ai déjà vu une bd qui faisait quelques dizaines de Mo (oui, dizaines de Mo, aucune faute de frappe) qui prenait régulièrement quelques Go de RAM et arrivait régulièrement dans le top des consommateurs de mémoire par rapport à des bds bien plus volumineuses et plus sollicitées...
Je n'ai jamais eu le courage d'aller voir le code de ce site web mais dans le genre ça devait être assez comique...

[iberserk]

J'ai déjà vu une bd qui faisait quelques dizaines de Mo (oui, dizaines de Mo, aucune faute de frappe) qui prenait régulièrement quelques Go de RAM et arrivait régulièrement dans le top des consommateurs de mémoire par rapport à des bds bien plus volumineuses et plus sollicitées...
Je n'ai jamais eu le courage d'aller voir le code de ce site web mais dans le genre ça devait être assez comique...

Mon ancienne boite: site déjà consequent (400 aspx différents...)

Derrière chaque bouton une ouverture de connexion ADO... une requête en dur (jamais écrit de la même façon que ce soit dans l'ordre ou de par la casse...)...

Je vous dis pas ce que prenais le cache....

[mikedavem]

Derrière chaque bouton une ouverture de connexion ADO

Bon là je pourrais dire que si le pooling de connexion était utilisé ce n'était pas bien grave

Derrière chaque bouton une ouverture de connexion ADO... une requête en dur (jamais écrit de la même façon que ce soit dans l'ordre ou de par la casse...)...

Là on peut essayer de jouer avec l'option de base de données PARAMETERIZATION. L'inconvénient est d'avoir ici une réutilisation d'un plan d'exécution en cache non performant.

++

[iberserk]

Bon là je pourrais dire que si le pooling de connexion était utilisé ce n'était pas bien grave

C'était juste pour dire que derrière chaque bouton on avait 10 lignes de code rien que pour ouvrir la connexion créer une commande, l'execution la fermer etc

Là on peut essayer de jouer avec l'option de base de données PARAMETERIZATION. L'inconvénient est d'avoir ici une réutilisation d'un plan d'exécution en cache non performant.

PARAMETERIZATION n'impacte qu'une quantité limitée de requête (pas de top, de DISTINCT de <> de sous requête) etc...

[mikedavem]

PARAMETERIZATION n'impacte qu'une quantité limitée de requête (pas de top, de DISTINCT de <> de sous requête) etc...

C'est sûr ce n'est pas la solution miracle ...

++

[ccambier]

Merci pour vos réponses.

Ce qui m'étonne c'est qu'on a des bases de données qui tournent sur ce genre de serveur et qui n'occasionnent pas ce genre de réaction, pour la même application.

Mais je vais vérifier l'utilisation de tempdb,
et certainement proposer à mon client un audit de son serveur, ils ont p-e des programmes spécifiques qui utilisent la base de donnée et que cela ne vienne pas de notre programme standard.

au niveau du serveur je ne peux malheureusement pas dire à mon client d'utiliser un serveur dédier pour sa base de donnée, c'était dans les prérequis mais ils ont délibérément accepté de travailler comme cela.

Je vous tiens au courant dès que j'ai trouvé qqch

Merci

[dbaffaleuf]

Par rapport à vos remarques sur PARAMETERIZATION, je regarderais la quantité de mémoire prise par le cachestore des plans SQL au détriment du buffer pool pour avoir une idée de ce que celà représente:

Code :

1
2
3
4
5
6
7
SELECT name, type, single_pages_kb ,  single_pages_in_use_kb
FROM sys.dm_os_memory_cache_counters
WHERE single_pages_kb > 0
AND single_pages_in_use_kb > 0
AND type LIKE 'CACHESTORE%'
ORDER BY 3 DESC
GO

Comme il y a de moins en moins de développement en procs, et de plus en plus de no SQL ou de requêtes construites dans le code applicatif, de plus en plus de mémoire est utilisée pour cacher des plans souvent identiques.

Une autre piste, la densité des pages de données:
http://www.sqlskills.com/BLOGS/PAUL/...to-run%29.aspx

[SQLpro]

Envoyé par ccambier

au niveau du serveur je ne peux malheureusement pas dire à mon client d'utiliser un serveur dédier pour sa base de donnée, c'était dans les prérequis mais ils ont délibérément accepté de travailler comme cela.

Bien au contraire.... Il faut savoir dire à un client qu'il a délibérément pris la mauvaise voie malgré vos préconisations et que tant qu'il persistera cette problématique ne fera qu'empirer en fonction de la montée en charge.

A +

[ccambier]

j'aimerais pouvoir m'assurer de l'origine du problème avant de devoir leur dire qu'ils doivent dédier leur serveur à cette DB et investir dans un autre serveur pour leurs autres applications...

Je vais voir toutes les pistes que j'ai reçu de votre part et je vous tiens informé

[ccambier]

Voilà j'ai vérifié sur le serveur et pour l'instant je n'ai rien remarqué TempDb est normale et la taille occupée en mémoire est de 400Mo

Donc il semblerait, sans tirer trop vite de conclusion qu'il s'agirait bien de tempdb

Je dois me rendre chez eux bientôt et j'activerais des alertes sur la taille de Tempdb

En tout cas merci