Eh bien, première chose, avant d'entrer dans une réponse plus détaillée. Dans votre première capture d'écran, votre pool non paginé (un type d'utilisation de la mémoire du noyau) est à 1,3 Go. Cela me semble inhabituellement élevé, surtout pendant les 30 minutes qui suivent le démarrage. Je suppose que je pouvais voir le NP Pool atteindre ce niveau après une utilisation prolongée ou avec un programme qui fuyait comme une passoire. En revanche, mon NP Pool se situe généralement entre 100 et 200 mégaoctets, et mon pool de pagination peut atteindre 400 ou 500 (et ce après avoir fait tourner mon système 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 sur les en-têtes de colonne, et en choisissant “Sélectionner les colonnes”. Vous devez ajouter Working Set (private), Working Set (shared), Commit, et NP Pool. Je parcourrais tous vos processus de tous les utilisateurs, et verrais si certains d'entre eux ont un pool de NP de plus de 256KB environ. 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, la quantité de mémoire physique utilisée par un processus, est la combinaison des ensembles de travail privé et partagé (WS). L'ensemble privé est généralement plus important pour la plupart des processus, mais il peut y en avoir qui utilisent une plus grande quantité d'ensembles de travail partagés. Les deux devraient normalement s'additionner pour former le total de l'ensemble de travail privé et partagé. Commit est le montant de votre ensemble de travail qui a été engagé dans le magasin de sauvegarde (dans la plupart des cas, le fichier de la page Windows). Les applications en arrière-plan auront souvent un Commit plus important que WS, ce qui indique qu'une grande partie de leur pool de pagination a été échangée de la mémoire vers 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 de la mémoire qui ne peut pas, et ne pourra jamais, être échangée hors de la mémoire physique…c'est en fait votre utilisation minimale permanente de mémoire physique. La mémoire du NP Pool contient souvent du code de programme et des sections critiques qui doivent se trouver dans la mémoire physique pour se comporter correctement ou en toute sécurité, des tas spéciaux, etc. Sur 60 processus, si tous ont 256KB de mémoire NP Pool, alors votre utilisation minimale absolue de mémoire physique serait d'environ 15 360KB. Dans la plupart des cas, une ou deux applications peuvent disposer d'un NP Pool de 256 Ko, tandis que la plupart en ont moins, souvent beaucoup moins (ou aucune). Il est très improbable que le système puisse un jour paginer l'ensemble des processus en cours, 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 des données vers et depuis un espace mémoire étendu (swap, fichier de page) sur un disque physique. La pagination est un processus qui consiste à déplacer des blocs de mémoire physique allouée, à en pousser certains sur le disque et à en faire entrer d'autres dans la mémoire physique à partir du disque. Pour rester simple, le paging est très indésirable. Il n'est pas “mauvais” en soi, mais il peut être un véritable frein aux performances lorsqu'il se produit trop fréquemment. Le but ultime de l'augmentation de la mémoire vive physique totale d'un système est de permettre à un plus grand nombre de processus de conserver une plus grande partie de leur commit dans la mémoire physique (ensemble de travail plus important). La consommation de mémoire n'est pas un problème, et lorsque davantage 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é physique du disque liée aux accès à la mémoire (les fautes de page, en particulier) sera plus faible.
Windows gère la mémoire pour vous, et pagine automatiquement 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 nécessite 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 leur ensemble de travail, et il paginera une partie ou la totalité de leur pool de pages à échanger afin de libérer ce 1 Go supplémentaire. Si votre grand 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 processus volumineux pourrait éventuellement consommer toute la mémoire disponible, à l'exception du NP Pool, et peut-être quelques frais supplémentaires minimes pour l'exécution périodique de processus qui ne permettent pas à Windows de libérer une plus grande partie de son ensemble de travail (c'est-à-dire qu'ils ont des défauts de page en attente que Windows aurait autrement permutés 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 qu'il n'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), alors Windows essaiera parfois de virtualiser sa mémoire avec de l'espace de swap. Si une application 32 bits veut utiliser ses 2 Go d'espace maximum autorisé, mais que seuls 1,2 Go sont disponibles, Windows réservera les 2 Go complets dans le fichier de la page et déplacera les données propres au processus dans et hors du fichier de la page selon les besoins afin de prendre en charge l'utilisation de la mémoire de l'application. Dans ce cas, l'utilisation totale de la “mémoire” peut sembler supérieure à la mémoire physique disponible, si l'on passe de Total Commit. Le Total Commit atteint généralement son maximum à la taille totale du fichier de la page, qui, lorsqu'elle est gérée par le système, est généralement de 2 à 3 fois la quantité de mémoire physique. Dans votre cas, Total Commit serait d'environ 24 Go, ou 2x votre mémoire physique de 12 Go (et ceci 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 mémoire vive, alors que le gestionnaire des tâches n'en voit que 12. Il y a deux choses ici. Soit votre système ne dispose réellement que de 12 Go de RAM, soit l'un de vos sticks ne s'enregistre pas correctement. Si un stick de RAM (je suppose 4x 4Gb sticks), il peut être mauvais, peut ne pas être installé entièrement correctement dans votre carte mère, ou votre carte mère peut avoir un problème de détection de mémoire.
Pour vérifier si c'est ce dernier 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 sticks de mémoire vive DDR3 Tripple-Channel (6x 2 Go) étaient tous bons si on les teste individuellement… mais ma carte mère a décidé au hasard de ne pas en compter un ou deux de temps en temps, ne me laissant souvent que 8 Go de mémoire vive. Une mise à jour du BIOS a réglé le problème, et j'ai maintenant un accès fiable à tous les 12 Go de ma mémoire.
