Ces informations système proviennent de Process Explorer. Il y a encore de la mémoire physique disponible mais le système n'affiche presque plus de RAM.

Le Gestionnaire des tâches montre également qu'environ 74% de la RAM totale est utilisée.

Depuis l'installation de Windows 8.1, l'ordinateur avait 4 + 8 = 12 Go de RAM. Je l'ai mis à niveau en changeant les 4 Go en un module de 8 Go. Est-ce que cela pourrait être le problème? Ou ce comportement est-il normal et je viens de mal comprendre le sens de la mémoire physique disponible?

Réponse courte

La fenêtre contextuelle "Mémoire insuffisante" indique que vous n'avez plus de limite sur la mémoire privée validée - un type de mémoire virtuelle. Non pas que vous manquiez de RAM (mémoire physique). Peu importe la quantité de RAM disponible dont vous disposez. Avoir beaucoup de RAM disponible ne vous permet pas de dépasser la limite de validation. La limite de validation est la somme de votre RAM totale (qu'elle soit utilisée ou non!) Plus la taille actuelle du fichier d'échange.

Inversement, ce qui "utilise" la limite de validation (qui est principalement la création d'un espace d'adressage virtuel privé de processus) n'utilise pas nécessairement de RAM! Mais le système d'exploitation ne permettra pas sa création à moins qu'il ne sache qu'il y a un endroit pour le stocker s'il en a besoin. Ainsi, vous pouvez exécuter la limite de validation sans utiliser toute votre RAM, ni même la majeure partie de votre RAM.

C'est pourquoi vous ne devez pas exécuter sans fichier d'échange. Notez que le fichier d'échange pourrait ne jamais être écrit! Mais cela vous permettra toujours d'éviter les erreurs de «mémoire insuffisante» et «de mémoire insuffisante».

Réponse intermédiaire

Windows n'a pas réellement de message d'erreur pour manquer de RAM. Ce qui vous manque, c'est la "limite de validation".

Le graphique "Système" dans cette version de Process Explorer est mal nommé. Il devrait être étiqueté «engager la charge». (Dans la version que j'ai, elle s'appelle "System commit". Mieux, mais toujours pas complètement cohérente.) Dans tous les cas, la hauteur "actuelle" du graphique est ce qui apparaît plus bas dans la section de texte comme "Commit Charge" - " Current ", et la hauteur maximale du graphique représente" Commit Charge "-" Limit ".

"Commit charge" se réfère à l'espace d'adressage virtuel qui est soutenu par le fichier d'échange (si vous en avez un) - en d'autres termes, s'il ne peut pas tout tenir dans la RAM, le reste va dans le fichier d'échange. (Il existe d'autres types de vas qui sont soit soutenus par d'autres fichiers - c'est ce que l'on appelle un vas "mappé" - soit qui doivent rester en RAM tout le temps; ce dernier est appelé "non paginable".) La "limite de validation" est le maximum qui la «charge de validation» peut être. Il est égal à la taille de votre RAM plus la taille du fichier d'échange.

Vous n'avez apparemment aucun fichier d'échange (je peux le dire parce que votre limite de validation est égale à la taille de votre RAM), donc la limite de validation est simplement la taille de la RAM.

Apparemment, divers programmes + le système d'exploitation ont utilisé presque tout le maximum de commit possible.

Cela n'a rien à voir directement avec la quantité de RAM disponible ou disponible. Oui, vous disposez d'environ 4,5 Go de RAM. Cela ne signifie pas que vous pouvez dépasser la limite de validation. La mémoire engagée n'utilise pas nécessairement la RAM et n'est pas limitée par la quantité de RAM disponible.

Vous devez soit réactiver le fichier d'échange - en utilisant ce fichier très engagé, je suggérerais un fichier d'échange de 16 Go, car vous ne voulez pas forcer le système d'exploitation à conserver autant de choses en RAM, et le fichier d'échange fonctionne mieux s'il a beaucoup d'espace libre - ou bien ajoutez plus de RAM. Beaucoup plus. Pour de bonnes performances, vous devez avoir beaucoup de place dans la RAM pour le code et d'autres éléments qui ne sont pas sauvegardés par le fichier d'échange (mais qui peuvent être paginés vers d'autres fichiers).

Réponse très longue

(mais toujours beaucoup plus court que le chapitre sur la gestion de la mémoire de Windows Internals ...)

Supposons qu'un programme alloue 100 Mo de mémoire virtuelle privée au processus. Cela se fait avec un appel VirtualAlloc avec l'option "commit". Il en résultera une augmentation de 100 Mo de la «charge de validation». Mais cette "allocation" n'utilise en fait aucune RAM! La RAM n'est utilisée que lorsque certains de cet espace d'adressage virtuel nouvellement engagé sont accédés pour la première fois.

Comment la RAM finit par être utilisée

(si c'est le cas)

Le premier accès à l'espace nouvellement engagé serait presque toujours une écriture en mémoire (lire un canal privé nouvellement alloué avant l'écriture est presque toujours une erreur de programmation, car son contenu initial est, à proprement parler, indéfini). Mais lire ou écrire, le résultat, la première fois que vous touchez une page de vas nouvellement allouée, est un défaut de page . Bien que le mot «faute» sonne mal, les défauts de page sont un événement complètement attendu et même requis dans un système d'exploitation à mémoire virtuelle.

En réponse à ce type particulier de défaut de page, le pager (qui fait partie du gestionnaire de mémoire du système d'exploitation, que je vais parfois abréger en "Mm"):

1. allouer une page physique de RAM (idéalement à partir de la liste des pages nulles, mais dans tous les cas, elle provient de ce que Windows appelle «disponible»: la liste des pages zéro, libre ou en attente, dans cet ordre de préférence);
2. remplissez une entrée de table de pages pour associer la page physique à la page virtuelle; et enfin
3. ignorer l'exception de faute de page.

Après quoi, le code qui a fait la référence mémoire réexécutera l'instruction qui a provoqué l'erreur de page, et cette fois la référence réussira.

Nous disons que la page a été "mise en défaut" dans le jeu de processus et dans la RAM. Dans le Gestionnaire des tâches, cela apparaîtra comme une augmentation d'une page (4 Ko) dans le «jeu de travail privé» du processus. Et une réduction d'une page de la mémoire physique disponible. (Ce dernier peut être difficile à remarquer sur une machine occupée.)

Remarque 1: cette erreur de page n'impliquait rien de lu sur le disque. Une page de mémoire virtuelle validée jamais consultée ne démarre pas sur le disque; il doit le lire pas de place sur le disque à partir . Il est simplement "matérialisé" dans une page de RAM précédemment disponible. Statistiquement, en fait, la plupart des erreurs de page sont résolues en RAM, soit sur les pages partagées qui sont déjà en RAM pour d'autres processus, soit sur les caches de pages - les listes de réserve ou modifiées, ou sous forme de pages "zéro demande" comme celle-ci.

Remarque 2: Cela ne prend qu'une seule page, 4096 octets, de "Disponible". L'espace d'adressage engagé jamais touché auparavant est normalement réalisé - défectueux - une seule page à la fois, car chaque page est «touchée» pour la première fois. Il n'y aurait aucune amélioration, aucun avantage à en faire plus à la fois; cela prendrait n fois plus de temps. En revanche, lorsque les pages doivent être lues à partir du disque, une certaine "lecture anticipée" est tentée car la grande majorité du temps dans une lecture sur disque est en surcharge par opération, pas le transfert de données réel. Le montant «engagé» reste à 100 Mo; le fait qu'une ou des pages aient été défectueuses ne réduit pas les frais de validation.

Note 3:Supposons que nous ayons 4 Go de RAM "disponible". Cela signifie que nous pourrions référencer la mémoire engagée déjà allouée mais jamais référencée environ un million de fois (4 Go / 4096) avant de manquer de RAM. À ce stade, si nous avons un fichier d'échange comme le souhaitaient David Cutler et Lou Perazzoli, certaines des pages référencées en RAM les plus anciennes seraient enregistrées sur le disque, puis rendues disponibles pour être utilisées pour résoudre ces erreurs de page les plus récentes. (En fait, le système d'exploitation lancerait des méthodes de récupération de la RAM comme "le découpage du jeu de travail" plutôt avant cela, et les écritures réelles dans le fichier d'échange sont mises en cache et regroupées sur la liste des pages modifiée pour plus d'efficacité, et ...) Rien de tout cela n'affecterait le compte "engagé". Elle concerne cependant la «limite de validation». S'il n'y a pas de place pour tous "

Et ça continue de se produire ...

Mais supposons que nous n'ayons pas fait ces millions de références supplémentaires et qu'il reste environ 4 Go de pages "disponibles". Supposons maintenant que le même processus - ou un autre, peu importe - fasse un autre VirtualAlloc, cette fois de 200 Mo engagés. Encore une fois, ces 200 Mo s'ajoutent à la charge de validation, et cela ne supprime aucune mémoire RAM disponible. Simplement, l'espace d'adressage VirtualAlloc'up n'utilise pas une quantité correspondante de RAM, et avoir une faible RAM "disponible" ne limite pas la quantité d'espace d'adressage que vous pouvez VirtualAlloc (ni avoir une RAM disponible élevée ne l'augmente).

(Eh bien, ok ... il y a un tout petit peu de surcharge, ce qui équivaut à une page (paginable!) Qui est utilisée pour un tableau de pages pour 2 Mo (4 Mo si vous êtes sur un système x86, non-PAE) de espace d'adressage virtuel alloué, et il existe un "descripteur d'adresse virtuelle" de quelques dizaines d'octets pour chaque plage allouée virtuellement contiguë.)

De cette façon, c'est possible - et commun! - utiliser beaucoup de «charge de validation» tout en n'utilisant que de petites quantités de RAM.

Donc, si "valider" l'espace d'adressage virtuel n'utilise pas de RAM, pourquoi doit-il y avoir une limite?

Parce que la «charge de validation» représente une utilisation future potentielle de l'espace de stockage. La «limite de validation» représente la quantité totale de stockage (RAM + espace du fichier d'échange) disponible pour contenir de telles allocations, si jamais elles étaient effectivement référencées et devaient être stockées quelque part.

Lorsque le Mm approuve une demande VirtualAlloc, il est prometteur - "prendre un engagement" - que tous les accès mémoire ultérieurs à la zone allouée réussiront; ils peuvent entraîner des défauts de page, mais les défauts pourront tous être résolus, car il y a un stockage adéquat pour conserver le contenu de toutes ces pages, que ce soit en RAM ou dans le fichier d'échange. Le Mm le sait car il sait combien d'espace de stockage il y a (la limite de validation) et combien a déjà été «validé» (la charge de validation actuelle).

(Mais toutes ces pages n'ont pas encore nécessairement été consultées, il n'y a donc pas nécessairement de stockage réel pour aller avec le montant engagé, à un moment donné.)

Alors ... Qu'en est-il du "système est en mémoire"?

Si vous essayez de VirtualAlloc et que les frais de validation actuels plus la taille d'allocation demandée vous feraient dépasser la limite de validation, ET le système d'exploitation ne peut pas étendre le fichier d'échange afin d'augmenter la limite de validation ... vous obtenez le pop-up "out of memory" et le processus voit l'appel VirtualAlloc FAIL. La plupart des programmes lèveront leurs mains et mourront à ce moment-là. Certains continueront d'avancer aveuglément, en supposant que l'appel a réussi, et échoueront plus tard lorsqu'ils essaieront de référencer la région qu'ils pensaient avoir allouée.

Encore une fois (désolé pour la répétition): peu importe la quantité de RAM disponible dont vous disposez. Le système d' exploitation a promis que la RAM ou de l' espace de fichier d' échange sera disponible quand il est nécessaire, mais cette promesse ne soustrait pas de « disponible ». La RAM disponible n'est utilisée par vm engagé que lorsqu'il est référencé pour la première fois, ce qui provoque son "défaut" ... c'est-à-dire qu'il est réalisé dans la mémoire physique. Et la simple validation (= allocation) de la mémoire virtuelle ne fait pas cela. Il ne prend que de l'espace d'adressage virtuel gratuit et en fait un espace d'adressage virtuel utilisable.

Mais dans le cas de "mémoire insuffisante", il y a eu une demande d'allocation de mémoire validée, et le système d'exploitation a ajouté la charge de validation actuelle à la taille de cette nouvelle demande ... et a constaté que le total était supérieur à la limite de validation. Donc, si le système d'exploitation approuvait ce nouveau, et tout cet espace était référencé après cela, il n'y aurait pas de vrais endroits (RAM + fichier d'échange) pour tout stocker.

L'OS ne le permettra pas. Il ne permettra pas d'allouer plus de vas qu'il n'a d'espace pour le garder dans le pire des cas - même si tout est "en panne". C'est le but de la "limite de validation".

Je vous dis trois fois Je vous dis trois fois Je vous dis trois fois: La quantité de RAM "disponible" n'a pas d'importance. Que l'espace virtuel engagé n'utilise pas encore tout cet espace de stockage, cela n'a pas d'importance. Windows ne peut pas «valider» l'allocation virtuelle à moins qu'il ne puisse «être» défectueux à l'avenir.

Notez qu'il existe un autre type de canal appelé "mappé", principalement utilisé pour le code et pour l'accès aux gros fichiers de données, mais il n'est pas facturé pour "valider la charge" et n'est pas limité par la "limite de validation". En effet, il est livré avec sa propre zone de stockage, les fichiers qui y sont "mappés". La seule limite sur le canal "mappé" est la quantité d'espace disque dont vous disposez pour les fichiers mappés et la quantité de canal libre dans votre processus pour les mapper.

Mais quand je regarde le système, je ne suis pas encore tout à fait à la limite de validation?

C'est essentiellement un problème de mesure et de tenue de dossiers. Vous examinez le système après qu'un appel VirtualAlloc a déjà été essayé et échoué.

Supposons qu'il ne vous reste que 500 Mo de limite de validation et qu'un programme ait essayé de VirtualAlloc 600 Mo. La tentative échoue. Ensuite, vous regardez le système et dites "Quoi? Il reste encore 500 Mo!" En fait, il pourrait y en avoir beaucoup plus à ce moment-là, car le processus en question a probablement complètement disparu à ce stade, de sorte que TOUTE sa mémoire validée précédemment allouée a été libérée.

Le problème est que vous ne pouvez pas regarder en arrière dans le temps et voir ce que l'engagement de charge était au moment de la tentative de alloc a été faite. Et vous ne savez pas non plus combien d'espace était destiné à cette tentative. Vous ne pouvez donc pas voir définitivement pourquoi la tentative a échoué, ou combien plus de "limite de validation" aurait été nécessaire pour lui permettre de fonctionner.

J'ai vu "le système manque de mémoire". Qu'est-ce que c'est?

Si dans le cas ci-dessus, le système d'exploitation peut étendre le fichier d'échange (c'est-à-dire que vous le laissez au paramètre par défaut "géré par le système", ou vous le gérez mais vous définissez le maximum sur plus grand que le fichier initial, ET il y a suffisamment d'espace disque libre), et une telle expansion augmente suffisamment la limite de validation pour permettre à l'appel VirtualAlloc de réussir, puis ... le Mm étend le fichier d'échange et l'appel VirtualAlloc réussit.

Et c'est là que vous voyez "le système fonctionne FAIBLE en mémoire". C'est un avertissement précoce que si les choses continuent sans atténuation, vous verrez probablement bientôt un avertissement de «mémoire insuffisante». Il est temps de fermer certaines applications. Je commencerais par les fenêtres de votre navigateur.

Et vous pensez que c'est une bonne chose? L'expansion du fichier d'échange est mal !!!

Non, ça ne l'est pas. Vous voyez, le système d'exploitation ne «développe» pas vraiment le fichier existant. Il alloue simplement une nouvelle étendue. L'effet ressemble beaucoup à tout autre fichier non contigu. L'ancien contenu du fichier d'échange reste là où il se trouve; ils ne doivent pas être copiés vers un nouvel endroit ou quelque chose comme ça. Étant donné que la plupart des E / S du fichier d'échange sont en morceaux relativement petits par rapport à la taille du fichier d'échange, les chances qu'un transfert donné franchisse une limite d'étendue sont vraiment assez rares, de sorte que la fragmentation ne nuit pas beaucoup à moins qu'elle ne soit vraiment excessive.

Enfin, une fois que tous les processus qui ont "engagé" de l'espace dans l'extension se sont arrêtés (à l'arrêt du système d'exploitation si ce n'est pas plus tôt), les extensions sont libérées en silence et le fichier d'échange reprendra sa taille et son allocation précédentes - s'il était contigu auparavant, il est à nouveau.

Autoriser l'expansion du fichier d'échange agit donc comme un filet de sécurité totalement gratuit: si vous l'autorisez mais que le système n'en a jamais besoin, le système "ne se développera pas et ne contractera pas constamment le fichier d'échange" comme on le prétend souvent, donc cela ne coûtera rien . Et si vous en avez besoin, cela vous évitera que des applications ne plantent avec des erreurs de «mémoire virtuelle insuffisante».

Mais mais mais ...

J'ai lu sur des dizaines de sites Web que si vous autorisez l'expansion du fichier d'échange, Windows se développera et se contractera constamment, et cela entraînera une fragmentation du fichier d'échange jusqu'à ce que vous le défragmentiez.

Ils ont juste tort.

Si vous n'avez jamais vu le pop-up "manquer de mémoire" (ou, dans les anciennes versions, "manquer de mémoire virtuelle"), le système d'exploitation n'a jamais développé votre fichier d'échange.

Si vous voyez ce pop-up, cela vous indique que la taille initiale de votre fichier d'échange est trop petite. (J'aime le définir à environ 4x l'utilisation maximale observée, c'est-à-dire que le compteur de perfmon "% pagefile usage peak" doit être inférieur à 25%. Raison: l'espace du fichier d'échange est géré comme n'importe quel autre tas et il fonctionne mieux avec beaucoup d'espace libre pour jouer.)

Mais pourquoi ne font-ils pas simplement ...

On pourrait faire valoir que le système d'exploitation devrait simplement laisser l'allocation se produire, puis laisser les références échouer s'il n'y a pas de RAM disponible pour résoudre les défauts de page. En d'autres termes, au-dessus de l'endroit où nous avons décrit le fonctionnement de l'erreur de page initiale, que faire si "allouer une page physique de RAM disponible" (étape 1) ne pouvait pas être fait car il n'y en avait pas et il n'y avait pas de place laissé à la page n'importe quoi pour rendre disponible?

Ensuite, le pager ne pourrait pas résoudre le problème de page. Cela devrait permettre à l'exception (l'erreur de page) d'être rapportée au thread défaillant, probablement modifiée en un autre code d'exception.

La philosophie de conception est que VirtualAlloc renverra zéro (techniquement un pointeur NULL) au lieu d'une adresse si vous manquez de limite de validation, et il est tout à fait raisonnable de s'attendre à ce que le programmeur sache qu'un appel VirtualAlloc peut échouer. Les programmeurs doivent donc vérifier ce cas et faire quelque chose de raisonnable en réponse (comme vous donner une chance d'enregistrer votre travail jusqu'à ce point, puis de terminer le programme "gracieusement"). (Programmeurs: vous vérifiez un retour de pointeur NULL de malloc, new, etc., oui? Alors pourquoi ne le feriez-vous pas?)

Mais les programmeurs ne devraient pas s'attendre à ce qu'une simple référence de mémoire comme

i = 0;             // initialize loop counter

peut échouer - pas s'il se trouve dans une région d'espace d'adressage validé avec succès. (Ou l'espace d'adressage mappé, d'ailleurs.) Mais c'est ce qui pourrait arriver si la philosophie «autoriser l'allocation surchargée, laisser la référence de mémoire échouer» était suivie.

Malheureusement, une référence de mémoire comme celle de la ligne de code ci-dessus n'a tout simplement pas de moyen pratique de renvoyer un mauvais état! Ils sont juste censés fonctionner , tout comme l'addition et la soustraction. La seule façon de signaler de tels échecs serait à titre d'exception. Donc, pour les gérer, le programmeur devrait encapsuler le programme entier dans un gestionnaire d'exceptions. (essayez ... attraper et tout ça.)

Cela peut être fait ... Mais il serait difficile pour le gestionnaire de savoir comment "faire la bonne chose" en réponse à ces exceptions, car il y aurait tellement, beaucoup de points dans le code où ils pourraient survenir. (Plus précisément, ils peuvent survenir à chaque référence de mémoire à la mémoire VirtualAlloc'd, à la mémoire allouée avec malloc ou new ... ainsi qu'à toutes les variables locales, car la pile est également VirtualAlloc'd.)

En bref, faire échouer le programme avec grâce dans ces cas serait très difficile.

Il est assez facile, d'autre part, de vérifier un retour de pointeur NULL de VirtualAlloc (ou malloc ou nouveau, d'ailleurs, bien qu'ils ne soient pas exactement la même chose), puis de faire quelque chose de raisonnable ... comme ne pas essayer d'aller et faire tout ce que le programme avait besoin de cet espace virtuel. Et peut-être demander à l'utilisateur s'il souhaite enregistrer son travail jusqu'à présent, le cas échéant. (Certes, beaucoup trop d'applications ne prennent pas la peine d'en faire autant.)

Autres utilisateurs de commit

Soit dit en passant, la «limite de validation» n'est pas réduite par les différentes allocations du système d'exploitation telles que le pool paginé et non paginé, la liste PFN, etc. ceux-ci sont simplement chargés d'engager la charge à mesure qu'ils se produisent. La charge ou la limite de validation ne sont pas non plus affectées par la RAM vidéo, ni même par la taille de la "fenêtre" de la RAM vidéo.

Testez-le vous-même

Vous pouvez faire une démonstration de tout cela avec l'outil testlimit du site SysInternals. L'option -m allouera l'espace d'adressage engagé mais ne le "touchera" pas, donc ne provoquera pas d'allocation de RAM. Alors que l'option -d allouera et référencera également les pages, entraînant une augmentation de la charge de validation et une diminution de la RAM disponible.

Les références

Windows Internals par Russinovich, Solomon et Ionescu. Il existe même des démonstrations vous permettant de prouver tous ces points à l'aide de l'outil testlimit. Cependant, je dois vous avertir que si vous pensez que cela a été long, soyez averti: le chapitre Mm à lui seul fait 200 pages; ce qui précède est une version EXTRÊMEMENT simplifiée. (Veuillez également consulter la section "Remerciements" dans l'introduction.)

Voir aussi la documentation MSDN VirtualAlloc