- Estimation de la mémoire réelle.
- Comment s’utilise la mémoire dans les environnements TS ?
- Détermination si vous avez assez de mémoire physique.
- Tracer l’usage de la CPU.
- Minimiser l’impact des applications sur la CPU.
- Hyperthreading avec un processeur Intel Xeon.
- Utilisation du disque
- Identification des goulots d’étranglement dans l’utilisation du disque.
- Outils de mesure du réseau.
- Identification des goulots d’étranglement du réseau.
- Implémentation de l’utilisation de la mémoire par le noyau dans Windows 2000.
- Evaluation des problèmes d’utilisation de la mémoire par le noyau 2003.
- Compréhension l’utilisation des switches dans le Boot.ini dans un environnement TS
- Utilisation de la base de registre.
Les indicateurs de performance
La mémoire
C’est le composant physique le plus important aussi bien pour la quantité que la qualité des services TS.
De nombreuses étapes sont à franchir pour ce faire :
Il faut comprendre comment TS utilise la mémoire
Savoir si vous avez la bonne quantité de mémoire pour le service souhaité.
Si le système ralentit avec le temps, il faut rechercher les fuites* de mémoire.
Définition : *http://en.wikipedia.org/wiki/Memory_leak
Estimation de la mémoire réelle
La quantité de mémoire requise par utilisateur dépend des applications et de l’OS du serveur. Le minimum requis pour l’OS dépend de sa version.
Pour des utilisateurs de plusieurs applications type bureautique :
15MB/utilisateur sur Windows2000 servers.
10MB /utilisateur sur Windows 2003 servers.
Pour les utilisateurs légers, il faut compter :
7MB pour Windows 2000
5MB pour Windows 2003.
Si votre Terminal Servers supporte des line-of-business applications client / server complexes, il faut facilement compter entre 20 et 30, voire 50MB/utilisateur.
Comment s’utilise la mémoire dans les environnements TS ?
Chaque utilisateur qui utilise une application sur un TS consomme la même quantité de mémoire que si l’application était sur station de travail. Pour un usage de 10 Mo, 20 utilisateurs auront besoin de 200 Mo. Ajouter à cela le minimum requis pour ouvrir la session qui est de 4 Mo, le volume final devient 280 Mo. Il faut ajouter à cela le requis pour l’OS : 128 Mo, 256Mo ou 500 Mo (selon la version).
Détermination du manque de mémoire physique
L’utilisation du Moniteur de Performance pour déterminer l’utilisation réelle de la mémoire n’a jamais été satisfaisante. Il vaut mieux regarder comment se comportent plusieurs compteurs ensemble quand le système présente une faiblesse. Ainsi, il devient aisé de dégager une tendance. Voici des compteurs à observer simultanément.
Process | Working Set | _Total
Memory | Pages Input/Sec
Memory | Pages Output/Sec
Memory | Available Bytes
Terminal Services | Active Sessions
Identifier les fuites de mémoire
La fuite de mémoire pénalise le système. Ce phénomène s’installe progressivement et prend de plus en plus de mémoire. Cela peut aller de quelques Ko à des Mo/ mn. Dans tous les cas, les fuites de mémoires sont dues à des problèmes avec des applications ou des pilotes, et peuvent, dans leur majorité, être traités à l’aide de patchs.
En monitorant les compteurs suivants :
Pool paginé Bytes (Memory | Pool Paged Bytes)
Page File Usage (Paging File | %Usage | Total)
On peut détecter les fuites de mémoire.
Si l’on remarque un accroissement simultané des deux courbes alors qu’on n’a pas augmenté le nombre d’utilisateurs, on peut conclure à une fuite de mémoire. C’est aussi le cas si l’on remarque un accroissement intermittent (toujours sans ajout d’utilisateurs)
Utilisation de la mémoire virtuelle
Certes, il est vrai que la mémoire virtuelle est un recours en cas de carence, mais elles aussi utilisée autrement.
Dans l’environnement Windows, chaque exécutable ou DLL est écrit en mémoire dès qu’il est utilisé. (Cela signifie que dès qu’il est chargé en mémoire la version change.) Ainsi, une DLL est chargée en mémoire et le système laisse plusieurs processus la partager. Cependant, dès qu’un processus tente d’écrie dans une portion de la DLL, le système en crée une copie rapide. (A travers la fonctionnalité de “copy-on-write”) and laisse le processus écrire dessus. En plus, le système sauvegarde cette copie dans la mémoire virtuelle. Cela signifie qu’il y a trois copies de la DLL : l’original, la copie pour l’autre processus et la sauvegarde en mémoire virtuelle. Le même phénomène intervient quand il s’agit d’application face à plusieurs utilisateurs.
Modification de la façon dont Windows utilise le page-file
Le marché offre des softs d’optimisation comme :
* http://www.rtosoft.com/Products/TScale/TScale.htm
Rendre la mémoire virtuelle plus rapide
Voici quelques mesures à mettre en œuvre :
*Mettre la mémoire virtuelle sur son propre disque et son propre canal scsi
*S’assurer qu’elle est sur une partition FAT (plus rapide que la NTFS)
*Mettre en place des SSD. Ils utilisent la mémoire flash
* Recourir, avant tout, à une optimisation avec des softs comme : TScale* ou Expedian**.
(Voir ci-haut pour ces utilitaires.)
Dimensionnement de l’utilisation de ma mémoire virtuelle
Le dernier aspect qui peut avoir un impact sur le nombre d’utilisateur que le serveur peut supporter est la taille du fichier d’échange. Si celui-ci manque d’espace, il devient impossible d’ajouter des utilisateurs. La recommandation officielle est 1.5 fois la RAM. Cependant, rien ne vous oblige à respecter cela. Pour déterminer la taille du fichier d’échange, il faut tenir compte du type et nombre d’applications. Il faut également considérer la quantité totale de la mémoire système (noyau). Si vous avez un serveur doté de 512 MB, 1.5 fois la RAM suffit. Mais, Avec Une RAM de 8 GB, un petit fichier suffit largement : adoptez 4 GB et augmentez-le s’il y a besoin.
On peut vérifier le pourcentage d’utilisation de la mémoire virtuelle à l’aide du compteur suivant dans le moniteur de performance :
Paging File | % Usage | _Total
32 Utilisation de la CPU
Comprendre comment TS utilise la CPU.
Prendre des mesures pour minimiser l’impact que peuvent avoir les applications sur la CPU
Si vous utilisez Itel Xeon, comprendre comment active ou désactiver l’hyperthreading peut affecter les performances.
Tracer l’usage de la CPU
A l’aide du Moniteur des Performances et des compteurs ci-dessous :
Processor | % Processor Time | _Total
System | Processor Queue Length
Minimiser l’impact des applications sur le CPU
Le but de cette action est d’identifier les applications consommatrices de CPU et les éliminer. Désactiver la vérification de la Grammaire dans Microsoft Word 2000’s permet de doubler le nombre d’utilisateur. D’autres actions comme le paramétrage des couleurs de l’écran ou la personnalisation des navigateurs Web peuvent contribuer à libérer des ressources CPU.
Hyperthreading avec le processeur Intel Xeon
L’hyperthreading est fonctionnalité activable au niveau du bios. Elle permet à la CPU Intel Xeon d’utiliser deux pipies pour accélérer le traitement. Cette fonctionnalité cause le ralentissement du système sous Windows Server 2000. Par contre, elle boost Windows Server 2003 de 10 à 20%.
Utilisation du disque
Pour savoir si vos disques durs ralentissent vos serveurs, tracez à l’aide du Moniteur de Performances les compteurs suivants :
Physical Disk | % Disk Time
Physical Disk | Current Disk Queue Length
331 Identification des goulots d’étranglement dans l’utilisation du disque
Changer de disques
Changer d’architecture
Changer la configuration du Cache du Raid (à l’aide d’un soft) permet de doubler le nombre d’utilisateur
Mettre l’OS sur un disque et la mémoire virtuelle sur un autre. (Cela suppose une destruction du mirroring)
Utilisation du Réseau
Outils de mesure
A l’aide des compteurs suivants et du monteur des performances, on peut avoir les premières informations :
Network Interface | Bytes Total/sec | Select your card
Network Interface | Output Queue Length | Select you card
Identification des goulots d’étranglement du réseau
Globalement, revoir l’architecture réseau.
Mettre des interfaces réseau plus rapides et/ou mettre en full duplex pour doubler l’interface du serveur.
Doter le serveur de deux cartes réseau. Ceci permet aux utilisateurs de ICA ou RDP de passer par une interface alors le reste des données transite par l’autre.
Utilisation de la mémoire par le noyau
Quand malgré la disponibilité de toutes les ressources matérielles votre système atteint ses limites. Il reste à comprendre comment le noyau utilise la mémoire.
Comprendre comment le noyau utilise la mémoire
L’appellation 32-bit signifie que Windows peut adresser au maximum 2^32 (4 GB) de mémoire.
Ces 4 GB sont répartis en 2 GB pour mode utilisateur et 2 GB pour mode Noyau. Ce niveau-
limite est indépendant de la mémoire physique installée. IL est la limite de la mémoire virtuelle.
Sur des TS particulièrement occupés, certaines composantes tournant sur l’espace d’adresse noyau peuvent manquer de ressources, empêchant des utilisateurs d’ouvrir une session. Ceci survient dans des milieux qui ont fait le plein des ressources physiques. La réaffectation de la mémoire au profit d’une composante se fait au détriment d’une autre. Les trois blocs se partagent ces 2 GB : PTEs, the Pool paginé, the System File Cache
Évaluation des problèmes d’utilisation de Mémoire par le noyau sous Windows 2000 TS
Pour vérifier la l’utilisation de la mémoire par noyau, il faut lancer les compteurs suivant sous le Moniteur des performances :
Memory | Free System Page Table Entries
Memory | Pool paginé Bytes
Cache | Copy Read Hits %
Implémentation de l’utilisation de la mémoire par le noyau dans Windows 2000
Le system PTE :
*HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\SystemPages
La valeur permet de contrôler le nombre de system PTEs que Windows crée au moment du boot
Le pool paginé :
*HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management\PagedPoolSize
Cette valeur spécifie la taille du pool paginé
*HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management\PagedPoolMax
La valeur du PagedPoolMax spécifie le pourcentage maximum du paged_pool que l’on désire avant que le système commence à dérober la mémoire du system file cache
Evaluation des problèmes d’utilisation de la mémoire par le noyau windows 2003
Les conclusions relatives à Windows 2000 s’appliquent à Windows 2003. Cependant, ce dernier apporte des améliorations quant à la gestion de la mémoire.
1- Le nombre de System PTE dans win2003 a doublé par rapport à win 2000: soit 1.3 GB.
2- Ces améliorations amènent moins de recours aux pools paginés.
Si vous soupçonnez un manqué de PTE ou de Pool paginé, utilisez un debugger de noyau. Téléchargez les outils : http://msdn.microsoft.com/en-us/library/cc267445.aspx
Installez-les sur le Terminal Server. Choisissez les options par défaut. Démarrez le Windows Debugger (Start | All
Programs | Debugging Tools for Windows | WinDbg).
Puis, vous aurez besoins d’établir une session de débogage du noyau sur l’ordinateur local.
1. Choose File | Kernel Debug…
2. Click the “Local” tab.
3. Click “OK.”
Vous devez savoir où se trouve le fichier symbol (extension SDB).
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d
Ex : Debugging Tools for Windows
Enabling RPC State Information
Two different levels of RPC run-time state information can be gathered: Server information and Full information. This information gathering must be enabled before the debugger or DbgRpc can be used to analyze state information.
Only Windows XP and later versions of Windows support the gathering of RPC state information.
Gathering Server state information is very lightweight. It costs about 100 machine instructions per RPC call, resulting in no detectable load, even during performance tests. However, gathering this information does use memory (about 4KB per RPC server), so it is not recommended on a machine that is already experiencing memory pressure. Server information includes data about endpoints, threads, connection objects, and Server Call (SCALL) objects. This is sufficient to debug most RPC problems.
Gathering Full state information is more heavyweight. It includes all the information gathered at the Server level and, in addition, includes Client Call (CCALL) objects. Full state information is usually not needed.
To enable state information to be gathered on an individual machine, run the Group Policy Editor (Gpedit.msc). Under the Local Computer Policy, navigate to Computer Configuration/Administrative Templates/System/Remote Procedure Call. Under this node you will see the RPC Troubleshooting State Information item. When you edit its properties, you will see five possible states:
None
No state information will be maintained. Unless your machine is experiencing memory pressure, this is not recommended.
Server
Server state information will be gathered. This is the recommended setting on a single computer.
Full
Full state information will be gathered.
Auto1
On a computer with less than 64 MB of RAM, this is the same as None. On a computer with at least 64 MB of RAM, this is the same as Server.
Auto2
On a computer running Windows Server 2003 with less than 128 MB of RAM, or on any Windows XP computer, this is the same as None. On a Windows Server 2003 computer with at least 128 MB RAM, this is the same as Server. This is the default.
If you want to simultaneously set these levels on a set of networked computers, use the Group Policy Editor to roll out a machine policy to the preferred set of machines. The policy engine will take care that the settings you want are propagated to the preferred set of machines. The Auto1 and Auto2 levels are especially useful in this case, because the operating system and amount of RAM on each computer may vary.
If the network includes computers running versions of Windows that are earlier than Windows XP, the settings will be ignored on those machines.
1 Comment disposer des « symbol files » :
A l’heure de la rédaction, il ya deux voies:
· Les télécharger vers votre disque (ou les copier du CD Windows Server 2003). Puis, configurer le Debugger qui va s’en servir
· Vous pouvez utiliser les nouveaux “Symbol Server,” de Microsoft qui permettent au Debugger de télécharger automatiquent et dynamiquent les « symbol server » requis du site
2 Comment utiliser « les symbol files » :
Configuring your Windows Debugger to use Microsoft’s symbol server is easy:
1. Choose File | Symbol Path File in the Debugger.
2. Enter the following statement into the box: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols (“c:\websymbols” can be changed to an appropriate local storage path for your environment.)
3. Check the “Reload” box.
4. Click “OK.”
Connectez les utilisateurs. Quand le système commence à ralentir, entrez dans la boîte “lkd>” en bas de l’écran du debugger, la commande suivante :
!vm 1
Ceci produira un snapshot de l’utilisation de la mémoire (2GB). Ceci ressemblerait à ce qui suit :
lkd> !vm 1
*** Virtual Memory Usage ***
Physical Memory: 130908 ( 523632 Kb)
Page File: \??\C:\pagefile.sys
Current: 786432Kb Free Space: 767788Kb
Minimum: 786432Kb Maximum: 1572864Kb
Available Pages: 45979 ( 183916 Kb)
ResAvail Pages: 93692 ( 374768 Kb)
Locked IO Pages: 95 ( 380 Kb)
Free System PTEs: 245121 ( 980484 Kb)
Free NP PTEs: 28495 ( 113980 Kb)
Free Special NP: 0 ( 0 Kb)
Modified Pages: 135 ( 540 Kb)
Modified PF Pages: 134 ( 536 Kb)
NonPagedPool Usage: 2309 ( 9236 Kb)
NonPagedPool Max: 32768 ( 131072 Kb)
PagedPool 0 Usage: 4172 ( 16688 Kb)
PagedPool 1 Usage: 1663 ( 6652 Kb)
PagedPool 2 Usage: 1609 ( 6436 Kb)
PagedPool Usage: 7444 ( 29776 Kb)
PagedPool Maximum: 43008 ( 172032 Kb)
Shared Commit: 1150 ( 4600 Kb)
Special Pool: 0 ( 0 Kb)
Shared Process: 2939 ( 11756 Kb)
PagedPool Commit: 7444 ( 29776 Kb)
Driver Commit: 2219 ( 8876 Kb)
Committed pages: 63588 ( 254352 Kb)
Commit limit: 320147 ( 1280588 Kb)
Les informations les plus importantes sont relatives aux :
· Free System PTEs
· PagedPool Usage
· PagedPool Maximum
Si vos PTEs sont vraiment bas, alors vous devez l’augmenter. Si l’utilisation votre Pool paginé est au plus au pool paginé maximum, alors il faut l’augmenter. Si aucune de ces deux situations ne se présente, réduisez le nombre d’utilisateurs et relancer la commande « vm1 » du debugger.
Pour augmenter les PTE, il faut modifier la valeur du SystemPages à FFFFFFFF (Hex), rebouter le serveur et relancer le test. Cette opération ne change plus grand-chose depuis que Windows 2003 a maximisé le nombre de PTE.
Si la part du Pool paginé est petite par rapport pool paginé maximum, alors vous aimeriez augmenter la taille maximale. Vous ne pouvez faire cela que si vous avez beaucoup de PTE disponible (environ au moins 3000)
Chaque PTE est de 4 KB. Pour chaque PTE que vous vous permettez de perdre, vous pouvez ajouter 4 KB à la taille de votre Pool paginé. Pour 10000 system PTE libre vous consentez à perdre 7000, pour 14000 vous consentez 11000, (en gardant 3000)
Prenez un nombre de PTE que vous consentez à perdre et multipliez-le par 4. Ajoutez ce chiffre à votre Pool paginé maximum. Ouvrez le registre et ajouter cette valeur (en multipliant par 1024) :
HKLM\System\CurrentControlSet\Control\Session Manager\Memory
Management\PagedPoolSize
Le registre va convertir cette valeur en Hexa
A ce stade, reboutez le système pour constater les changements.
Compréhension l’utilisation des switches dans le Boot.ini dans un environnement TS
Il y a deux switches: /3GB and /PAE.
Le Switch /3GB
Windows base 32-bit peut adresser 4GB de mémoire, et cette mémoire est divisée en 2 parts de 2 GB chacune, une pour le noyau et l’autre pour chaque process. L’ajout du switch “/3GB” à une entrée du boot.ini, modifie la manière dont le serveur alloue l’espace des 4GB. Au lieu de deux sections 2GB, en utilisant le commutateur “/3GB” , le noyau prend 1GB et chaque process prend 3GB.
Ceci est utile pour les applications gourmandes en mémoire comme Ms Exchange ou SQL Server. Terminal Servers a assez de problème avec le noyau en raison de la limitation par défaut à 2 G et vous pouvez imaginer le désastre si cette limite était à 1 GBt. (Par ailleurs, et pour utiliser les 3GB, une application doit être compilée d’une certaine façon. Si votre TS boot via un boot.ini avec une entrée switchée /3GB, il faut retirer celle-ci immédiatement.
Le Switch /PAE
Le commutateur “Physical Address Extensions” (PAE) dans le boot.ini est utilise quand Terminal Server a plus de 4GB de RAM. Sachant que le 32-bit Windows ne peut adresser que 4GB de la mémoire virtuelle, les systèmes dotés de plus de 4GB doivent recourir à des ruses pour utiliser la mémoire physique au delà des 4GB. Cette ruse est activé par l’ajout du commutateur « /PAE » à une entrée dans le boot.ini. (Pour utiliser plus de 4 GB de RAM, utiliser Windows 2000 Advanced Server ou supérieur ou Windows 2003 Enterprise Edition ou supérieur.)
Procédure (exemple) :
Pour activer une extension d’adresse physique (PAE) X86
1. Localisez le fichier Boot.ini, situé généralement dans le dossier racine (par exemple, C et supprimez son attribut lecture seule.
2. Ouvrez le fichier Boot.ini, et ajoutez le paramètre /PAE au chemin d’accès ARC, comme indiqué en gras dans l’exemple suivant :
multi(0)disk(0)rdisk(0)partition(2)\WINNT= »Windows 2000 Advanced Server » /PAE /basevideo /sos
3. Dans le menu Fichier, cliquez sur Enregistrer.
4. Restaurez l’attribut lecture seule au fichier Boot.ini.
Pour activer /3GB
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT= »???? » /3GB
Utilisation de la base de registre
L’espace de la base de registre détermine, lui aussi, le nombre d’utilisateurs. Le registre doit créer une ruche HKU pour chaque utilisateur. Le compteur suivant du Moniteur des performances renseigne sur cela en donnant le pourcentage maximum utilisé.
System | % Registry Quota in Use
Si cette valeur est proche du maximum, il faut pour ajouter des utilisateurs configure la taille du registre.
Les conséquences potentielles : sur Windows 2000 TS, tous les fichiers du registre sont stockés dans le pool paginé du noyau. C’est un problème pour deus raisons :
Le registre a une taille maximum de 160 MB
Augmenter sa taille réduit le nombre des pools paginés disponibles pour d’autres process du noyau en transformant le pool paginé en goulot d’étranglement.
Si vous voulez ajuster la taille du registre sur Windows 2000, vous pouvez le faire ainsi :
Control Panel. (Control Panel | System | Advanced Tab | “Performance Options” Button
| “Change…” Button | “Maximum Registry Size” box)
Si TS tourne sur Windows 2003, il n’ ya pas de soucis. Windows 2003 ne stocke pas le registre dans le pool paginé. Ce qui signifie que sa taille n’a pas de limite et qu’il n’a pas de paramétrage de sa taille. Il consommé 4MB du pool paginé indépendamment de sa taille effective.