Y a-t-il des inconvénients du commutateur «/ 3Gb» dans boot.ini pour Windows 32 bits?

Microsoft conseille d'utiliser le commutateur / 3Gb dans Boot.ini afin d'obtenir plus de mémoire pour un processus s'exécutant sur un système 32 bits.

Actuellement, j'ai besoin de beaucoup de mémoire pour le processus devenv (Visual Studio 2008) car j'ai une solution complexe qui a beaucoup de projets et de formulaires et consomme beaucoup de ressources au moment de la conception.

Je voudrais demander, si quelqu'un le sait, quels sont les aspects négatifs de l'utilisation du commutateur / 3Gb, y a-t-il des circonstances où il n'est pas recommandé de l'utiliser.

Sur une machine de bureau, il n'y a probablement aucun problème. Le pool paginé du noyau est plus petit sur une machine W2K3 / WXP avec le jeu de commutateurs / 3GB. Ce n'est probablement pas un problème pour une machine de bureau car vous ne devriez pas vous approcher de l'épuisement de votre pool paginé du noyau. Sur un serveur, épuiser le pool paginé du noyau vous causera des problèmes, et il est beaucoup plus probable que vous puissiez l'épuiser.

Voici quelques bons détails sur les considérations de mémoire du noyau associées au commutateur / 3GB. Si vous le voulez vraiment, vous pouvez lancer le débogueur de noyau NT et profiler votre système avant et après la modification avec les informations dans ce document: http://blogs.technet.com/markrussinovich/archive/2009/03/26 /3211216.aspx

Vous aurez moins de mémoire disponible pour votre noyau - le commutateur ajuste la répartition de l'espace d'adressage en mode noyau / espace d'adressage en mode utilisateur, auparavant de 2 Go à 2 Go, de 1 Go à 3 Go. Lisez le post de Raymond Chen sur / 3GB, et les suivis, avant de continuer.

Avant d'apporter des modifications, vous devez d'abord vérifier si les processus que vous souhaitez exécuter sont liés à l'indicateur LARGEADDRESSAWARE. Avec l'indicateur, il n'y aura aucun changement à la façon dont le processus utilise la mémoire.

Vous pouvez utiliser les outils SDK pour cela:

dumpbin / headers exeName

Les en-têtes crachés doivent inclure:

L'application peut gérer de grandes adresses (> 2 Go)

J'ai fait la vérification sur devenv.exe et dans VS2008, il inclut le drapeau.

Beaucoup d'inconvénients. Par défaut, Windows alloue un pool de mémoire de 4 Go à chaque processus, qui est divisé 50/50 entre les processus en mode noyau (communs à toutes les applications) et les processus en mode utilisateur (uniques pour chaque application) (explication simplifiée). Une application exécutée sur le système dispose donc de 2 Go de mémoire pour jouer, tandis que le système lui-même a ses propres 2 Go. Remarque importante: ce deuxième 2 Go est le même 2 Go pour toutes les applications exécutées sur le système.

Le commutateur / 3GB ajuste la répartition de sorte que le mode noyau obtienne 1 Go et le mode utilisateur 3 Go.

Considérez maintenant les applications que vous exécutez. Certains d'entre eux nécessiteront plus d'espace en mode noyau, d'autres nécessiteront plus d'espace en mode utilisateur. Comme le pool en mode noyau est partagé, vous pouvez très rapidement manquer de mémoire si vous exécutez des applications qui mettent la mémoire en mode noyau sous pression. D'un autre côté, si vos applications utilisent beaucoup de mémoire en mode utilisateur, la mise en œuvre de / 3 Go leur donnera la marge dont elles ont besoin.

C'est donc vraiment dû à la nature des applications que vous souhaitez exécuter. La règle d'or est de consulter le fournisseur de l'application et de lire la documentation; en particulier, si le fournisseur de l'application n'a aucune recommandation, vous devriez commencer à vous méfier ... ont-ils correctement testé leur application ou non? Il s'agit de choses de base que chaque fournisseur doit connaître.

Il y a une assez bonne discussion à ce sujet ici: http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

Dans votre cas particulier, je pense que passer à 64 bits et obtenir plus de RAM sera une solution plus viable, car / 3 Go ne vous donnera pas vraiment ce que vous voulez (cela fonctionne-t-il même sous XP?)

Nous l'avons utilisé sur quelques systèmes qui exécutaient des applications de traitement d'image sur de nombreuses images de grande taille, et nous n'avons jamais remarqué de problème. Dans toutes les situations où vous avez besoin de plus de Gig de mémoire d'application, vous allez probablement laisser l'application s'exécuter et ne rien faire d'autre avec le système, donc il n'y aura probablement pas beaucoup d'impact.

Je l'ai vu interférer avec les cartes vidéo de façon étrange. Mais tout pilote peut mal se comporter avec ce commutateur s'il n'est pas écrit correctement.

Parfois, ces problèmes peuvent être contournés avec l'ajout du commutateur / USERVA.

http://support.microsoft.com/kb/319043
http://support.microsoft.com/kb/833721
http://support.microsoft.com/kb/839490
http://support.microsoft.com/kb / 316739

Il ne fonctionne de manière fiable (sauf pour le débogage des pilotes, etc.) sur un système d'exploitation de serveur d'entreprise pour les binaires LARGEADDRESSAWARE.

devenv n'est pas un tel binaire . SQL Server et Exchange le sont, par exemple.

Vous auriez besoin d'un système d'exploitation x64 bits et d'une édition VS x64 : LARGEADDRESSAWARE est détecté sur x64 pour dépasser la limite de 2 Go.