Eh bien, tout d'abord, avant de répondre plus en détail. Dans votre première capture d'écran, votre pool non paginé (un type d'utilisation de la mémoire du noyau) est de 1,3 Go. Cela me semble anormalement élevé, surtout pour seulement 30 minutes après le démarrage. Je suppose que je pourrais voir le NP Pool atteindre ce niveau après une utilisation prolongée ou avec un programme qui fuit comme une passoire. En revanche, mon pool NP se situe généralement entre 100 et 200 mégaoctets, et mon pool paginé peut atteindre 400 ou 500 (et ce, après que mon système ait fonctionné sans redémarrage pendant des semaines).
Vous pouvez activer quelques colonnes supplémentaires dans le Gestionnaire des tâches en cliquant avec le bouton droit de la souris sur les en-têtes de colonne, puis en choisissant Sélectionner les colonnes. Vous devez ajouter Working Set (private) , Working Set (shared) , Commit et NP Pool . Je vais parcourir tous les processus de tous les utilisateurs, et voir si l'un d'entre eux a un NP Pool de plus de 256KB. Si vous en voyez, en particulier ceux qui sont considérablement plus élevés, cela pourrait être la source du problème, ou du moins une partie de celui-ci.
Votre ensemble de travail total, c'est-à-dire la quantité de mémoire physique utilisée par un processus, est la combinaison des ensembles de travail (WS) privé et partagé. La mémoire privée est généralement plus importante pour la plupart des processus, mais certains peuvent utiliser une plus grande quantité de mémoire partagée. La somme des deux devrait normalement correspondre au WS total. commit est la quantité de votre ensemble de travail qui a été commise au backing store (dans la plupart des cas, le fichier de page Windows). Les applications en arrière-plan auront fréquemment un commit plus grand que WS, indiquant qu'une grande partie de leur pool de pagination a été échangée hors de la mémoire et dans votre fichier de pagination (ce qui est assez normal pour les applications de bureau qui ont été minimisées et non utilisées pendant un certain temps).
Le pool non paginé est la mémoire qui ne peut pas, et ne pourra jamais, être échangée hors de la mémoire physique... c'est effectivement votre utilisation minimale permanente de la mémoire physique. La mémoire du pool NP contient souvent du code de programme et des sections critiques qui doivent être en mémoire physique pour se comporter correctement ou en toute sécurité, des tas spéciaux, etc. Sur 60 processus, si tous ont 256 Ko de mémoire NP Pool, alors votre utilisation minimale absolue de la mémoire physique sera d'environ 15 360 Ko. Dans la plupart des cas, une ou deux applications peuvent avoir un NP Pool de 256 Ko, tandis que la plupart en ont moins, souvent beaucoup moins (ou pas du tout). Il est très improbable que le système affiche la totalité de l'ensemble des processus de travail, donc ne vous attendez pas à ce que l'utilisation de la mémoire soit aussi faible.
Enfin, l'intérêt d'avoir plus de mémoire est d'éviter d'avoir à paginer les données vers et depuis l'espace mémoire étendu (swap, fichier de page) sur un disque physique. La pagination est un processus qui implique le déplacement de blocs de mémoire physique allouée, en poussant certains vers le disque et en amenant d'autres dans la mémoire physique depuis le disque. La pagination est, pour faire simple, hautement indésirable. Elle n'est pas "mauvaise" en soi, mais elle peut être un véritable frein aux performances lorsqu'elle se produit trop fréquemment. Le but ultime de l'augmentation de la RAM physique totale dans un système est de permettre à plus de processus de garder plus de leur commit en mémoire physique (ensemble de travail plus grand). Consommer de la mémoire n'est pas un problème, et lorsqu'un plus grand nombre de processus d'exécution utilisent plus de mémoire, les performances totales du système et les performances des processus actifs seront généralement plus élevées, car l'activité du disque physique liée aux accès à la mémoire (défauts de page, spécifiquement) sera plus faible.
Windows gère la mémoire pour vous, et met automatiquement en page les données dans et hors de la mémoire vers et depuis le fichier de page (swap) pour vous. Si vous exécutez un processus qui a besoin de 9 Go de mémoire et que votre système utilise déjà 4 Go (sur 12 Go), le système déterminera automatiquement quels processus n'ont pas besoin d'un accès immédiat à l'ensemble de leurs ressources, et il transférera une partie ou la totalité de leur pool de données vers le fichier d'échange afin de libérer 1 Go supplémentaire. Si votre gros processus a besoin de plus de mémoire, Windows réduira encore l'ensemble de travail des autres processus jusqu'à ce qu'il ait suffisamment d'espace libre pour allouer le bloc nouvellement demandé. Votre gros processus pourrait éventuellement consommer toute la mémoire disponible, à l'exception du pool NP et peut-être d'une surcharge minimale supplémentaire pour les processus qui s'exécutent périodiquement et qui ne permettent pas à Windows de libérer davantage de leur ensemble de travail (c'est-à-dire qu'ils ont des défauts de page en attente que Windows pourrait échanger hors de la mémoire physique, mais parce qu'ils sont demandés, ils ne peuvent pas être déplacés).
Si un processus a besoin de plus de mémoire que celle à laquelle il est autorisé à accéder (les processus 32 bits peuvent généralement accéder à 2 Go, et certains à un peu moins de 4 Go avec des techniques améliorées, tandis que les processus 64 bits peuvent généralement accéder à environ 48 Go de mémoire chacun), Windows essaiera parfois de virtualiser sa mémoire avec de l'espace swap. Si une application 32 bits veut utiliser ses 2 Go d'espace maximum autorisé, mais que seulement 1,2 Go sont disponibles, Windows réservera les 2 Go complets dans le fichier de pagination, et déplacera les données du processus dans et hors du fichier de pagination selon les besoins afin de supporter l'utilisation de la mémoire de l'application. L'utilisation totale de la "mémoire" dans ce cas peut sembler supérieure à la mémoire physique disponible, si l'on se réfère à Total commit. Total commit sera généralement maximale à la taille de fichier de page grand total, qui, lorsqu'il est géré par le système, est généralement 2-3x la quantité de mémoire physique. Dans votre cas, le total de commit serait d'environ 24 Go, soit 2x votre mémoire physique de 12 Go (et cela est indiqué dans votre première capture d'écran, où il est indiqué : commit (GB) 3 / 23).
Un dernier point. Vous avez dit dans votre réponse que vous aviez 16 Go de RAM, alors que le gestionnaire des tâches ne voit que 12 Go de RAM. De deux choses l'une. Soit votre système n'a vraiment que 12 Go de RAM, soit l'une de vos barrettes ne s'enregistre pas correctement. S'il s'agit d'une clé de RAM (je suppose qu'il s'agit de 4 clés de 4 Go), il se peut qu'elle soit défectueuse, qu'elle ne soit pas correctement installée sur votre carte mère ou que votre carte mère ait un problème de détection de mémoire.
Pour vérifier si c'est le cas, vous devez d'abord mettre à jour le BIOS de votre carte mère à la dernière version. J'ai eu un problème similaire... mes six bâtons de RAM DDR3 à trois canaux (6x 2 Go) étaient tous bons après avoir testé chacun d'eux individuellement... mais ma carte mère décidait aléatoirement de ne pas compter un ou deux d'entre eux de temps en temps, me laissant souvent avec seulement 8 Go de RAM. Une mise à jour du BIOS a corrigé le problème, et j'ai maintenant un accès fiable aux 12 Go de ma mémoire.
