Que représente réellement l'« utilisation mémoire » sous Windows — Lire correctement Working Set, Private Bytes, Commit et le fichier d'échange

Le Gestionnaire des tâches affiche « 1,2 Go » pour la « mémoire » d’un certain processus. Pourtant, dans Process Explorer, le Working Set indique 1,5 Go, Private Bytes 2,4 Go, et dans VMMap, la Size est encore plus grande. Pour l’ensemble du système, on lit « Committed 19,6/31,8 Go ».

Alors, combien de gigaoctets de mémoire cette application utilise-t-elle réellement ?

Le fait que ces chiffres diffèrent ne permet pas de conclure que l’un d’eux est faux. L’indicateur à consulter dépend de ce que l’on veut savoir.

La quantité actuellement en RAM, l’allocation propre à ce processus, la quantité que le système s’engage à soutenir à l’avenir, et la plage d’adresses virtuelles réservée sont des choses distinctes. Avant de demander « combien de Go ? », établissez d’abord « la quantité de quoi ? ».

Ce qui rend les indicateurs de mémoire de Windows difficiles, c’est qu’ils s’affichent tous sous le même mot « mémoire », alors qu’ils mesurent en réalité les axes distincts suivants :

• combien d’espace d’adressage est utilisé
• combien de commit est consommé
• si la page est actuellement résidente en RAM physique
• si cette page est propre au processus ou partageable
• combien d’allocation supplémentaire le système peut encore soutenir dans son ensemble

Cet article s’adresse à ceux qui, sous Windows 10/11 et les versions actuelles de Windows Server, cherchent à comprendre la croissance de la mémoire d’une application ou une pénurie de mémoire à l’échelle du système. Il relie en un seul panorama Working Set, Private Working Set, Private Bytes, Commit, Virtual Bytes, le fichier d’échange, Available et les Page Fault.

La procédure pour remonter à la cause d’objets .NET non collectés est traitée dans « Distinguer l’attente du GC d’une fuite mémoire en .NET », et les manipulations concrètes de VMMap et Process Explorer dans « Process Explorer / Handle / VMMap en pratique ». Cet article se concentre sur le préalable des deux : la lecture des chiffres côté système d’exploitation Windows.

1. D’abord la conclusion

Working Set est « la quantité actuellement en RAM », Private Bytes est « la quantité promise exclusivement à ce processus », et System Commit est « la quantité promise par l’ensemble du système ». Commencez par lire ces trois-là séparément.

Aligner chaque indicateur sur la question à laquelle il répond

Attention aussi au nom d’API Win32 PagefileUsage. Sur Windows actuel, il représente en pratique le même Commit Charge que Private Bytes, et non la quantité réellement écrite dans le fichier d’échange.²

Ne pas juger seulement d’après « réservé » ou « augmenté »

Si une plage d’adresses virtuelles a seulement été réservée (Reserve), elle a simplement été mise de côté pour un usage futur. Elle ne consomme pas la même quantité de RAM ni de Commit Limit ; Reserve et Commit sont des étapes distinctes.⁴⁵

De plus, un Page Fault n’est pas nécessairement une E/S disque. Distinguez les soft faults, résolus en RAM, des hard faults, qui lisent depuis le fichier d’échange, un exécutable, un fichier mappé en mémoire, etc.¹⁶

Une fuite mémoire non plus ne se juge pas sur une seule grande valeur. Voyez si, lorsque la même charge est répétée, Private Bytes ou sa ventilation continue de monter par paliers après chaque cycle au lieu de revenir au même état stationnaire. Ce qu’il faut regarder n’est pas la taille à un instant, mais le plancher et la pente après répétition.

Lire d’après le symptôme ou l’objectif

Pour apprendre le mécanisme depuis le début, lisez dans l’ordre à partir du chapitre 2 ; si vous avez déjà des enregistrements, partez du tableau du chapitre 10.

flowchart TB
    accTitle: Choisir parmi les principaux indicateurs de mémoire Windows
    accDescr: L'indicateur à consulter change selon que l'on veut connaître la résidence en RAM, le commit propre au processus, le commit de l'ensemble du système, ou la plage d'adresses virtuelles
    question["Que veut-on savoir avec « utilisation mémoire » ?"]
    question -->|Quantité actuellement en RAM| workingSet["Working Set"]
    question -->|Quantité promise propre au processus| privateBytes["Private Bytes"]
    question -->|Quantité promise pour tout le système| systemCommit["System Commit"]
    question -->|Plage d'adresses réservée| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["Résidence en RAM physique"]
    privateBytes --> privateCommit["Commit propre au processus"]
    systemCommit --> commitLimit["Comparer avec le Commit Limit"]
    virtualBytes --> addressSpace["Espace d'adressage virtuel"]

Figure 1 : Décomposez d’abord l’observation « il y a beaucoup de mémoire » en quatre sortes de questions.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (18 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Séparer l’« utilisation mémoire » en quatre axes

On peut ranger les écarts de chiffres en se disant que la même page est comptée sous des angles distincts. Ici, on sépare quatre axes : l’état de l’adresse, le backing des données, la résidence en RAM, et la possibilité de partage avec d’autres processus.

flowchart TB
    accTitle: Quatre axes indépendants pour classer une page
    accDescr: Vérifier séparément l'état de l'adresse virtuelle, le backing des pages committées, la résidence en RAM physique, et la possibilité de partage avec d'autres processus
    page["Regarder une page selon quatre axes"]
    page --> address["État de l'adresse"]
    address --> addressValues["Free / Reserved / Committed"]
    page --> backing["Backing"]
    backing --> backingValues["Page-file-backed / File-backed"]
    page --> residentAxis["Résidence en RAM"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["Possibilité de partage"]
    sharing --> sharingValues["Private / Shareable"]

Figure 2 : Même pour une seule page, l’état d’adresse, le backing, la résidence et le partage se décident séparément.

Ne pas mélanger état, backing et possibilité de partage

Mapped n’est pas un état d’adresse au même titre que Free, Reserved et Committed : c’est un type de région. Les pages d’une vue mappée peuvent aussi être Committed.

Private, de son côté, n’est pas un support de backing, mais une classification de partage. On lit séparément si le backing est Page-file-backed ou File-backed, et si le partage est Private ou Shareable.

Comparer ce qui entre dans chaque indicateur

En combinant ces quatre axes, la relation des indicateurs représentatifs est la suivante.

flowchart TB
    accTitle: Correspondance entre types de pages et principaux indicateurs mémoire
    accDescr: Montrer quelles pages Private résidentes, Private non résidentes, partagées résidentes, ou seulement réservées, entrent dans quels indicateurs
    privateResident["Private, Commit, résidente en RAM"]
    privateNonresident["Private, Commit, non résidente en RAM"]
    sharedResident["Page partagée, résidente en RAM"]
    reservedOnly["Reserved, non Commit"]
    workingSet["Working Set"]
    privateWorkingSet["Private Working Set"]
    privateBytes["Private Bytes"]
    virtualBytes["Famille Virtual Bytes"]
    privateResident --> workingSet
    privateResident --> privateWorkingSet
    privateResident --> privateBytes
    privateResident --> virtualBytes
    privateNonresident --> privateBytes
    privateNonresident --> virtualBytes
    sharedResident --> workingSet
    sharedResident --> virtualBytes
    reservedOnly --> virtualBytes

Figure 3 : Working Set et Private Bytes comptent des ensembles de pages différents, donc il n’y a pas de simple relation d’inclusion.

Il n’y a pas de relation d’ordre fixe entre Working Set et Private Bytes

L’important ici est que Working Set et Private Bytes ne sont pas dans une simple relation d’inclusion.

Private Bytes inclut des pages propres au processus mais actuellement non résidentes en RAM. Working Set, lui, inclut des pages partagées — code de DLL, mémoire partagée, etc. — que Private Bytes ne compte pas. Selon le processus et l’instant, Working Set peut donc être plus grand que Private Bytes, ou l’inverse.

De plus, additionner simplement les Working Set de plusieurs processus peut compter plusieurs fois la même page physique d’une DLL partagée. « Somme des Working Set = RAM utilisée » n’est pas toujours vrai.

3. Espace d’adressage virtuel — Reserve et Commit sont distincts

« Réserver une adresse », « committer », « toucher pour la première fois et charger en RAM » sont des événements distincts. Ce chapitre va de cette différence jusqu’aux raisons pour lesquelles une allocation peut échouer alors qu’il reste de la RAM libre.

3.1. Une adresse virtuelle n’est pas une adresse de RAM physique

Chaque processus a son propre espace d’adressage virtuel. Les pointeurs que l’application manipule n’indiquent pas directement une position en RAM physique : Windows fait correspondre, via les tables de pages, l’adresse virtuelle à une page physique ou à des données sur fichier.⁷

C’est pourquoi, même sur un PC avec 64 Go de RAM, l’espace d’adressage virtuel utilisable par un processus 32 bits est en général bien plus petit. Inversement, un processus 64 bits a couramment un espace d’adressage virtuel plus grand que la RAM physique.

3.2. Reserved, c’est seulement « avoir retenu l’adresse »

MEM_RESERVE de VirtualAlloc réserve une plage d’adresses virtuelles contiguë pour un usage futur. À ce stade, aucun stockage physique n’est associé aux pages, et on ne peut ni lire ni écrire cette plage.⁴⁵

Par exemple, même si une base de données ou un runtime réserve 8 Go d’adresses pour une croissance future, cela ne consomme pas à lui seul 8 Go de RAM ni 8 Go de Private Bytes.

3.3. Committed, c’est l’état « je promets de soutenir le moment venu »

MEM_COMMIT passe la page virtuelle à l’état Committed et promet que Windows fournira le backing nécessaire. Au moment du commit, la quantité est comptabilisée dans le Commit Charge du système.⁵

Committed ne signifie pas forcément que l’on peut lire et écrire

Les droits de lecture, d’écriture et d’exécution se décident séparément par la protection de page : PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, PAGE_NOACCESS, etc. Le seul fait d’être Committed ne signifie pas « lisible et inscriptible ».⁵

Commit et résidence en RAM sont aussi des étapes distinctes

La page physique réelle peut n’être allouée qu’au premier accès. Une page touchée pour la première fois est initialisée à zéro, passe par un Demand-zero fault et entre dans le Working Set.⁵¹

Ainsi, le même « réservé » a les trois étapes suivantes.

flowchart TB
    accTitle: Trois étapes, de Reserve au Commit et à la résidence en RAM
    accDescr: Réserver une plage d'adresses virtuelles, committer la page, puis allouer une page physique au premier accès pour l'entrée dans le Working Set
    reserve["MEM_RESERVE : réserver la plage d'adresses"]
    reserve -.-> virtualMetric["Se reflète dans la famille Virtual Bytes"]
    reserve -->|MEM_COMMIT| committed["Committed : accessible selon la protection de page"]
    committed -.-> commitMetric["Se reflète dans Private Bytes / System Commit"]
    committed -->|Premier accès, Demand-zero fault| resident["Allouer une page physique, résidente en RAM"]
    resident -.-> workingSetMetric["Se reflète dans Working Set"]
    committed -.->|Si pas encore d'accès| nonresident["Committed mais non résidente"]

Figure 4 : Reserve, Commit et premier accès sont des événements distincts, qui font bouger des indicateurs distincts.

Ces trois étapes font bouger séparément les chiffres de la famille Virtual Bytes, de Private Bytes et du Working Set.

3.4. Pourquoi OutOfMemory arrive alors qu’il reste de la RAM libre

Le succès d’une allocation mémoire ne se décide pas seulement d’après la RAM libre.

• L’espace d’adressage virtuel du processus est épuisé
• Il n’y a pas de plage d’adresses libres contiguë de la taille requise
• Le Commit Charge de l’ensemble du système a atteint le Commit Limit
• Un Job Object, un conteneur, un runtime ou une bibliothèque a son propre plafond
• Le processus est 32 bits
• Le tas natif est fragmenté

Même sous Windows 64 bits, l’espace d’adressage virtuel en mode utilisateur d’un processus 32 bits est en général de 2 Go si IMAGE_FILE_LARGE_ADDRESS_AWARE est inactif. Une application 32 bits qui l’a activé peut utiliser jusqu’à 4 Go sous Windows 64 bits.⁸

Donc « le PC a 20 Go de RAM libre, mais l’application 32 bits échoue vers 1,6 Go » n’est pas une contradiction. Ce n’est peut-être pas un problème de RAM, mais de fragmentation ou de plafond de l’espace d’adressage.

4. Working Set — les pages actuellement en RAM

Le Working Set est l’ensemble des pages de l’espace d’adressage virtuel du processus actuellement résidentes en RAM physique.¹

Y coexistent notamment :

• Le tas et la pile propres au processus
• Le code et les données en lecture seule de l’EXE et des DLL
• Les fichiers mappés en mémoire
• La mémoire partagée
• Les pages devenues propres au processus après copy-on-write
• Les pages touchées par le runtime et diverses bibliothèques

4.1. Une hausse du Working Set ne signifie pas forcément une hausse d’allocation

En hausse : des pages existantes ont peut-être seulement entré en RAM

Si l’on accède pour la première fois à une page déjà committée, le Working Set peut augmenter sans que Private Bytes change.

Si l’on mappe un gros fichier en mémoire et qu’on le lit dans l’ordre, des pages issues du fichier entrent dans le Working Set, et Private Bytes n’augmente presque pas.

En baisse : on peut encore détenir la même mémoire

Quand Windows trim le Working Set sous pression mémoire, l’application détient logiquement la même mémoire, mais le Working Set seul diminue. Un nouvel accès plus tard revient via un Page Fault.

Autrement dit, une hausse du Working Set n’est pas forcément « nouvellement alloué », une baisse n’est pas forcément « libéré ». On sépare le changement d’état de résidence et l’allocation/libération.

flowchart TB
    accTitle: Flux typique où seul le Working Set monte et descend
    accDescr: La même page Committed entre en RAM au premier accès, sort par Trim, revient par réaccès, tandis que Private Bytes reste comptabilisé
    committed["La même page Committed"]
    committed -->|Premier accès| resident["Résidente en RAM"]
    resident -->|Trim sous pression mémoire| nonresident["Non résidente"]
    nonresident -->|Réaccès, Page Fault| resident
    resident -.-> inWorkingSet["Incluse dans Working Set"]
    nonresident -.-> outsideWorkingSet["Non incluse dans Working Set"]
    committed -.-> privateBytes["Comptabilisée dans Private Bytes tant qu'elle est Committed"]

Figure 5 : Le Working Set monte et descend selon l’état de résidence, mais Private Bytes ne baisse pas tant que le Commit de la même page reste.

4.2. Le Working Set inclut des pages partagées

Si 10 processus partagent les pages de code de la même DLL, cette page peut apparaître dans le Working Set de chacun, alors qu’il n’en existe qu’un exemplaire en RAM physique. Que la somme des Working Set dépasse la RAM installée n’est pas immédiatement anormal.

Pour se rapprocher de « la RAM que ce processus occupe actuellement en propre », on regarde le Private Working Set. Ce n’est toutefois pas « toute la mémoire réservée par ce processus », mais seulement les pages Private actuellement résidentes.

4.3. Réduire de force le Working Set ne corrige pas une fuite

EmptyWorkingSet ou SetProcessWorkingSetSize peuvent chasser des pages du Working Set du processus. Ce n’est pas une opération qui libère le commit ni les références sur le tas. Private Bytes peut rester inchangé tandis que l’utilisation RAM apparente baisse, et les Page Fault augmenter au prochain accès.⁹

Si le chiffre du Gestionnaire des tâches ne diminue que juste après un bouton de réduction mémoire, puis revient dès que l’on reprend l’opération, ce n’est peut-être pas une « libération » mais seulement un trim du Working Set.

5. Private Bytes — la quantité de commit propre au processus

Private Bytes est la quantité de mémoire virtuelle committée exclusivement pour ce processus. Elle représente un Commit Charge non partageable avec un autre processus, que les pages soient ou non actuellement résidentes en RAM. Dans PROCESS_MEMORY_COUNTERS_EX de Microsoft, PrivateUsage correspond à cette valeur.¹⁰²

L’API Win32 a aussi le nom de champ trompeur PagefileUsage, mais la documentation actuelle le définit comme « le Commit Charge de ce processus » et indique que c’est la même valeur que PrivateUsage. Autrement dit, 2 Go de Private Bytes ne signifie pas « 2 Go écrits dans pagefile.sys ».²

Private Bytes est typiquement influencé par :

• Le commit du tas natif utilisé par HeapAlloc, malloc, new, etc.
• Les Private Data committées directement par VirtualAlloc
• La région committée du tas GC .NET
• La partie réellement committée des piles de threads
• Le Commit Charge de l’ensemble de la vue, réservé au mappage d’une vue copy-on-write (FILE_MAP_COPY)
• Les tampons Private conservés en interne par une bibliothèque ou un SDK de périphérique

En copy-on-write, le comptage précède l’écriture réelle. Une vue créée avec FILE_MAP_COPY peut rendre chaque page Private plus tard, donc le Commit Charge est réservé au mappage pour que l’ensemble de la vue puisse être soutenu par le fichier d’échange.¹¹

Ainsi, System Commit et le Commit Charge du processus (Private Bytes) peuvent augmenter de la taille de toute la vue avant même qu’une copie Private soit créée par écriture.¹¹

5.1. Pourquoi Private Bytes ne baisse pas après free ou un GC

Séparer la libération dans l’application et le rendu à l’OS

Même si l’application « libère » de la mémoire, le runtime ou l’allocateur de tas peut ne pas Decommit cette région vers l’OS et la garder pour réutilisation. Dans ce cas, elle est réutilisable à l’intérieur de l’application, mais Private Bytes reste élevé.

Une région dont seule une partie survit, la fragmentation, un cache ou un pool saturé jusqu’à son plafond, peuvent aussi maintenir un niveau haut.

Comparer le changement après la même charge, pas la valeur haute figée

Un Private Bytes élevé ne prouve pas une fuite. On compare le décalage dans le temps dans cet ordre.

1. Répéter le même traitement, le même nombre de fois.
2. Après le traitement, laisser le même temps d’attente.
3. Vérifier si Private Bytes revient au même niveau, ou plafonne à une valeur fixe.
4. Avec VMMap ou un dump de tas, vérifier quelle région ou quel type a augmenté.

flowchart TB
    accTitle: Pourquoi Private Bytes ne baisse pas après free ou un GC
    accDescr: Le changement de Private Bytes diffère selon que l'allocateur rend la région à l'OS ou la garde pour réutilisation
    release["L'application rend la région inutile par free / GC"]
    release --> decision{"L'allocateur la rend-il à l'OS ?"}
    decision -->|Decommit / Release| returned["Le Commit Charge diminue"]
    returned --> lower["Private Bytes baisse"]
    decision -->|Gardée pour réutilisation| retained["La région reste Committed"]
    retained --> high["Private Bytes reste haut"]
    retained --> reasons["Pool, cache, fragmentation"]

Figure 6 : Devenir réutilisable dans l’application et rendre le Commit à l’OS ne sont pas la même chose.

5.2. Une forme forte de candidate à la fuite

Une augmentation « en escalier », où le plancher monte à chaque charge, mérite attention.

Private Bytes
  ^
  |                    ________
  |             ______|
  |      ______|
  |_____|
  +----------------------------> répétition du même traitement

Cela dit, même en escalier, le JIT initial, les polices, un décodeur d’images, un pool de connexions ou le warmup d’un cache peuvent n’augmenter que quelques fois, puis se stabiliser. Plus que le fait d’augmenter, le fait de ne pas converger vers un état stationnaire compte.

6. System Commit — ce qu’est « Committed X/Y »

Jusqu’ici, on a surtout regardé les indicateurs d’un processus. Le « Committed X/Y » de [Performances] → [Mémoire] dans le Gestionnaire des tâches est un indicateur de l’ensemble du système. On le lit séparément des valeurs par processus.

• X : System Commit Charge
  La mémoire committée que Windows promet actuellement de soutenir pour l’ensemble du système
• Y : System Commit Limit
  Le plafond de commit que le système peut soutenir

Le Commit Limit est globalement déterminé par la somme de la RAM physique et de tous les fichiers d’échange. Sans fichier d’échange, il est un peu plus petit que la RAM installée.³⁶

flowchart TB
    accTitle: Relation entre System Commit Charge et Commit Limit
    accDescr: Le commit propre aux processus, des sections partagées et du noyau forme la valeur actuelle X ; la RAM physique et le fichier d'échange soutiennent le plafond Y
    processCommit["Private Commit de chaque processus"] --> charge["System Commit Charge : X"]
    sharedCommit["Commit des sections partagées soutenues par le fichier d'échange"] --> charge
    kernelCommit["Commit du noyau"] --> charge
    physicalRam["RAM physique"] --> limit["System Commit Limit : Y"]
    pageFiles["Fichier d'échange"] --> limit
    charge -->|X ne peut pas dépasser Y| limit

Figure 7 : X est la quantité actuellement promise, Y le plafond capable de soutenir cette promesse ; ce n’est pas un affichage d’utilisation du fichier d’échange.

Le System Commit Charge inclut, outre la somme des Private Bytes de chaque processus, le commit des sections partagées soutenues par le fichier d’échange et le commit consommé par le noyau. La somme des Private Bytes par processus n’explique donc pas X complètement.

6.1. Le Commit Charge n’est pas l’utilisation du fichier d’échange

Les 20 Go de « 20/31 Go » ne sont pas une quantité sur disque

Prenons un système de 16 Go de RAM, 16 Go de fichier d’échange, Committed 20/31 Go.

Ces 20 Go ne signifient pas « 20 Go écrits dans le fichier d’échange ». 20 Go est le total que Windows promet de soutenir, le moment venu, par de la RAM ou le fichier d’échange, pour des pages Private modifiables notamment.

Dans ces 20 Go se mélangent notamment les états suivants.

• La plupart sont résidentes en RAM
• Une partie est déchargée vers le fichier d’échange
• Committed mais pas encore accédée une première fois
• Consommée comme commit côté noyau

Le taux d’utilisation du fichier d’échange se lit sur un autre compteur

Pour le taux d’utilisation réel du fichier d’échange, on consulte Paging File(*)\% Usage séparément du Commit. Même les documents Microsoft expliquent qu’un taux élevé du fichier d’échange ne signifie pas à lui seul un problème de performance, et qu’il faut le juger avec l’atteinte du Commit Limit, la Modified Page List et les E/S de pagination réelles.⁶

6.2. Que se passe-t-il quand on s’approche du Commit Limit ?

Quand le System Commit Charge atteint le Commit Limit, on ne peut plus soutenir une nouvelle demande de commit. Cela peut mener à un échec d’allocation, un plantage d’application, une impossibilité d’opérer, etc.³

Ici, le X/Y du Commit compte plus que la « RAM libre ». Trim le Working Set pour créer de la RAM libre ne résout pas l’atteinte du Commit Limit si le Commit Charge lui-même ne diminue pas.

6.3. Les trois rôles du fichier d’échange

Le fichier d’échange a principalement les rôles suivants.

1. Étendre le Commit Limit
2. Permettre de décharger hors de la RAM des pages modifiées peu utilisées
3. Soutenir, selon la configuration, le vidage sur incident système

Invalidation et changement de taille se jugent d’après le commit de pic et les besoins de vidage

Il n’y a pas de relation simple du type : désactiver le fichier d’échange réduit forcément les E/S disque et accélère. Cela peut au contraire abaisser le Commit Limit, laisser en RAM des pages modifiées dont on n’a pas besoin pour l’instant, et empêcher de collecter le vidage nécessaire en cas de plantage.³⁶

La taille appropriée du fichier d’échange ne se décide pas seulement d’après la RAM installée. Microsoft explique aussi qu’on ne peut pas généraliser, parce que le System Commit Charge de pic et le type de vidage sur incident nécessaire diffèrent selon le système.⁶

7. Ventilation de la RAM physique — un Available bas ne suffit pas à juger

La RAM physique n’est pas utilisée seulement par le Working Set des processus utilisateur.

• Working Set de chaque processus
• Cache de fichiers système
• Listes de pages Standby, Modified, Free, Zeroed, etc.
• Paged Pool / Nonpaged Pool du noyau
• Mémoire détenue par les pilotes de périphériques
• Store de compression mémoire
• Régions partagées ou réservées avec le GPU et les périphériques
• Réservation matérielle

7.1. Available inclut aussi un cache réutilisable

Free et Available n’ont pas le même sens. Le Available MBytes de Windows inclut, outre Free et Zeroed, les pages Standby réutilisables au besoin. Ce n’est pas un indicateur qui ne compte que la RAM entièrement inutilisée.¹²

• Free : pages actuellement non allouées à aucun usage
• Zeroed : pages déjà mises à zéro pour pouvoir être transmises en sécurité à un autre processus
• Standby : pages sorties du Working Set, mais dont le contenu est encore en cache en RAM
• Modified : pages dont le contenu a changé, et qu’il faut écrire vers le backing approprié avant réutilisation

flowchart TB
    accTitle: Déplacements entre Working Set et listes de pages
    accDescr: Une page en cours d'usage va vers Standby si elle n'est pas modifiée, vers Modified si elle l'est, puis revient par réaccès, écriture ou réutilisation
    workingSet["Working Set : en cours d'usage"]
    workingSet -->|Retirer une page non modifiée| standby["Standby : candidate à réutilisation, contenu conservé"]
    workingSet -->|Retirer une page modifiée| modified["Modified : en attente d'écriture"]
    modified -->|Écriture terminée| standby
    standby -->|Réaccès| workingSet
    standby -->|Réutilisation pour un autre usage| reused["Allouée à un autre usage"]
    free["Free : inutilisée"] -->|Mise à zéro| zeroed["Zeroed : allouable à du nouveau"]
    zeroed -->|Accès après allocation| workingSet
    standby -.-> available["Incluse dans Available"]
    free -.-> available
    zeroed -.-> available

Figure 8 : Available n’inclut pas seulement le vide complet, mais aussi Standby, réutilisable au besoin.

Séparer un Free bas et une pression sur la mémoire physique

« Jeter tout le cache pour augmenter la RAM libre » n’est pas toujours un gain. Si les données nécessaires restent sur Standby, un réaccès les ramène vite dans le Working Set sans lire le disque.

Donc, même si Free est bas dans le Gestionnaire des tâches, si Available est suffisant et que les hard Page Fault et l’attente disque ne posent pas problème, Windows est peut-être simplement en train d’utiliser efficacement la RAM comme cache.

7.2. Quand la RAM diminue sans gros processus

Une consommation mémoire que la somme des Private Working Set de chaque processus n’explique pas n’est pas rare.

• Cache de fichiers et fichiers mappés en mémoire
• Nonpaged Pool / Paged Pool
• Pages verrouillées par un pilote
• Pages partagées
• Compression mémoire
• Allocations liées à la virtualisation ou au GPU

Dans ce cas, plutôt que de continuer à regarder la liste des processus, on consulte Use Counts, Processes, Priority Summary, File Summary dans RAMMap de Sysinternals. RAMMap est l’outil officiel pour décomposer la mémoire physique par usage, liste de pages et fichier.¹³

Si seul le Nonpaged Pool continue d’augmenter, on en est au stade de suspecter une fuite côté pilote ou noyau, pas le Private Bytes d’une application en mode utilisateur.

8. Page Fault — un nombre élevé n’est pas à lui seul anormal

Un Page Fault se produit quand le processus accède à une page qui n’est pas actuellement dans son Working Set. Malgré le mot « Fault », ce n’est pas une panne exceptionnelle, mais le mécanisme normal de la mémoire virtuelle.¹

La première séparation est : faut-il lire le disque ? Ensuite, on regarde ensemble, au-delà du nombre d’occurrences, le temps d’attente réel et la dégradation de réponse.

8.1. Soft Page Fault

Ceux qui se résolvent sans lire le disque.

• La page reste en Standby ou Transition
• Un autre processus a la même page partagée dans son Working Set
• Premier accès à une page Committed, allocation d’une page zéro
• Déjà en RAM par le prefetch du gestionnaire de mémoire

Donc un \Memory\Page Faults/sec élevé n’implique pas forcément des E/S disque ou de la latence.

8.2. Hard Page Fault

Ceux qui exigent de lire le contenu depuis un Backing Store sur disque. La source n’est pas limitée au fichier d’échange.

• Code et données d’un .exe ou d’une .dll
• Fichier mappé en mémoire
• Fichier d’échange

flowchart TB
    accTitle: Bifurcation entre soft Page Fault et hard Page Fault
    accDescr: Quand on accède à une page hors Working Set, traiter comme soft Page Fault si aucune E/S de stockage n'est nécessaire, comme hard Page Fault si elle l'est
    access["Accès à une page hors Working Set"] --> storageIo{"Une E/S de stockage est-elle nécessaire ?"}
    storageIo -->|Non : Standby, partagée, Demand-zero, etc.| soft["Soft Page Fault"]
    soft --> resident["Vers le Working Set sans lire le disque"]
    storageIo -->|Oui| hard["Hard Page Fault"]
    hard --> source{"D'où lire ?"}
    source --> image["EXE / DLL"]
    source --> mapped["Fichier mappé en mémoire"]
    source --> pagefile["Fichier d'échange"]
    image --> loaded["Vers le Working Set après lecture"]
    mapped --> loaded
    pagefile --> loaded

Figure 9 : Le nom Page Fault à lui seul ne permet pas de juger de la présence d’E/S disque.

Microsoft cite comme compteurs de hard fault \Memory\Pages/sec, \Memory\Page Reads/sec, \Memory\Pages Input/sec, etc. Même s’ils sont élevés, ce n’est pas forcément une mémoire basse : on les corréle avec Available MBytes, la latence disque et le temps de réponse réel.⁶

8.3. Ne pas poser de seuil unique

Un seuil fixe du type « Page Faults/sec au-dessus de 1000 est anormal » change de sens selon le stockage, la taille de page, la charge et la localité d’accès.

En pratique, on aligne sur le même axe temporel :

• Memory\Available MBytes
• Memory\Pages Input/sec
• Memory\Page Reads/sec
• Read latency / Queue du disque concerné
• Working Set et Private Bytes du processus concerné
• Temps de traitement de l’application, timeouts, réponse UI

Si, en même temps que la charge augmente, Available baisse, Pages Input/sec et l’attente disque montent, et le temps de traitement se dégrade, on a des bases pour suspecter une pagination due à une pression sur la mémoire physique.

9. Quel écran, quel outil, pour quoi

Décider d’abord un processus ou l’ensemble du système, une ventilation à un instant ou une série temporelle facilite le choix d’outil. Faites correspondre indicateurs et outils dans le tableau ci-dessous, puis passez à l’enregistrement.

flowchart TB
    accTitle: Choisir un outil d'enquête mémoire Windows
    accDescr: Choisir l'outil selon que la cible est un processus ou l'ensemble du système, un instant ou une série temporelle, et s'il faut aller jusqu'à l'intérieur du runtime
    question["Que veut-on isoler ?"]
    question --> processScope{"La cible est-elle un processus ?"}
    processScope -->|Oui| processTime{"Un instant ou une série temporelle ?"}
    processTime -->|Ventilation à un instant| vmmap["VMMap"]
    processTime -->|Série temporelle| perfmon["PerfMon / PowerShell"]
    processScope -->|Ensemble du système| systemView{"Ventilation de la RAM physique ou axe temporel ?"}
    systemView -->|Ventilation de la RAM physique| rammap["RAMMap"]
    systemView -->|Axe temporel incluant CPU, E/S, attente| wpa["WPR / WPA"]
    question --> runtime{"Faut-il suivre ce que le runtime retient ?"}
    runtime -->|Tas .NET| dotnet["dotnet-dump / PerfView"]
    runtime -->|Tas natif| native["WinDbg / Application Verifier"]

Figure 10 : En fixant d’abord le périmètre et l’axe temporel, on choisit les outils nécessaires sans excès ni manque.

9.1. Gestionnaire des tâches

Dans le Gestionnaire des tâches, on sépare les écrans.

• [Processus] ou [Détails] : famille Working Set, famille Commit Size d’un processus
• [Performances] → [Mémoire] : In use, Available, Committed, Cached, Paged pool, Non-paged pool de l’ensemble du système

Ne jugez pas seulement d’après le nom de colonne « Mémoire » : dans l’onglet [Détails], clic droit sur l’en-tête pour ajouter Working Set, Peak Working Set, Commit Size, etc. Les noms de colonnes varient un peu selon la version de Windows et la langue d’affichage, donc enregistrez après avoir confirmé le sens de la colonne.

9.2. Prendre une série temporelle avec PowerShell

D’abord, enregistrer les trois indicateurs du même processus

Si l’on connaît l’ID du processus cible, Get-Process permet de prendre en même temps les pentes de Working Set, Private Bytes et Virtual Bytes.

param(
    [Parameter(Mandatory)]
    [int]$ProcessId,

    [int]$IntervalSeconds = 5,
    [int]$SampleCount = 60
)

$samples = for ($i = 0; $i -lt $SampleCount; $i++) {
    $process = Get-Process -Id $ProcessId -ErrorAction Stop

    [pscustomobject]@{
        Timestamp      = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
        ProcessId      = $process.Id
        WorkingSetMB   = [math]::Round($process.WorkingSet64 / 1MB, 1)
        PrivateBytesMB = [math]::Round($process.PrivateMemorySize64 / 1MB, 1)
        VirtualBytesMB = [math]::Round($process.VirtualMemorySize64 / 1MB, 1)
        Handles        = $process.HandleCount
        Threads        = $process.Threads.Count
    }

    Start-Sleep -Seconds $IntervalSeconds
}

$samples | Format-Table -AutoSize
$samples | Export-Csv .\memory-samples.csv -NoTypeInformation -Encoding utf8

Process.WorkingSet64 de .NET correspond au Working Set, PrivateMemorySize64 à Private Bytes, VirtualMemorySize64 à Virtual Bytes.¹⁴¹⁵¹⁶

Éviter les confusions dues aux instances multiples et aux redémarrages

Pour une application à plusieurs instances, suivez le PID, pas le nom. Pour une surveillance longue où le PID change au redémarrage, il faut enregistrer l’heure de démarrage, le nom de service, etc., pour ne pas confondre la cible.

9.3. Aligner système et processus sur le même axe temporel avec PerfMon

Au minimum, enregistrer en même temps ce qui suit facilite l’isolement.

\Process(<cible>)\ID Process
\Process(<cible>)\Working Set
\Process(<cible>)\Working Set - Private
\Process(<cible>)\Private Bytes
\Process(<cible>)\Virtual Bytes

\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Commit Limit
\Memory\Pages Input/sec
\Memory\Page Reads/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes

Vérifier le PID de chaque échantillon, pas seulement le nom d’instance

S’il y a plusieurs processus du même nom, ou un redémarrage pendant la surveillance, le nom d’instance Process(name) ou Process(name#N) ne fige pas la cible. Enregistrez aussi ID Process à chaque échantillon, et ne retenez que l’instance dont la valeur correspond au PID suivi. Si le PID change au redémarrage, enregistrez aussi l’heure du basculement.

Si un compteur est introuvable, vérifier la langue d’affichage

Les noms de compteurs de performance Windows peuvent être localisés selon la langue d’affichage. Si la spécification directe du nom anglais en PowerShell ne les trouve pas, ajoutez-les depuis l’interface de PerfMon, ou confirmez les noms de l’environnement local avec Get-Counter -ListSet *.

9.4. Ne pas confondre les rôles de VMMap et de RAMMap

• VMMap : décompose la mémoire virtuelle et le Working Set d’un processus en Heap, Image, Mapped File, Private Data, Managed Heap, etc.
• RAMMap : décompose la RAM physique de l’ensemble du système par usage, liste de pages, processus, fichier

« Pourquoi le Private Bytes de ce processus a-t-il augmenté ? » est VMMap ; « À quoi a servi la RAM que la liste des processus n’explique pas ? » est RAMMap.¹⁷¹³

10. Lire le symptôme d’après les combinaisons de chiffres

Les valeurs enregistrées se lisent d’après quels indicateurs bougent ensemble, et lesquels ne changent pas. Le tableau suivant ne sert pas à trancher la cause, mais à choisir la ventilation ou la condition à confirmer ensuite.

Le plus important dans ce tableau est de lire par combinaison, pas par valeur isolée.

11. Procédure pratique d’enquête de fuite mémoire

L’enquête avance en cinq étapes : fixer les conditions de comparaison → enregistrer en même temps → identifier l’indicateur qui augmente → examiner la ventilation → comparer avant/après correction. On ne passe pas au dump dès qu’on voit une grande valeur : on circonscrit d’abord ce qui augmente.

11.1. D’abord fixer les conditions de reproduction et le point stationnaire

« Cela augmente en quelques jours » ne permet pas de comparer. Pour comparer version saine et version à problème dans les mêmes conditions, fixez d’abord :

• Jusqu’où inclure le warmup après démarrage
• Le contenu d’un cycle d’opération
• Combien de secondes attendre après un cycle
• Combien de fois il faut pour atteindre le plafond de cache
• Si version saine et version à problème peuvent utiliser les mêmes entrées

11.2. Enregistrer processus et système en même temps

Au minimum, laissez au même instant :

• Working Set de la cible
• Private Bytes de la cible
• Virtual Bytes de la cible
• Committed Bytes / Commit Limit du système
• Available MBytes
• Pages Input/sec
• Nombre de handles, nombre de threads
• Nombre d’opérations ou de traitements

Si le Private Bytes du processus est stable mais que seul le Commit du système augmente, il faut élargir le champ à un autre processus, au noyau, à un pilote, à une section partagée, etc.

11.3. Décider d’abord la « dimension » qui augmente

• Working Set seulement : pages résidentes, origine partagée/fichier, trim et relecture
• Private Bytes : commit propre au processus
• Virtual Bytes seulement : Reserve, mappage, fragmentation de l’espace d’adressage
• System Commit seulement : y compris autres processus et côté noyau
• Nonpaged Pool : côté pilote et noyau
• Handles / GDI / USER : fuite de ressource autre que la mémoire

Sauter cet ordre et prendre un dump d’emblée, c’est lire une grande quantité d’information alors que la cible n’est pas la bonne.

11.4. Passer à la ventilation

• Processus natif : VMMap, WinDbg, Application Verifier, trace de tas
• .NET : dotnet-counters, dotnet-gcdump, dotnet-dump, PerfView
• Ensemble du système : RAMMap, PerfMon, WPR/WPA
• Pool noyau : PoolMon, WinDbg

VMMap affiche par type la mémoire virtuelle committée du processus et le Working Set alloué à chacune. Le coût de la suite de l’enquête change beaucoup selon que l’on peut circonscrire l’augmentation de Private Bytes à « Heap », « Private Data », « Managed Heap » ou « Mapped File ».¹⁷

11.5. Après correction, comparer la pente dans les mêmes conditions

Une différence de pic avant/après correction ne suffit pas. Un décalage des valeurs initiales inverse facilement le résultat. Alignez les conditions suivantes, et comparez le plancher et la pente après chaque cycle.

• Même état de démarrage
• Mêmes entrées
• Même nombre d’opérations
• Même temps d’attente
• Même intervalle d’échantillonnage

La preuve d’une correction de fuite n’est pas « le maximum a diminué », mais l’augmentation converge même en répétant la même charge.

12. Reformuler les malentendus fréquents

Malentendu 1 : mémoire du Gestionnaire des tâches = total réservé par l’application

Reformulation : confirmez de quelle colonne il s’agit. Famille Working Set : quantité actuellement résidente en RAM. Famille Commit Size : quantité de commit propre au processus.

Malentendu 2 : Private Bytes = nombre d’octets sur le fichier d’échange

Reformulation : Private Bytes est le Commit Charge Private. C’est une quantité promise logique, qui inclut les pages en RAM et celles que le fichier d’échange peut soutenir au besoin.

Malentendu 3 : Commit X/Y = utilisation du fichier d’échange / capacité du fichier d’échange

Reformulation : X est le Commit Charge de l’ensemble du système, Y le Commit Limit. Le fichier d’échange étend Y, mais X n’est pas tel quel l’utilisation sur disque.

Malentendu 4 : Page Faults/sec élevé = on swappe vers le disque

Reformulation : cela inclut les soft faults. La présence d’E/S disque se confirme avec Pages Input/sec, Page Reads/sec et la latence disque.

Malentendu 5 : Free RAM bas = pénurie de mémoire

Reformulation : regardez Available, Standby, la pagination hard, le temps de réponse. Remplir la RAM d’un cache réutilisable est normal.

Malentendu 6 : on a pu réduire le Working Set = on a corrigé une fuite mémoire

Reformulation : on a peut-être seulement chassé des pages hors de la RAM. Vérifiez si Private Bytes et ce que le tas retient ont diminué.

Malentendu 7 : Private Bytes a augmenté = fuite confirmée

Reformulation : on ne peut juger qu’après avoir vérifié si cela converge en répétant la même charge, quel type de mémoire a augmenté, et s’il s’agit d’un cache libérable.

13. Conclusion

D’abord, décider ce que le chiffre compte

L’« utilisation mémoire » de Windows n’est pas un seul chiffre. Pensez séparément espace d’adressage, commit, résidence en RAM, possibilité de partage.

Le Working Set est les pages actuellement en RAM, Private et Shared compris. Le Private Working Set est, parmi elles, les pages résidentes propres au processus. Private Bytes, lui, est le Commit Charge propre au processus : ni la quantité actuellement en RAM, ni la quantité réellement écrite dans le fichier d’échange.

Ensuite, lire séparément réservation, résidence et pagination

Les adresses virtuelles Reserved, les pages Committed, et les pages réellement touchées qui sont entrées dans le Working Set sont des étapes distinctes.

Committed X/Y indique Commit Charge / Commit Limit de l’ensemble du système. Le fichier d’échange soutient principalement l’extension du Commit Limit, le déchargement des pages modifiées, et le vidage sur incident.

Un Page Fault est un fonctionnement normal, et un soft fault ne lit pas le disque. Les sources d’un hard fault incluent, outre le fichier d’échange, les EXE, DLL et fichiers mappés.

Dans une enquête, comparer plancher, pente et ventilation après la même charge

Une fuite mémoire se prouve non par la taille à un instant, mais par le plancher et la pente après la même charge, et par la ventilation.

Le chemin de base est VMMap pour la ventilation d’un processus, RAMMap pour la RAM physique de l’ensemble du système, PerfMon pour la série temporelle, et un outil de dump dédié pour l’intérieur du runtime.

La prochaine fois que vous remarquerez dans le Gestionnaire des tâches que « la mémoire augmente », reposez d’abord cette question.

Ce qui augmente, est-ce le Working Set, Private Bytes, Virtual Bytes, ou System Commit ?

Cette seule question rend l’entrée de l’enquête nettement plus précise.

Articles connexes

• Distinguer l’attente du GC d’une fuite mémoire en .NET — Procédure pratique pour observer, comparer et prouver la croissance mémoire
• Process Explorer / Handle / VMMap en pratique — Diagnostiquer les blocages, fuites et « fichiers en cours d’utilisation » à partir de l’état du système à cet instant précis
• Pièges de la mémoire partagée et bonnes pratiques concrètes
• Les profondeurs de l’E/S Windows (partie 4) — Le gestionnaire de cache : quand votre WriteFile atteint-il vraiment le disque ?
• Enquête sur les plantages après un fonctionnement de longue durée d’une caméra industrielle - La fuite de handles (partie 1)

Domaines de conseil connexes

KomuraSoft LLC traite les enquêtes de cause de croissance mémoire d’applications Windows, de dégradation de performance après un fonctionnement long, d’OutOfMemory de processus 32 bits, et de pénurie de mémoire qui n’apparaît que chez le client, en combinant PerfMon, VMMap, RAMMap, WinDbg et les outils de diagnostic .NET. Plutôt que de s’arrêter à « il y a beaucoup de mémoire », nous isolons quelle région augmente, lors de quelle opération, pourquoi, et d’où elle est référencée et retenue.

• Développement d’applications Windows
• Analyse de dysfonctionnements et des causes racines
• Conseil technique et revue de conception
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

La colonne « mémoire » du Gestionnaire des tâches est-elle toute la mémoire réservée par l'application ?

Non. Le Gestionnaire des tâches propose plusieurs colonnes de mémoire — la famille Working Set, la famille Private Working Set, Commit Size — et le sens change selon l'écran et la colonne consultés. Working Set désigne les pages actuellement chargées en RAM, tandis que Private Bytes ou Commit Size représentent la quantité de commit propre à ce processus. Ne lisez jamais une unique colonne « mémoire » comme la capacité totale réservée par l'application ni comme le volume d'une fuite.

Quelle est la différence entre Working Set et Private Bytes ?

Working Set est la quantité de pages visibles depuis ce processus et actuellement résidentes en RAM physique, y compris les pages partagées comme les DLL ou les fichiers mappés en mémoire. Private Bytes est la quantité de mémoire committée utilisée exclusivement par ce processus, qu'elle soit ou non actuellement résidente en RAM. Les deux valeurs ne coïncident donc jamais, et il n'existe pas de relation d'ordre simple entre elles.

« Committed 18/32 Go » dans le Gestionnaire des tâches signifie-t-il que 18 Go ont été écrits dans le fichier d'échange ?

Non. Le nombre de gauche est la quantité de commit actuellement promise par l'ensemble du système, le nombre de droite est le Commit Limit que le système peut soutenir. Ce plafond est globalement déterminé par la somme de la RAM et du fichier d'échange, mais le total de gauche ne se trouve pas intégralement sur le fichier d'échange. La plupart des pages committées sont en RAM, et certaines n'ont encore jamais reçu de page physique. À l'inverse, les pages qui peuvent être relues depuis leur fichier d'origine — comme celles d'un EXE, d'une DLL ou d'un fichier mappé en mémoire — n'augmentent pas nécessairement le Commit privé dans la même proportion que le Working Set.

Peut-on obtenir une erreur OutOfMemory alors qu'il reste de la RAM libre ?

Oui, cela arrive. L'insuffisance de l'espace d'adressage virtuel d'un processus 32 bits, le manque de plage d'adresses libres contiguës, le Commit Limit du système, ou des plafonds propres à un Job Object ou à un runtime sont autant de conditions d'échec d'allocation indépendantes de la RAM physique. En particulier, un processus 32 bits sous Windows 64 bits est en général limité à 2 Go d'espace d'adressage virtuel en mode utilisateur, sauf s'il est Large Address Aware.

Désactiver le fichier d'échange rend-il Windows plus rapide ?

On ne peut pas l'affirmer en général. Désactiver le fichier d'échange abaisse le Commit Limit du système, rend plus difficile le déchargement hors de la RAM des pages modifiées mais inutilisées, et affecte aussi la configuration des vidages sur incident. La taille du fichier d'échange doit être décidée en mesurant le pic de commit et les besoins en vidage sur incident ; ce n'est pas un paramètre à désactiver sans justification.

Un Page Faults/sec élevé signifie-t-il un manque de mémoire ?

Ce seul indicateur ne permet pas de le déterminer. Les Page Fault se répartissent entre les soft faults, résolus par une page Standby en RAM ou partagée avec un autre processus, et les hard faults, qui nécessitent une lecture depuis le disque. Ne vous fiez pas à Page Faults/sec isolément : croisez-le avec Pages Input/sec, Page Reads/sec, Available MBytes, la latence disque et le temps de traitement sur le même axe temporel.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.