Discussion :

[dens19]

Bonjour,

Je travaille actuellement sur une instance SQL SERVER 2000 SP4 EE hébergé sur une machine avec les caractéristiques suivantes :
- OS : Windows 2000 Advanced Server virtualisé avec VM WARE ESX SERVER 3.5.0
- 2 vCPU : DUAL Core AMD Opteron
- RAM : 4GB

Nous étudions actuellement une solution de migration vers SQL SERVER 2008 (sur Windows server 2008). En attendant la migration, je souhaiterais, étant donné que la RAM est une ressource rare dans ma société, activer le switch /3GB dans le boot.ini de la configuration actuelle, afin que SQL SERVER bénéficie de 2.7GB de RAM au lieu des 1.7GB. Je tiens à préciser que cette machine est dédiée SQL SERVER, aucune autre application ne fonctionne sur ce serveur (à part l'antivirus).

J'ai vu sur certains forums que l'utilisation de ce switch peux provoquer des instabilité de l'OS (écran bleu ), avez déjà rencontré ce problème ? Quel est votre feedback sur l'utilisation de cette fonctionnalité ?

Cdlt.

[zinzineti]

Voici un lien

A+

[dbaffaleuf]

J'ai vu sur certains forums que l'utilisation de ce switch peux provoquer des instabilité de l'OS (écran bleu ), avez déjà rencontré ce problème ? Quel est votre feedback sur l'utilisation de cette fonctionnalité ?Cdlt.

Là je veux bien voir une référence du post en question. Il peut y avoir des problème en user mode, des out of memory, OK, mais un écran bleu...

Je vois des inconvénients au /3GB. Le premier, il contraint windows a revoir toute son allocation, car elle est statique jusqu'en XP / Server 2003. Donc celà nécessite un reboot. Ensuite, ça contraint le kernel de travailler dans un espace plus réduit de 1Gb, avec tous les risques d'échec d'allocation mémoire et de ralentissements dans le fonctionnement que ça suppose. Un genre de mode dégradé, en quelque sorte.

Personnellement, je trouverais un moyen de convaincre un responsable de mettre la main à la poche et rajouter qq barrettes de RAM à cet ESX. En 2000 Advanced Server, en plus, tu peux utiliser AWE et permettre à SQL Server d'allouer beaucoup plus de mémoire.

[dens19]

Bonjour,

Tout d'abord, merci pour vos réponses !!

@dbaffaleuf : pour l'histoire de l'écran bleu en fait il s'agissait plutôt d'une déduction (étant donné que c'est parfois comme cela que l'OS windows réagit en cas d'instabilité).

@zinzineti : merci pour le lien mais j'avais déjà fait un tour sur la page de SQLPro.

Pour vous répondre évidemment que l'ajout de RAM serait la solution la plus efficace avec l'utilisation de l'AWE mais en attendant que ces négociations d'achat de RAM aboutissent, j'ai néanmoins voulu faire un test.
J'ai copié la VM sur laquelle tourne ce serveur, rajouté le switch /3GB dans le boot.ini et redémarré la machine (windows). Après avoir lancé des requêtes gourmandes je n'ai pas pu atteindre les 2,7GB, le processus "sqlsrvr.exe" plafonne à 1,7GB. Y a-t-il autre chose à configurer pour obtenir les 2,7GB ?

Cdlt.

[dbaffaleuf]

Normalement non. Regarde la valeur du compteur Perfmon :
\<instance>:Buffer Manager\Page Life Expectancy. Si elle est élevée, disons au dessus de 300 secondes en général, c'est que SQL Server a suffisamment de place avec 1,7Gb.

Et si tu peux renvoyer ce que donne un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dbcc memorystatus

, paragraphe 'Buffer Counts'

merci,

[dens19]

Voilà ce que j'obtiens pour le compteur "Page life expectancy" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
"(PDH-CSV 4.0) (Paris, Madrid (heure d'été))(-120)","\\SERVER\SQLServer:Buffer Manager\Page life expectancy"
"09/01/2010 16:35:16.437","5033"
"09/01/2010 16:35:21.437","5343"
"09/01/2010 16:35:26.437","5654"
"09/01/2010 16:35:31.437","5965"
"09/01/2010 16:35:36.437","6276"
"09/01/2010 16:35:41.437","289"
"09/01/2010 16:35:46.437","215"
"09/01/2010 16:35:51.437","171"
"09/01/2010 16:35:56.437","0"
"09/01/2010 16:36:01.452","10"
"09/01/2010 16:36:06.484","1"
"09/01/2010 16:36:11.499","11"
"09/01/2010 16:36:16.499","19"
"09/01/2010 16:36:21.499","24"
"09/01/2010 16:36:26.515","22"
"09/01/2010 16:36:31.515","11"
"09/01/2010 16:36:36.530","18"
"09/01/2010 16:36:41.530","23"
"09/01/2010 16:36:46.530","5"
"09/01/2010 16:36:51.530","13"
"09/01/2010 16:36:56.530","11"
"09/01/2010 16:37:01.530","16"
"09/01/2010 16:37:06.530","9"
"09/01/2010 16:37:11.530","5"
"09/01/2010 16:37:16.530","14"

Voici ce que j'obtiens pour la commande dbcc memorystatus section buffer count :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Commited	206800
Target	206800
Hashed	180171
InternalReservation	176
ExternalReservation	31050
Min Free	248
Visible	206800

D'après ce que je comprend si SQL SERVER pouvais utiliser plus de mémoire il le ferait puisque le compteur "Page life expectancy" passe à 0.

Cdlt.

[dbaffaleuf]

Exact. Il faudrait voir si ton paramètre 'max server memory' est par défaut ou s'il est plafonné.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sp_configure 'max server memory'
go

[dens19]

En fait j'avais configuré le serveur pour qu'il utilise toute la RAM dispo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sp_configure 'max server memory'
-- Résultat : 
-- max server memory (MB)   4	2147483647	2147483647	2147483647

Du coup mon problème persiste .

Voilà en même temps le contenu du boot.ini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Server" /fastdetect /3GB

Cdlt.

[dbaffaleuf]

Re-

Les valeurs de '\Process(sqlservr)\Private Bytes' et '\Process(sqlservr)\Working Set' ?

Quand Page Life Expectancy tombe à zéro SQL Server devrait faire des demandes d'alloc à Windows, mais comme c'est une vieille version d'OS, je ne sais pas trop comment il fonctionne. Ce qui est sûr, c'est que sqlservr 8.0 est linké avec IMAGE_FILE_LARGE_ADDRESS_AWARE dans son entête pour pouvoir utiliser au delà de 2GB sans avoir rien à faire de plus.

Sinon, autre chose, tu dis que ton windows est un advanced server, mais la ligne dans le boot.ini ne l'indique pas. Or l'utilisation du /3GB n'est pas possible à priori avec un windows 2000 de base cf http://www.microsoft.com/whdc/system...ae/paemem.mspx

La ligne de boot ne devrait pas plutôt être:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Advanced Server" /fastdetect /3GB

?

[zinzineti]

En fait j'avais configuré le serveur pour qu'il utilise toute la RAM dispo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
sp_configure 'max server memory'
-- Résultat : 
-- max server memory (MB)   4	2147483647	2147483647	2147483647

Du coup mon problème persiste .

Voilà en même temps le contenu du boot.ini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Server" /fastdetect /3GB

Cdlt.

Il ne faut pas laisser "max server memory" sur la valeur par défaut ( 2147483647). Il faut le modifier en indiquant une valeur valeur proche de 3 GB

Essaye et donne-nous le résultat

A+

[mikedavem]

Je confirme les propose de dbaffaleuf .. Une version Windows 2000 server ne vous permettra pas d'utiliser le commutateur /3GB. Il faut au minimum une version advanced server ..

++

[dbaffaleuf]

Pour vérifier si Windows a bien pris en compte le /3GB, j'ai une théorie.

1) Si tu as moyen de récupérer tlist dans un ressource kit ou le CD de support tools de windows 2000, sinon tu peux le trouver aussi ici.
2) Tu lances un notepad dans la VM
3) Sous le prompt DOS:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
DOS> tlist -p notepad
<doit te renvoyer le PID, admettons 3365>
DOS> tlist 3365 | findstr kernel32.dll
  5.1.2600.5512 shp  0x7C800000  C:\WINDOWS\system32\kernel32.dll
DOS> tlist 3365 | findstr ntdll.dll
  5.1.2600.5512 shp  0x7C910000  C:\WINDOWS\system32\ntdll.dll

kernel32.dll est une subsystem DLL, et ntdll.dll est un genre de traducteur entre les programmes et le noyau de windows. Elles sont référencées par la quasi totalité des programmes. Elles sont chargées en général assez près de la limite haute de l'espace d'adressage en user mode qui est 0x7fffffff (2gb - 1 octet). Par exemple, sur mon laptop en XP 32 bits, pas de /3GB, ntdll est chargée à 0x7C910000 et kernel32 à 0x7C800000.

Lorsque Windows boote en /3Gb, toute l'allocation est revue (ce n'est plus le cas en vista et +) et il charge le noyau, HAL et compagnie à partir de 0xC000000 (3GB). Les modules critiques comme kernel32.dll et ntdll.dll devraient normalement être relogés proche de 0xC000000, sur des adresses à la louche vers 0xBCnnnnnn. Mais je n'ai pas de machine configurable en /3GB, je ne peux donc pas mesurer.

Si tu as l'occasion de faire le test et de nous poster le résultat des tlist, ce serait sympa.

[SQLpro]

Bonjour,

Tout d'abord, merci pour vos réponses !!

@dbaffaleuf : pour l'histoire de l'écran bleu en fait il s'agissait plutôt d'une déduction (étant donné que c'est parfois comme cela que l'OS windows réagit en cas d'instabilité).

@zinzineti : merci pour le lien mais j'avais déjà fait un tour sur la page de SQLPro.

Pour vous répondre évidemment que l'ajout de RAM serait la solution la plus efficace avec l'utilisation de l'AWE mais en attendant que ces négociations d'achat de RAM aboutissent, j'ai néanmoins voulu faire un test.
J'ai copié la VM sur laquelle tourne ce serveur, rajouté le switch /3GB dans le boot.ini et redémarré la machine (windows). Après avoir lancé des requêtes gourmandes je n'ai pas pu atteindre les 2,7GB, le processus "sqlsrvr.exe" plafonne à 1,7GB. Y a-t-il autre chose à configurer pour obtenir les 2,7GB ?

Cdlt.

En version 2000 SQL Server n'est pas capable d'utiliser les 3 Go de RAM du switch 3GB. Il plafonnera donc vers les 2 Go. Cepandant cette réserve sera disponible pour les autres applications du serveur s'il en existe...

En revanche je vois que vous êtes en machine virtuelle. l'utilisation d'une VM nuit de façon catastrophique aux performances de SQL Server. SQL Server n'est pas conçu pour être virtualisé.
Commencez donc pas le commencement, car si vous voulez de bonnes perfmances, il faut commencer par dévirtualiser !
Lisez les articles que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...irtualisation/
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
http://blog.developpez.com/sqlpro/p5...fichiers-et-t/

A +

[dens19]

Bonjour,

Je reviens vers pour le fin mot de l'histoire. Le serveur sur lequel je travaille est bien un Windows server 2000 et non pas un Windows server 2000 advanced server.
Je me suis basé sur les informations du "Guest OS" de la console d'administration de la VM (qui a été créé en P2V donc censé remonté le bon OS) alors que comme l'a précisé dbaffaleuf il devrait y avoir ceci dans le fichier boot.ini si çà avait réellement était un advanced server:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Advanced Server" /fastdetect /3GB

Du coup je ne peux pas utiliser le switch /3GB. Désolé de vous avoir fait perdre votre temps sur ce post .

@SQLPro : Pour ce qui est de la virtualisation, j'ai déjà pris en compte les informations qui sont dans vos billets, pour proposer un solution de migration vers SQL SERVER 2008 sur un serveur non virtualisé .

Cdlt.