Processus Limite de mémoire du processus 64 bits

Question

J'ai actuellement une application .Net 32 ​​bits (sur Windows x86) qui nécessite beaucoup de mémoire. Récemment, il a commencé à lancer System.OutOfMemoryException. Donc, je prévois de le déplacer vers une plate-forme x64 en tant que processus 64 bits. Cela va donc aider avec les exceptions de mémoire insuffisante. Je lisais cet article de MSDN Memory limits for Windows

Alors, ma question est de savoir si je compile une application .Net 64 bits, ce qu'il y aura IMAGE_FILE_LARGE_ADDRESS_AWARE défini par défaut (comme l'article l'indique)? Est-ce que je serai en mesure de profiter de l'espace d'adressage virtuel en mode utilisateur de 8 Go?

Answer 1

La limite de mémoire maximale pour les processus x64 est de 8 To, mais la limite pratique est bien moindre car elle dépend de la quantité de mémoire physique et de la taille du fichier d'échange sur votre système. Voir this post pour plus de détails à ce sujet. Les IMAGE_FILE_LARGE_ADDRESS_AWARE affectent un processus x86 exécuté sur un système d'exploitation x64 (ou un système d'exploitation x86 avec la directive/3GB). Votre application x64 n'a pas besoin de définir l'indicateur de grande adresse et elle pourra utiliser toute la mémoire virtuelle disponible sur votre système.

Answer 2

En fait, cet article indique que vous aurez accès à 8 TB de l'espace d'adressage virtuel (et oui, cela est vrai).

Answer 3

En fait, sur un système d'exploitation x64 si votre application est compilée pour AnyCPU, vous n'avez rien de spécial à faire. Le JIT crée une image x64 au moment de l'exécution ou une image x86 lorsqu'elle est exécutée sur un système 32 bits.

Answer 4

IMAGE_FILE_LARGE_ADDRESS_AWARE est uniquement pertinent pour les processus 32 bits. La raison en est que l'espace d'adressage sur Windows 32 bits est divisé en deux: 2 Go pour l'espace noyau et 2 Go pour l'espace utilisateur. Pour répondre à 2 Go, vous avez besoin de 31 bits. C'est à dire. les pointeurs dans une application 32 bits n'ont pas besoin du dernier bit pour l'adressage.

Certaines applications peuvent avoir utilisé ce bit supplémentaire à des fins personnalisées, donc si le gestionnaire de mémoire Windows leur donne soudainement une véritable adresse 32 bits, ils ne peuvent pas gérer cela. En activant l'indicateur IMAGE_FILE_LARGE_ADDRESS_AWARE, l'application indique au système d'exploitation qu'elle peut gérer l'intégralité de l'espace adressable de 32 bits.

Si vous exécutez une application IMAGE_FILE_LARGE_ADDRESS_AWARE sur Windows 32 bits, vous pouvez accéder à 3 GB. Si vous exécutez la même application 32 bits sur Windows 64 bits, le processus récupère l'intégralité de l'espace d'adressage de 4 Go. Si vous exécutez une application 64 bits sous Windows 64 bits, l'espace d'adressage de l'utilisateur est de 8 To (avec 8 To supplémentaires réservés à l'espace d'adressage du noyau). Les applications .NET définies sur AnyCPU seront automatiquement des applications 64 bits sur x64, vous n'avez donc rien à faire pour traiter la mémoire supplémentaire. Gardez à l'esprit, cependant, que le CLR impose une limite de 2 Go sur un seul objet, alors même si votre application peut utiliser beaucoup de mémoire, vous ne pouvez pas créer une baie de 2 To par exemple. Plus d'informations sur cette question: Single objects still limited to 2 GB in size in CLR 4.0?

Answer 5

        Le passage à un 64 bits contribue certainement découper les OutOfMemoryExceptions, mais vous pouvez vous concentrer sur l'architecture de votre système et les mécanismes de codage pour éviter ces derniers comme il serait seulement une question de temps avant de faire surface sur la machine 64 bits.Un autre avantage du passage à des machines 64 bits est qu'avec un espace d'adressage virtuel de 8 To, la récupération de place pour .NET est peu fréquente. Cela améliore les performances des applications en augmentant l'espace virtuel disponible pour votre programme.