Bonjour,  
 
je possède un PC assez récent qui tourne sous Windows 10 avec 16Go de Ram DDR3.
 
je rencontre depuis plusieurs jours un problème assez embêtant : En effet ma Mémoire "Mise en Cache" (que je regarde dans les performances du Gestionnaire des tâches) augmente continuellement et ne redescend jamais hormis bien sûr avec un redémarrage du PC..
Pour vous donner un exemple, quand j'allume l'ordi, la Mise en cache est environ à 2Go. Ensuite si j'ouvre quelques programmes elle commence à grimper et ne redescend pas même si je ferme ces programmes.  
J'ai découvert ce problème quand j'ai téléchargé un film d'environ 10Go ce qui a fait monter la "Mise en cache" à 13Go d'utilisation et qui à provoqué des ralentissements sur mes pages internet alors que j'ai la fibre.  
 
Du coup je voulais savoir si quelqu'un connaissait un moyen de pouvoir "vider" cette mémoire "Mise en Cache" sans devoir redémarrer le PC. Ou encore mieux un moyen d'éviter qu'elle grimpe aussi haut.
Pour info, j'ai fait des scans antivirus, anti malware etc mais rien n'a été trouvé.
 
Par avance merci pour votre aide    

C'est normal.
 
Tous les fichiers touchés par des I/O restent en mémoire cache (disque) OS, ce qui fait que plus tu utilises des trucs, plus ça monte.
Dès qu'une appli alloue de la mémoire, il tape dans ce qui est libre puis dans les pages de cache les moins utilisées.

Salut
 
Le film tu l'as téléchargé via le navigateur ?
Si oui, il suffit de vider le cache du navigateur, Ccleaner ou autre logiciel de nettoyage feront le taff très bien sans redémarrer.
 
Sinon, voilà un lien pour nettoyer les caches sous W7, peut-être celà t'aidera à nettoyer ton W10.

1 - Ce n'est pas un problème.
 
2 - A ma connaissance, les outils proposés ne gèrent pas l'invalidation du cache disque OS
 
3 - Il y a un outil dans les Sysinternals qui permet d'invalider le cache disque OS, c'est utilisé par les développeurs pour benchmarker le lancement de l'application qu'ils développent en cas de cache/filesystem froid. (le cache OS pouvant masquer des I/O inutiles, à optimiser)
 
4 - Ce n'est pas un problème.

Pour référence, ProcessIdleTasks() n'a aucun rapports avec le cache disque OS:
http://www.thewindowsclub.com/misc [...] sidletasks

C'est ce passage qui m'a fait parler de cache du navigateur.
Par contre j'ai du mal à saisir la notion de cache disk OS.

Quand tu dis que "ce n'est pas un problème", ça n'a pas l'air d'être le cas de l'auteur.

Peux tu donner des pistes de résolution de ce "problème" qui n'en est pas un ?

Pour notre culture bien sûr

Bien vu, j'avais zappé.
 
En fait, le problème vient du fait que le gestionnaire mémoire/cache disque OS a repoussé en swap des pages de process (celles de firefox, l'explorer windows, ou autre) considérées comme rarement touchées.  
 
Et ça rame quelques instants plus tard lorsque les pages sont relues depuis le swap.
 
C'est exactement le même problème lorsque l'on gravait une image ISO de dvd (~4Go) sur des machines qui n'avaient que 4Go de ram physique:  
 
- le burner lit séquentiellement l'ISO, le cache disque OS conserve ce qui est lu (pour rien dans ce scénario)
 
- tu touches quasi à rien pendant la gravure (ou le download, ou autre...), le gestionnaire mémoire converge vers "le marquage" de certaines pages mémoires comme froides (celles de l'explorer où il y a des pages qui stockent les messages d'erreur, les process en tâche de fond qui font rien, les DLLs d'icônes à la con....).
 
- en fin de gravure (au delà des 3Go on va dire dans cet exemple) lorsque les pages mémoire libres manquent, le gestionnaire mémoire va vouloir rendre le cache disque OS heureux en renvoyant en swap les pages mémoires de process rarement touchées (celles marquées comme froides donc)
 
- après la fin de l'opération, tu vas dans une autre appli, simplement l'explorer, et là ça rame pour récupérer les pages qui se font maintenant touchées.
 
moralité: des trucs ont fait un tour d'aller-retour dans le swap, à cause de la tentative de favoriser les futurs I/O de l'application la plus active.
 
---
 
C'est chiant, car pour contrer ça:
 
- le cache disque OS devrait détecter par heuristique que l'accès I/O est séquentiel (en lecture ou écriture), et devrait baisser la priorité de piquage de pages aux autres process lorsque le pool "libre" est épuisé.
 
- soit tu désactives le swap, ce qui est mal, car il y a toujours des trucs useless qui peuvent être libérés pour favoriser l'appli active.
 
----
 
Le contre-exemple, c'est par exemple un après-midi jeu vidéo.
 
Sur une machine de 16Go:
 
- Tu lances un gros truc, avec des grosses maps, genre un battlefield qui va pomper 10Go dans une grosse map
- 1Go nécessaires pour l'OS/drivers et les process de tâche de fond utilies
- 2Go perdu dans des trucs useless
=> Sans swap il te resterait 3Go au cache disque, donc 3Go de fichiers du jeu potentiellement conservées et réutilisées en cas de changement de map (le moteur essaye d'être conservateur au changemap, donc il recharge pas tout, sauf si tu quittes ; cas qui arrive avec bf quand tu changes de serveur, cas qui n'arrive pas dans dans un jeu source genre tf2 car tu changes de serveur sans quitter le jeu)
=> Avec swap, idéalement le gestionnaire mémoire renvoie tout ou partie des 2Go useless dans le swap, le cache disque OS monte à 5Go de données conservées qui ne seront potentiellement pas lues depuis le HDD/SSD au changement de map, ce qui est un gain de temps potentiel.
 
Tu "quittes" > les pages de trucs "useless" sont récupérées.
 
---
 
Au final ce cas borderline est effectivement présent depuis très longtemps (au moins Windows Xp), je pense qu'il existe aussi sous Linux et MacOS.
 
C'est pas trivial pour trouver les bonnes heuristiques au niveau couplage gestionnaire mémoire/cache disque.
 
C'est pas une bonne idée de provoquer l'invalidation du cache disque OS (hormis vouloir volontairement benchmarker son propre projet ou autre cas spécifique)
 
Il me semble que dans Windows 10, ils ont rajouté une priorité sur la pagination mémoire au niveau api win32, mais ce serait du cas par cas, et personne ne s'en sert.
 
---
 
Donc je dirais:
- le cache disque qui monte et consomme la mémoire libre est normal et optimal.
- ne jamais vider le cache disque OS (aucun "nettoyeur" genre ccleaner ne le propose, donc pas vraiment de soucis)
- le cas du swap post-opération sur un fichier qui fait 80% de la ram physique, malheureusement c'est LE cas borderline, c'est à MS d'améliorer leur heuristiques et le gestionnaire mémoire. (ce n'est pas un problème que pour eux, par design, c'est pas simple)

Du coup le problème de l'auteur pourrait être lié à une désactivation du swap ? Ou un swap trop réduit ?
D'après ce que je comprends, son gros fichier n'est pas parti dans le swap, mais est resté en cache RAM > RAM, pas RAM > Swap ?

Reste une grosse incertitude sur ce qu'est le cache par rapport au swap et où sont stockées les données mise en "cache".
A priori ce serait bien stocké dans la ram vu qu'il suffit d'éteindre et redémarrer le PC pour que le cache soit vidé, j'me trompe ?

Non, son gros fichier a poussé (par mise en cache) des pages d'autres trucs, considérés (à tord d'un point de vue user, mais pas d'un point de vue kernel) comme inutiles dans le swap.
 
Les pages de cache disque OS, les pages libres, les pages de process, le swap, sont des vases communicants avec des règles de priorité dissymétriques entre chaque.
 
- Lorsqu'un process a besoin d'une page, il pique une page libre, ou alors une page froide de cache disque, au final des pages froides d'un autre process (qui sont renvoyées en swap).
 
- Lorsque le cache disque a besoin d'une page, il fait pareil, page libre puis autre page froide de cache disque puis autre page de process froide (avec donc mise en swap de la page)
 
La subtilité réside dans le choix de piquer une autre page froide de cache disque (ce qui renvient à ce qu'un autre fichier ne soit plus caché en partie), et piquer une page froide de process.
 
Il se pourrait que le piège réside autour d'être actif au niveau I/O sur un seul et même fichier (handle) : une heuristique au niveau fichier manque peut-être de finesse.
 
---
 
L'autre problème, c'est que si son fichier de 10Go a été téléchargé via bittorent au autre, le pattern I/O est aléatoire et les heuristiques pour limiter la mise en cache en cas d'accès séquentiel tombent.

Conclusion c'est la gestion de la ram sous windows qui est catastrophique pour les gros fichiers ?

C'est un cas chiant vis à vis de l'optimisation des cas généraux, qui pourrait être contourné au cas par cas via une api de hint.  
 
On pourrait imaginer que le process de l'application déclare que pour le handle de fichier qui a été ouvert, le cachage doit être moins agressif.
 
Après comme il y a toujours moyen de faire mieux, il y a moyen de faire mieux au niveau gestionnaire mémoire/cache disque, ou pas.

ophiuchus > ton fichier de 10Go c'était du vuze , non ?

Et du coup, maintenant qu'il a son fichier de 10Go, qu'il redémarre son PC pour que l'utilisation mémoire soit au minimum et qu'il ouvre son film pour le regarder.
Il va faire quoi windows, remettre 10Go en cache ?
 
Si windows n'est pas capable de gérer correctement la ram avec 16go je pige pas pourquoi on a pas plus souvent ce genre de problèmes sur le fofo ?

Il va potentiellement conserver 10Go en cache au fur et à mesure qu'il lit le fichier, sauf que déjà il sera lu séquentiellement ce qu'il fait qu'il sera moins agressif arrivé en fin de pages libres.
Je pense que comme je disais c'était un téléchargement à I/O aléatoire, le cache disque a été un peu trop agressif.
 

Ce n'est pas qu'il ne gère pas correctement la ram, c'est juste que des optimisations qui font sens en usage desktop ou multimédia normal se retournent dans d'autres cas d’utilisations (un client bittorent qui fait des I/O random, ça a un pattern de serveur SQL).
Et c'est bien pour ça que les kernels sont ajustés différemment suivant le profil de charge ciblé.

Ok chef !

Bonjour et merci à tous pour vos réponses ! Je ne pensais pas en trouver autant en rentrant du boulot
 
Alors, pour les précisions : Le film je l'ai téléchargé sur navigateur avec Mozilla. D'ailleurs je viens d'essayer avec Edge et le problème est le même.  
D'autre part, en vidant le cache des navigateurs ou même en utilisant Ccleaner cela ne change rien.  
Mais je viens de trouver un autre indice : La Mise en cache retombe au point initial soit en interrompant le téléchargement avant la fin soit en supprimant complétement le film de la corbeille.  

D'accord, donc à priori le téléchargement était séquentiel (sauf en cas de plugin qui ouvre plusieurs connexions en simultané, on là on retombe sur du random).
 
Que le cache disque OS consommé pour un fichier soit invalidé lorsque le dit fichier est supprimé du filesystem est à priori cohérent.

 
Après c'est une problématique qui traine depuis un certain temps.
 
Comme je le disais à l'époque dans le cas d'une gravure ISO de dvd à l'époque des machines de 4Go ça se voyait, maintenant la ram physique est supérieure à la taille des fichiers physiques typiques, donc c'est potentiellement masqué.
 
Ça reste un worst-case scenario qui arrive rarement, ce qui fait que ce n'est pas assez remonté au niveau ingés kernel chez MS. (ils ne veulent peut-être trop toucher à l'ajustement des heuristiques desktop/serveur pour le moment)
Peut-être quelque chose à remonter via le blog MS, ou autre.

D'accord merci beaucoup. Du coup il n'y a pas vraiment de solution actuellement ?

Que la cache OS monte en consommant les pages libres, c'est optimal.
 
Après la seule manière de l'empêcher de trop bouffer des pages "froides" de process, c'est de limiter la taille du swap.
 
Si tu es sûr de ne jamais utiliser plursieurs applis très lourde, tu peux limiter le swap à 512Mo~1Go.
 
Mais c'est vraiment quelque chose que tu observeras que dans le cas d'I/O sur un très très gros fichier.

C'est fou ce qu'on en apprend quand même.
Thx bjone