Réglage de 4 gigaoctets : BCDEdit et Boot.ini
Sur les éditions 32 bits de Windows, les applications disposent de 4 gigaoctets (Go) d’espace d’adressage virtuel disponible. L’espace d’adressage virtuel est divisé de sorte que 2 Go soient disponibles pour l’application et que les 2 Autres Go soient disponibles uniquement pour le système. La fonctionnalité de réglage de 4 gigaoctets (réglage ram de 4GT ou 4GT), activée avec la commande BCDEdit /set increaseuserva , augmente l’espace d’adressage virtuel disponible pour l’application jusqu’à 3 Go et réduit la quantité disponible pour le système à entre 1 et 2 Go.
Pour les applications gourmandes en mémoire, telles que les systèmes de gestion de base de données (SGBD), l’utilisation d’un espace d’adressage virtuel plus grand peut offrir des avantages considérables en matière de performances et d’extensibilité. Toutefois, le cache de fichiers, le pool paginé et le pool sans pagination sont plus petits, ce qui peut nuire aux applications avec une mise en réseau ou des E/S intensives. Par conséquent, vous pouvez tester votre application sous charge et examiner les compteurs de performances pour déterminer si votre application bénéficie de l’espace d’adressage plus grand.
Pour activer 4GT, utilisez la commande BCDEdit /set pour définir l’option d’entrée de démarrage increaseuserva sur une valeur comprise entre 2048 (2 Go) et 3072 (3 Go).
Windows Server 2003 et versions antérieures : Pour activer 4GT, ajoutez le commutateur /3 Go au fichier Boot.ini. Le commutateur /3Gb est pris en charge sur les systèmes suivants :
- Windows Server 2003
- Windows XP Professionnel
Le commutateur /3 Go met à la disposition des applications un espace d’adressage virtuel complet de 3 Go et réduit la quantité disponible pour le système à 1 Go. Sur Windows Server 2003, la quantité d’espace d’adressage disponible pour les applications peut être ajustée en définissant le commutateur /USERVA dans Boot.ini sur une valeur comprise entre 2048 et 3072, ce qui augmente la quantité d’espace d’adressage disponible pour le système. Cela peut aider à maintenir les performances globales du système lorsque l’application nécessite plus de 2 Go, mais moins de 3 Go d’espace d’adressage.
Pour permettre à une application d’utiliser l’espace d’adressage plus grand, définissez l’indicateur IMAGE_FILE_LARGE_ADDRESS_AWARE dans l’en-tête d’image. L’éditeur de liens inclus avec Microsoft Visual C++ prend en charge le commutateur /LARGEADDRESSAWARE pour définir cet indicateur. La définition de cet indicateur, puis l’exécution de l’application sur un système qui ne prend pas en charge 4GT ne doit pas affecter l’application.
Sur les éditions 64 bits de Windows, les applications 32 bits marquées avec l’indicateur IMAGE_FILE_LARGE_ADDRESS_AWARE disposent de 4 Go d’espace d’adressage disponible.
Éditions Itanium de Windows Server 2003 : Avant SP1, les processus 32 bits n’ont que 2 Go d’espace d’adressage disponible.
Suivez les instructions suivantes pour prendre en charge 4GT dans les applications :
- Les adresses proches de la limite de 2 Go sont généralement utilisées par diverses DLL système. Par conséquent, un processus 32 bits ne peut pas allouer plus de 2 Go de mémoire contiguë, même si l’espace d’adressage de 4 Go entier est disponible.
- Pour récupérer la quantité totale d’espace virtuel utilisateur, utilisez la fonction GlobalMemoryStatusEx . Pour récupérer l’adresse utilisateur la plus élevée possible, utilisez la fonction GetSystemInfo . Détectez toujours la valeur réelle au moment de l’exécution et évitez d’utiliser des définitions de constantes câblées en dur telles que :
#define HIGHEST_USER_ADDRESS 0xC0000000. - Évitez les comparaisons signées avec des pointeurs, car elles peuvent provoquer le blocage des applications sur un système 4GT. Une condition telle que la suivante est false pour un pointeur supérieur à 2 Go :
if (pointer > 40000000). - Le code qui utilise le bit le plus élevé d’un pointeur pour un objectif défini par l’application échoue lorsque 4GT est activé. Par exemple, un mot 32 bits peut être considéré comme une adresse en mode utilisateur s’il est inférieur à 0x80000000, et un code d’erreur s’il est ci-dessus. Cela n’est pas vrai avec 4GT.
VirtualAlloc retourne généralement les adresses faibles avant les adresses élevées. Par conséquent, votre processus peut ne pas utiliser d’adresses très élevées, sauf s’il alloue beaucoup de mémoire ou a un espace d’adressage virtuel fragmenté. Pour forcer les allocations à allouer à partir d’adresses plus élevées avant les adresses inférieures à des fins de test, spécifiez MEM_TOP_DOWN lors de l’appel de VirtualAlloc ou définissez la valeur de Registre suivante sur 0x100000 :
HKEY_LOCAL_MACHINE\Système\Currentcontrolset\Contrôle\Gestionnaire de sessions\Gestion de la\ mémoire AllocationPreference
Rubriques connexes