si cela peut aider, Resource Monitor décrit toutes les autres RAM comme "Veille"
La RAM "en veille" est en cours d'utilisation. Il est utilisé comme cache de pages (il contient les pages récemment perdues de tous les ensembles de travail de processus; c'est-à-dire que les erreurs de page peuvent être résolues sans aller sur le disque) et également pour le cache de fichiers proactif par SuperFetch.
Il est considéré comme "disponible" car les pages de secours n'ont pas besoin d'être écrites sur le disque avant de pouvoir être affectées à une autre utilisation. Tels que lorsqu'un processus frappe un défaut de page qui ne nécessite la lecture à partir du disque, nouvelle page physique (s) doivent être alloués à ce processus, et le cas échéant ceux - ci peuvent être pris dans la liste d' attente. (Ce n'est pas le premier choix pour trouver des pages à cet effet, ce serait la liste gratuite puis la page zéro.)
En d'autres termes, votre système fonctionne comme il se doit.
Vous pouvez forcer votre système à mettre plus de RAM dans l'état "en cours d'utilisation" facilement avec l'outil de ligne de commande testlimit
, l'un des outils utilisés dans les expériences dans Windows Internals . Il ne fait pas partie des outils sysinternals habituels mais y est associé; trouver ici sur le site Sysinternals. Le téléchargement est un fichier zip qui contient deux versions, testlimit.exe et testlimit64.exe. Les deux sont liés aux grandes adresses, la version 32 bits pourra donc allouer jusqu'à 3 Gio sur une machine 32 bits démarrée avec / 3 Go, jusqu'à 4 Gio sur une machine 64 bits.
c:\> testlimit -?
donne de l'aide.
c:\> testlimit -d 4 -c 512
tentera d'allouer 2 Gio d'espace d'adressage virtuel privé de processus dans 512 allocations de 4 Mio chacune. Cela devrait fonctionner correctement sur une machine 64 bits. Sur une machine 32 bits non démarrée avec / 3 Go (la plupart ne le sont pas), il peut y avoir une erreur un peu plus tôt b / c, il y a déjà quelques Mio de choses dans le processus (comme le programme lui-même, toutes les DLL, etc.), donc il n'y a pas tout à fait 2 Gio disponibles pour le programme à allouer.
Dans les deux cas, il y aura une réduction de la RAM «disponible» et une augmentation de la RAM «en cours d'utilisation», mais pas nécessairement 2 Gio car il n'y a aucune garantie que le système d'exploitation laissera les 2 Gio dans le jeu de travail privé du processus. Même si c'est le cas à court terme, vous pouvez voir l'ensemble de travail du processus diminuer plus tard, car le système d'exploitation décide "hm, vous ne faites rien avec, les autres processus en ont plus besoin" et les pages.
Augmentez trop la taille des «morceaux» d'allocation, en réduisant le nombre de morceaux en conséquence, et cela échouera probablement plus tôt car chaque allocation doit être virtuellement contiguë. Par exemple, essayez de trouver sept morceaux de 512 Mo dans un espace d'adressage de 4 Gio et vous échouerez probablement.
Si vous utilisez l'option l (eak) au lieu de d (irty), le programme allouera l'espace virtuel mais ne le référencera jamais. Cela n'entraînera pas de diminution appréciable de la RAM "disponible".
(L'option d (irty) tire son nom du "bit de page sale" dans l'entrée de table de page x86 / x64, qui est définie lorsque la page virtuelle correspondante est accessible avec un opérande de style "modifier", ce qui signifie que le contenu de la page a Ceci est une indication de Windows que, si la page doit être supprimée du jeu de processus, son contenu doit être enregistré quelque part avant que la page puisse être utilisée pour autre chose. Les pages avec le bit "sale" vont à la "liste des pages modifiées" immédiatement après l'expulsion; à partir de là, Windows les écrit dans leurs magasins de sauvegarde respectifs.)
Vous aurez besoin d'avoir suffisamment de "commit" disponible pour que ces tests fonctionnent comme décrit ci-dessus (même pour l'option l (eak), même si cette option n'utilise pas une quantité appréciable de RAM). Plus précisément, votre «limite de validation» doit être d'au moins 2 Gio (ou quelle que soit la quantité que vous allouez) supérieure à la «charge de validation» avant de commencer votre test. Notez que cela s'applique même si vous utilisez l'option l (eak), pas seulement d (irty). Si vous rencontrez cette limite, vous verrez les fenêtres contextuelles «le système manque de mémoire» ou similaires. Le remède, bien sûr, consiste à ajouter plus de RAM et / ou à augmenter les paramètres de votre fichier d'échange.