Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur [DEBUTANT] - Instance SQL gourmande en ressources

[DEBUTANT] - Instance SQL gourmande en ressources

4 réponses
Avatar
Nesta
Bonjour à tous,

Nous avons un serveur Windows 2003 Standard Edition SP2 avec un
microprocesseur Intel Xeon 3,06 GHz, 2,00 Go de RAM sur lequel tourne SQL
Server 2000 - 8.00.760 (Build 3790 : SP2).

Nous avons depuis quelques temps une instance de SQL dans le gestionnaire
des tâches (sqlservr.exe) qui est très gourmande en ressources.
Nous avons rebooté le serveur il y a 50 minutes, et nous sommes déjà à 1 027
352 Go de consommation mémoire...
Est-ce que quelqu'un sait pourquoi ? Pouvez-vous nous apportez une solution
à ce problème si vous en avez ?
J'ai entendu dire que ce genre de soucis pouvait se manifester si on n'avait
pas le SP4 ? Est-ce fondé ?
Y-a-t-il beaucoup de conséquence à la migration en SP4 ?
Merci d'avance pour votre retour d'expérience.


Nesta
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Rudi Bruchez
Bonjour,

Nesta a écrit:

Nous avons depuis quelques temps une instance de SQL dans le gestionnaire
des tâches (sqlservr.exe) qui est très gourmande en ressources.
Nous avons rebooté le serveur il y a 50 minutes, et nous sommes déjà à 1 027
352 Go de consommation mémoire...



Tu veux dire que tu as un péta-octets de RAM (ou qqch du genre) ? Je
suppose que tu veux plutôt dire 1 Go.
Ce comportement est normal, et cela ne pose aucun problème : SQL Server
utilise la RAM comme cache de données. SQL Server est fait pour être
seul sur un serveur.
Si tu veux limiter la RAM, tu peux décider d'attribuer une limite
maximum dans les propriétés de l'instance.

--
Rudi Bruchez
Consultant independant, MCDBA, MCITP, MCT, MVP SQL Server
http://www.babaluga.com/
http://rudi.developpez.com/
Avatar
Fred BROUARD
Nesta a écrit :
Bonjour à tous,

Nous avons un serveur Windows 2003 Standard Edition SP2 avec un
microprocesseur Intel Xeon 3,06 GHz, 2,00 Go de RAM sur lequel tourne SQL
Server 2000 - 8.00.760 (Build 3790 : SP2).

Nous avons depuis quelques temps une instance de SQL dans le gestionnaire
des tâches (sqlservr.exe) qui est très gourmande en ressources.
Nous avons rebooté le serveur il y a 50 minutes, et nous sommes déjà à 1 027
352 Go de consommation mémoire...
Est-ce que quelqu'un sait pourquoi ? Pouvez-vous nous apportez une solution
à ce problème si vous en avez ?



Cze n'est pas un problème et comme vous l'a dit RB c'est la mise en
cache. Les données ne sont JAMAIS traitées depuis le disque... Un SGBD
client serveur met en cache (en ram) les données qu'il doit requêter...

Voici un extrait d'un article en ligne vous expliquant comment cela
fonctionne

"
[...]
en matière d'alimentation du cache : la règle est commune, c'est LRU qui
dicte sa loi... LRU pour Last Recent Use, c'est à dire "moins récemment
utilisé". Autrement dit pour faire place à une nouvelle mise en cache,
l'espace mémoire le plus anciennement accédé doit céder sa place.

1.1 – Cache et RAM

En fait LRU ne va se déclencher que si SQL Server manque de mémoire.
Tant que SQL Server constate qu’une partie de la RAM n’est pas mis à sa
disposition , il la prendra, quitte à soutirer toute la mémoire
disponible. Il est programmé pour vampiriser toute la RAM, celle de l’OS
exceptée, au mépris de toutes les applications. Seul l’OS s'il s'estime
stressé est autorisé à lui demander d’en restituer... Plus il a de
mémoire et plus la base est petite, moins LRU se déclenchera. Dans un
tel cas, des données vieilles de plusieurs années peuvent persister en
mémoire, jusqu'à l'arrêt sur serveur.
L'adéquation RAM/mise en cache peut être mesurée à l'aide des compteurs
du moniteur de performance. Dès que cette adéquation commence à
diminuer, les données doivent être lues sur le disque, et c'est là que
le système bascule...
Prenez conscience que le temps de lecture d'un bit dans une RAM est de
l'ordre de 10 nano secondes tandis que celui d'un disque est de l'ordre
de 10 ms. Entre les deux un écart de 1 000 000. Oui, j'ai bien dit UN
MILLION. Une lecture disque est un million de fois moins rapide qu'une
lecture mémoire. Cette différence doit toutefois être amendée par le
fait que d’un côté, entre la mémoire et le processeur il existe tout un
circuit électronique et des micro programmes pour charger et décharger
le processeur, et que de l'autre côté, le disque lui même possède
souvent un cache, ce qui fait que l'un dans l'autre l'écart effectif est
plus proche d'un rapport de mille que du million...
En conclusion, dès que le ratio de mise en cache commence à diminuer
singulièrement, les performances baissent de manière très sensible. Une
baisse de ce ration de 20% est déjà très sensible. Au delà, la file
d’attente des demandes de lecture du disque se met à s’allonger
démesurément et l’on se retrouve dans une situation d’engorgement digne
du périphérique un vendredi soir vers 17 heures avec chaussée extérieur
un accrochage et chaussée intérieure une voie immobilisée par une panne
d’essence !
[...]
"
http://www.sqlspot.com/Voulez-vous-optimiser-votre.html



J'ai entendu dire que ce genre de soucis pouvait se manifester si on n'avait
pas le SP4 ? Est-ce fondé ?



non... comportement normal !

Y-a-t-il beaucoup de conséquence à la migration en SP4 ?



oui : une meilleure sécurité et quelques bugs corrigés. mais pas de
changement. Manip indolore.
A +

Merci d'avance pour votre retour d'expérience.


Nesta






--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Avatar
Nesta
Bonjour Rudi,

Merci pour les infos.
Quelles conséquences est-ce que ça peut entraînner si je limite la RAM
utilisable par SQL ?
En fait, le fait qu'il utilise autant de RAM n'est un problème en soit,
sachant que SQL est effectivement seul à tourner dessus (hormis un soft de
sauvegarde).
Ce que je ne comprends pas, c'est que lorsque qu'il n'y a plus de requêtes
exécutées, la charge reste la même.
Ce cache n'est-il pas sensé se vider à un moment ?

Merci d'avance pour tes infos.


Nesta


"Rudi Bruchez" <rudi#nospam#at#babaluga.com> a écrit dans le message de
news:
Bonjour,

Nesta a écrit:

Nous avons depuis quelques temps une instance de SQL dans le gestionnaire
des tâches (sqlservr.exe) qui est très gourmande en ressources.
Nous avons rebooté le serveur il y a 50 minutes, et nous sommes déjà à 1
027 352 Go de consommation mémoire...



Tu veux dire que tu as un péta-octets de RAM (ou qqch du genre) ? Je
suppose que tu veux plutôt dire 1 Go.
Ce comportement est normal, et cela ne pose aucun problème : SQL Server
utilise la RAM comme cache de données. SQL Server est fait pour être seul
sur un serveur.
Si tu veux limiter la RAM, tu peux décider d'attribuer une limite maximum
dans les propriétés de l'instance.

--
Rudi Bruchez
Consultant independant, MCDBA, MCITP, MCT, MVP SQL Server
http://www.babaluga.com/
http://rudi.developpez.com/


Avatar
Nesta
Bonjour Fred,

Merci pour l'extrait d'article que je vais m'empresser de lire.



Cordialement.


"Fred BROUARD" a écrit dans le message de news:
%
Nesta a écrit :
Bonjour à tous,

Nous avons un serveur Windows 2003 Standard Edition SP2 avec un
microprocesseur Intel Xeon 3,06 GHz, 2,00 Go de RAM sur lequel tourne SQL
Server 2000 - 8.00.760 (Build 3790 : SP2).

Nous avons depuis quelques temps une instance de SQL dans le gestionnaire
des tâches (sqlservr.exe) qui est très gourmande en ressources.
Nous avons rebooté le serveur il y a 50 minutes, et nous sommes déjà à 1
027 352 Go de consommation mémoire...
Est-ce que quelqu'un sait pourquoi ? Pouvez-vous nous apportez une
solution à ce problème si vous en avez ?



Cze n'est pas un problème et comme vous l'a dit RB c'est la mise en cache.
Les données ne sont JAMAIS traitées depuis le disque... Un SGBD client
serveur met en cache (en ram) les données qu'il doit requêter...

Voici un extrait d'un article en ligne vous expliquant comment cela
fonctionne

"
[...]
en matière d'alimentation du cache : la règle est commune, c'est LRU qui
dicte sa loi... LRU pour Last Recent Use, c'est à dire "moins récemment
utilisé". Autrement dit pour faire place à une nouvelle mise en cache,
l'espace mémoire le plus anciennement accédé doit céder sa place.

1.1 – Cache et RAM

En fait LRU ne va se déclencher que si SQL Server manque de mémoire. Tant
que SQL Server constate qu’une partie de la RAM n’est pas mis à sa
disposition , il la prendra, quitte à soutirer toute la mémoire
disponible. Il est programmé pour vampiriser toute la RAM, celle de l’OS
exceptée, au mépris de toutes les applications. Seul l’OS s'il s'estime
stressé est autorisé à lui demander d’en restituer... Plus il a de mémoire
et plus la base est petite, moins LRU se déclenchera. Dans un tel cas, des
données vieilles de plusieurs années peuvent persister en mémoire, jusqu'à
l'arrêt sur serveur.
L'adéquation RAM/mise en cache peut être mesurée à l'aide des compteurs du
moniteur de performance. Dès que cette adéquation commence à diminuer, les
données doivent être lues sur le disque, et c'est là que le système
bascule...
Prenez conscience que le temps de lecture d'un bit dans une RAM est de
l'ordre de 10 nano secondes tandis que celui d'un disque est de l'ordre de
10 ms. Entre les deux un écart de 1 000 000. Oui, j'ai bien dit UN
MILLION. Une lecture disque est un million de fois moins rapide qu'une
lecture mémoire. Cette différence doit toutefois être amendée par le fait
que d’un côté, entre la mémoire et le processeur il existe tout un circuit
électronique et des micro programmes pour charger et décharger le
processeur, et que de l'autre côté, le disque lui même possède souvent un
cache, ce qui fait que l'un dans l'autre l'écart effectif est plus proche
d'un rapport de mille que du million...
En conclusion, dès que le ratio de mise en cache commence à diminuer
singulièrement, les performances baissent de manière très sensible. Une
baisse de ce ration de 20% est déjà très sensible. Au delà, la file d’attente
des demandes de lecture du disque se met à s’allonger démesurément et l’on
se retrouve dans une situation d’engorgement digne du périphérique un
vendredi soir vers 17 heures avec chaussée extérieur un accrochage et
chaussée intérieure une voie immobilisée par une panne d’essence !
[...]
"
http://www.sqlspot.com/Voulez-vous-optimiser-votre.html



J'ai entendu dire que ce genre de soucis pouvait se manifester si on
n'avait pas le SP4 ? Est-ce fondé ?



non... comportement normal !

Y-a-t-il beaucoup de conséquence à la migration en SP4 ?



oui : une meilleure sécurité et quelques bugs corrigés. mais pas de
changement. Manip indolore.
A +

Merci d'avance pour votre retour d'expérience.


Nesta




--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************