Dois-je désactiver le fichier d'échange si j'ai beaucoup de RAM ou dois-je le déplacer vers un disque RAM virtuel ?

@Groo Dernier paragraphe : " Il est inutile d'essayer de placer un fichier de pagination dans la RAM. ... "

@Eliah : oui, mais c'est correct : il y a pas de point en faisant cela. Ce qui est la même chose que ce qu'écrit Russinovich dans le lien de Spudone : "placer le fichier de pages sur un disque RAM est ridicule " . C'est pourquoi je ne comprends pas en quoi ce commentaire est pertinent (étant ce qui semble être une explication possible à la question de David sur le downvote).

Windows alloue-t-il toujours à l'avance des fichiers privés accessibles en écriture ? Sous Linux, je ne pense pas que quelqu'un fasse cela avec des fichiers énormes - MAP_NORESERVE et MAP_POPULATE sont des options qui vous donnent un certain contrôle sur les réservations et la population précoce des pages. Mais elles vous permettent également d'intercaler virtuellement des fichiers plus gros que la mémoire physique + l'espace de pagination. Bien sûr, vous pouvez vous retrouver dans des situations où vous SIGSEGV lors de l'accès, mais c'est un compromis connu.

@viraptor Si c'était le cas (et je ne suis pas certain à 100 % du comportement de Windows dans ce cas), mon argument serait encore plus fort : l'absence de fichier de pagination pourrait faire planter inutilement des applications, encore une fois parce que le système d'exploitation ne pourrait pas utiliser efficacement la mémoire vive dont il dispose.

Je contredisais le vote négatif. Mais pour ce qui est de votre dernier commentaire : Je fais tourner 2 machines différentes sans swap. C'est très bien si vous savez exactement comment la machine va être utilisée.

Je soupçonne que le fichier de page dans un lecteur de mémoire vive a commencé comme une "solution de contournement" du culte du cargo pour le fait que certains logiciels refusent de démarrer s'ils détectent qu'il n'y a pas de fichier de page. (On m'a dit que les outils graphiques/vidéo d'Adobe faisaient cela).

@DanNeely : +1. L'un des jeux Warhammer le fait aussi :)

Cette réponse ne devrait pas être acceptée. La conclusion est incorrecte car la réponse ne tient pas compte de l'hypothèse du PO selon laquelle il dispose de "tonnes de RAM", ce qui signifie qu'il a beaucoup plus de RAM qu'il n'en utilise. Dans un tel scénario, 1) la taille du cache du disque n'est pas affectée, et 2) le "gaspillage" de RAM dû à des allocations qui ne seront jamais lues n'est pas non plus un problème.

@Bigwheels La quantité de RAM dont vous disposez n'a pas d'importance. C'est comme dire que vous n'avez pas à vous soucier de l'argent parce que vous avez beaucoup de chèques dans votre chéquier. Si cette RAM est engagée, même si elle est inutilisée, le système devra refuser les allocations suivantes. (Prenons l'exemple d'un programme qui crée un mappage non partageable et modifiable d'un fichier de 1 Go. Même si aucune mémoire vive n'est utilisée par ce mappage, s'il n'y a pas de fichier de pagination, 1 Go de mémoire vive ne pourra être utilisé que pour des pages propres et jetables).

@David Schwartz : "si cette RAM est engagée, même si elle est inutilisée, le système devra refuser les allocations ultérieures". Pourquoi ? Pourquoi le système devrait-il refuser les allocations ultérieures ?

@Bigwheels Parce que le magasin de soutien est engagé. C'est la même raison pour laquelle vous ne pouvez pas faire un chèque simplement parce que vous avez assez d'argent sur votre compte en banque. Windows ne surengage pas le backing store, donc s'il n'a pas de fichier de pagination, il ne peut pas non plus surengager la RAM. La quantité de RAM libre n'a pas d'importance si elle est engagée, elle ne peut pas être utilisée pour contenir quoi que ce soit qui ne soit pas jetable, à moins qu'il n'y ait suffisamment de mémoire de sauvegarde non engagée. Un mappage de fichier insécable et inscriptible commits autant de mémoire de sauvegarde que la taille du mappage, même s'il n'utilise jamais de RAM.

@DavidSchwartz Je suis clair sur ce point. Un processus commits une certaine quantité de mémoire, et ensuite aucun autre processus ne pourra utiliser la mémoire qui a été engagée, même si cette RAM n'est jamais utilisée. Mais ce n'est pas un problème tant que toute la mémoire vive n'a pas été engagée. Par ailleurs, ce problème ne se pose pas uniquement lorsque vous n'avez pas de fichier de pages. Le fichier de pages vous donne simplement plus de mémoire pour commits avant d'atteindre la limite. Pour aller encore plus loin, je pourrais diminuer mon fichier de pages de 1 Go et ajouter 1 Go de RAM à mon système sans que cela ne soit ni mieux ni moins bien, en ce qui concerne la quantité de RAM qui peut être engagée.

@DavidSchwartz L'information que vous donnez est techniquement correcte, et c'est une bonne information à connaître. Mais la conclusion à laquelle vous arrivez, à savoir que vous devriez toujours avoir un fichier de page quelle que soit la quantité de RAM dont vous disposez, n'est pas correcte et je maintiens mon affirmation selon laquelle cela ne devrait pas être la réponse acceptée.

@Bigwheels Je n'arrive pas à cette conclusion. Relisez ma réponse.

@Bigwheels " Mais ce n'est pas un problème tant que toute la mémoire vive n'a pas été engagée. " Non, ce n'est pas vrai. En l'absence de fichier de pages, chaque octet de RAM engagé mais non encore utilisé est un octet de RAM limité à des pages propres et sauvegardées. Cela peut avoir un impact sur les performances (en forçant l'élimination précoce des pages propres qui font partie de l'ensemble de travail) bien avant que quoi que ce soit ne soit sur le point de s'épuiser.

@DavidSchwartz Tous les arguments que vous avez avancés contre l'absence de fichier de pages sont également valables lorsque vous avez un fichier de pages. En ce qui concerne vos arguments, ajouter 1 Go de RAM équivaut à ajouter 1 Go de pagefile. Je ne sais pas pourquoi vous insistez sur le fait qu'il est mauvais de ne pas avoir de pagefile, mais c'est un mauvais service pour les personnes qui lisent votre réponse.

@Bigwheels Sans fichier de pages, un mappage privé et modifiable de 1 Go empêche 1 Go de RAM de contenir des pages qui peuvent être jetées. Avec un fichier de pages de 1 Go, ce n'est pas le cas. Par conséquent, "Tous les arguments que vous avez avancés contre l'absence de fichier de pages sont également valables lorsque vous disposez d'un fichier de pages" est tout simplement faux. "Je ne sais pas pourquoi vous insistez sur le fait qu'il est mauvais de ne pas avoir de pagefile", parce que c'est est mauvais, pour toutes les raisons que j'ai expliquées. (Et que je ne vois aucune preuve que vous comprenez).

@DavidSchwartz Je ne comprends vraiment pas pourquoi les gens sont si farouchement pro-pagefile, alors que le bon sens (et l'expérience réelle) indique que cela fonctionne bien. Votre analogie "C'est comme dire que vous n'avez pas à vous soucier de l'argent parce que vous avez beaucoup de chèques dans votre chéquier" n'est pas correcte. L'analogie est la suivante : vous vous débrouilliez bien avec 50 000 dollars par an et vous gagnez 10 millions de dollars. Vous n'avez plus à vous soucier de l'argent si vous conservez raisonnablement le même style de vie. Si tout ce que vous voulez, c'est jouer à World of Warcraft et surfer sur le web, je suis certain que vous pouvez le faire sans pagefile sur une machine de 64 Go.

La seule raison acceptable de dire que tout le monde doit utiliser une pagefile en permanence, quelle que soit la quantité de mémoire vive dont il dispose et la manière dont il utilise son PC, serait que le système de gestion de la mémoire soit terriblement, terriblement défectueux. Une personne utilisant Win8 avec 4 Go de RAM a-t-elle besoin d'une pagefile ? Absolument. Est-ce que quelqu'un qui utilise Win8 avec 64 Go de RAM a besoin d'une pagefile ? Seulement s'il fait des choses énormes qui utilisent plus que les 4GB - 8GB que la plupart des utilisateurs utilisent. Et bien sûr, les pagesfiles peuvent provoquer des blocages. Comment les gens peuvent-ils encore discuter de ces points ?

@FredHamilton Dire que "les pagefiles peuvent provoquer un thrashing" équivaut à dire que le système de gestion de la mémoire est terriblement, terriblement cassé. Vous prétendez essentiellement que le fait de donner plus de choix au système (parce que c'est tout ce que fait un pagefile, il n'exige pas du système qu'il fasse quoi que ce soit) rend les performances moins bonnes. Je ne comprends pas comment vous pouvez dire "Seulement s'ils font des choses massives qui utilisent plus que les 4GB - 8GB que la plupart des utilisateurs utilisent". Comme je l'ai expliqué à plusieurs reprises, la quantité de mémoire vive disponible n'a pas d'importance.

@DavidSchwartz 'Dire que les pagefiles peuvent provoquer un thrashing équivaut à dire que le système de gestion de la mémoire est terriblement, terriblement cassé'. Je dirais que le système de gestion de la mémoire que vous décrivez EST terriblement cassé. Le seul univers dans lequel un système avec 4 Go de RAM et un fichier de page de 4 Go est plus fiable et moins trash qu'un système avec 64 Go et pas de fichier de page est un univers où le système de gestion de la mémoire est terriblement, terriblement cassé.

Je suis d'accord pour dire qu'un système doté d'un fichier de pages n'est pas OBLIGATOIREMENT trash - je sais simplement par expérience qu'avec toutes les versions de Windows que j'ai utilisées, il EST plus trash, parce que Windows lit/écrit le fichier de pages même lorsqu'il n'utilise que 10 % de la mémoire vive disponible. Personne ne vous contredirait si le système n'utilisait pas la pagefile jusqu'à ce qu'il en ait réellement besoin (je crois que linux s'en rapproche beaucoup, si ce n'est pas déjà le cas). Ce serait une excellente chose. Mais, du moins avec Windows, ce n'est pas ainsi que cela fonctionne.

@FredHamilton Non, ce serait une mauvais chose. Les le pire C'est à ce moment-là que les E/S causent le plus de dommages au système, car vous avez besoin de la capacité d'E/S pour lire dans le fichier de pages et pour écrire les données récemment modifiées. En fait, vous voulez commencer l'écriture opportuniste plus tôt, lorsque les E/S ne sont pas précieuses, afin que davantage de pages puissent être jetées plus tard. Je ne veux pas être impoli, mais je sais exactement de quoi je parle et j'ai passé des dizaines d'années à travailler sur ce sujet, il est très ennuyeux de se faire dire constamment que j'ai tort par des gens qui n'en ont pas la moindre idée.

Je n'ai pas dit que le SGM devrait écrire le fichier de pages à l'instant où il n'a plus de RAM, j'ai dit "jusqu'à ce qu'il en ait réellement besoin", et mon point de vue est qu'il ne devrait pas être nécessaire si vous avez une très grande quantité de RAM et que vous utilisez des programmes qui ne demandent qu'une fraction de cette quantité. Pourtant, Windows (du moins XP, la dernière fois que j'ai utilisé Windows avec une pagefile) lisait/écrivait suffisamment la pagefile pour provoquer des blocages, même si seulement 10 à 20 % de la RAM était utilisée.

Je comprends que les concepteurs du SGM puissent se préparer à une demande soudaine d'allocation de mémoire dans le pire des cas, mais je ne comprends pas pourquoi le fichier de pages a dû être écrit/lu si fréquemment pendant les heures/jours/années d'utilisation, alors que les tâches en cours d'exécution ne demandaient qu'une petite fraction de la RAM. Je ne dis pas que nous n'avons pas besoin de fichiers de pages, je dis simplement que sur une échelle de zéro à la perfection, ce SGM particulier était suffisamment loin de la perfection pour que je (et d'après ce que je peux dire, beaucoup d'autres) obtienne des E/S de disque dur beaucoup plus rapides sans conséquences négatives en désactivant le fichier de pages.

Je n'aime pas entendre dire que "les fichiers de pages sont magiques, ne les désactivez pas ou vous le regretterez", alors que je sais que dans de nombreuses circonstances courantes, vous pouvez peut Désactivez-les, et vous constaterez en toute sécurité une amélioration des performances, car vous n'augmentez plus les entrées/sorties sur disque de 100 % ou plus chaque fois que le SGM veut faire quelque chose. Tout ce que je veux entendre de la part des personnes de l'autre côté de ce débat, c'est "oui, il y a des circonstances où vous pouvez les désactiver et réduire les entrées/sorties sur disque qui peuvent résulter en un thrashing". Je ne dis pas que les fichiers de pages sont toujours mauvais, peut-être pouvez-vous dire qu'ils ne sont pas toujours nécessaires.

@FredHamilton Vous vous plaignez donc de ce que je n'ai pas dit ?

Je me suis rendu compte que ce qui m'énervait dans tout cela, c'est qu'un côté semble dire "les pagesfiles ne font jamais que du bien" et l'autre côté "les pagesfiles sont terribles" et ensuite les gens se retranchent dans un camp ou dans l'autre. La "vérité" est que dans certains cas, ils sont très utiles et permettent même d'éviter les crashs, et dans d'autres cas, ils ne sont pas nécessaires et peuvent même entraîner une baisse des performances. Je me contente de cette déclaration finale, quelle qu'elle soit. Longue vie et prospérité, @David Schwartz.

Et qu'en est-il d'un disque dur très lent ? Il pourrait provoquer un goulot d'étranglement dans l'ensemble du système.

@BamsBamx Si vous atteignez ce point, vous devez soit obtenir plus de RAM, soit un périphérique plus rapide pour le swap, soit réduire la charge sur la machine, soit tolérer la réduction des performances. Le matériel ne peut faire que ce qu'il peut faire.

@FredHamilton Je pense qu'un résumé plus correct est : Les fichiers de pages sont souvent utiles, parfois nécessaires, et s'ils ne sont pas nécessaires, ils ne font pas de mal (dans la grande majorité des cas). Voir les rapports de test détaillés ici : tweakhound.com/2011/10/10/… Mais si votre charge de travail a un jour besoin d'une pagefile et que vous n'en avez pas, que peut provoquer des pannes de programme, etc. La conclusion évidente est que vous devez avoir un fichier de pages. Considérez-le comme un filet de sécurité : Il n'encouragera pas les trapézistes à tomber, mais s'ils le font, c'est une bonne chose.

...en continuant : Le fait que Windows semble "utiliser le fichier de pages" alors que l'utilisateur a l'impression qu'il "ne devrait pas avoir à le faire" ne signifie pas qu'il fait du mal ; cela signifie surtout que l'utilisateur n'a pas suffisamment d'informations pour conclure qu'il "ne devrait pas avoir à le faire" ou qu'il "fait du mal". Le fait que le fichier de pages ne soit pas vide ne signifie pas qu'il vous ralentit. En permettant au système d'exploitation d'effacer les données périmées référencées depuis longtemps, il lui permet de libérer plus de mémoire vive pour les éléments auxquels on accède plus souvent.

La réponse acceptée est vraiment unilatérale et est donnée en supposant que l'utilisateur 1) veut que le système soit capable d'utiliser efficacement la mémoire vive et 2) utilise plus d'une application à la fois. Or, ces deux hypothèses peuvent s'avérer fausses dans certains cas. Par exemple, lorsque vous jouez à un jeu vidéo et que le moteur a mis en cache 30 Go de ressources, vous seriez vraiment déçu si le système d'exploitation en transférait certaines qui n'ont pas été utilisées pendant longtemps (même en les transférant sur un disque SSD rapide).

@Sergey.quixoticaxis.Ivanov Vous ne vous souciez pas de savoir si le système d'exploitation l'échange ou non, car il resterait en mémoire même après avoir été écrit, à moins que le système n'ait une meilleure utilisation de cette mémoire vive. Le fait d'écrire quelque chose dans le swap ne signifie pas nécessairement qu'il est mis au rebut.

Je fonctionne donc sous Windows avec 16gb de RAM et 16gb de swap. Il semble que ce système avec 64gb de RAM devrait être capable de faire ce que mon système peut faire, même sans swap. Il semble qu'il devrait au moins être capable de diviser sa RAM en deux et d'avoir 32gb de RAM libre et 32gb de ramdisk swap.

@NickSotiros Plus de RAM sera toujours mieux qu'une quantité équivalente de swap. Mais ce n'est presque jamais la décision à laquelle vous êtes confronté. Bien sûr, si vous avez le choix entre 16 Go de RAM en plus ou 16 Go de swap en plus, prenez la RAM.

Bien sûr, je ne m'en soucierais pas si la mémoire n'était pas modifiée. Quel était le but de votre commentaire ? Mais dans la pratique, elle peut être modifiée même lorsqu'il y a des tonnes de mémoire. Vos arguments tournent autour de "le système d'exploitation sait mieux s'il a quelque chose de mieux à faire" et "les développeurs du système d'exploitation ne sont pas des imbéciles" sans fournir d'informations détaillées.

Les développeurs de systèmes d'exploitation ne sont pas idiots, mais ces mécanismes ont été conçus pour le cas où "RAM < taille du code + taille des données auxquelles il accèdera", ce qui est faux pour, par exemple, les PC de jeu modernes où souvent "taille de RAM > côté de tout le code + taille de toutes les données auxquelles il accèdera jamais". Et la désactivation de la pagefile pourrait être perceptible.

On a déjà demandé à de nombreuses reprises à Microsft de fournir des outils permettant de régler les stratégies d'échange et de mise en cache, comme le font les systèmes d'exploitation basés sur Unix. Malheureusement, cette idée, bien qu'envisagée, n'a pas été mise en oeuvre.

@Sergey.quixoticaxis.Ivanov Les systèmes d'exploitation ont été réglés comme vous le dites il y a des années. Les systèmes de mémoire virtuelle de tous les principaux systèmes d'exploitation que vous êtes susceptible d'utiliser sur un PC ont été largement modifiés depuis lors. Les personnes qui demandent de telles poignées le font presque toujours parce qu'elles ont une idée erronée du fonctionnement de la gestion de la mémoire. Si le système d'exploitation n'est pas adapté à ces cas d'utilisation très typiques, c'est de la camelote. L'insaisissable bouton "faites en sorte que mon cas d'utilisation très typique aille beaucoup plus vite" n'existe pas, sinon on l'aurait déjà poussé.

Pouvez-vous fournir autre chose que des mots sur "tous les grands systèmes" et "c'est de la camelote" ? Quelque chose d'autre que vos propres convictions ? Une description de la stratégie de mise en cache peut-être ? Ou une description de la stratégie d'échange provenant de sources officielles ou autres ? Au moins un test qui montre où vous voulez en venir ? De plus, je ne vois pas ce qu'il y a de "très typique" dans ce scénario.

Bien sûr, posez une question à ce sujet et si je n'y réponds pas, signalez-le moi. Les développeurs de systèmes d'exploitation optimisent et affinent les systèmes de mémoire virtuelle avec précision depuis des décennies et pourtant les gens qui ne comprennent pas cela s'obstinent à chercher un bouton magique "aller plus vite" qui n'existe pas.

D'accord. La question principale : Quels sont les critères exacts utilisés dans Windows 10 pour déterminer si la page engagée peut être transférée sur le disque et la RAM physique sous-jacente réutilisée ? La question secondaire : si le système d'exploitation est un objet divin qui fonctionne selon des algorithmes idéaux, quel est l'intérêt de la fonction VirtualLock ?

@Sergey.quixoticaxis.Ivanov Le critère exact est qu'un tel échange produise une amélioration des performances dans les conditions mesurées par le système d'exploitation, sur la base d'un ensemble complexe d'heuristiques mises au point au fil de nombreuses années d'expérience. L'intérêt de VirtualLock est principalement de gérer les cas où les données ne peuvent pas être échangées pour des raisons de sécurité ou pour répondre à l'exigence occasionnelle de rapidité pour un petit morceau de données, même au détriment d'un comportement global du système plus mauvais. Le système d'exploitation est réglé par des experts en VM afin d'obtenir le meilleur comportement global du système dans une grande variété de conditions.

Encore une fois, aucune source à part "je crois" et "les experts de la vm". Ce n'est pas un critère concret. Des documents, s'il vous plaît. Des développeurs de systèmes d'exploitation, si possible, parce que tous les documents écrits sur le sujet que je connais de la part de développeurs de systèmes d'exploitation mentionnent les cas particuliers et notent que le système d'exploitation n'est pas réglé pour tout ce qui est possible et que la désactivation de la pagefile peut fournir un gain de performance dans certains scénarios. Il y a aussi beaucoup de tests qui montrent que la désactivation de pagefile, tout en ne faisant rien pour les fps moyens, peut (évidemment) augmenter les fps minimums dans les jeux si vous avez assez de RAM. Et cela peut être facilement reproduit.

@Sergey.quixoticaxis.Ivanov Il est amusant que vous vous plaigniez que je ne cite pas mes sources et que vous répondiez "tous les articles écrits sur le sujet que je connais", puis que vous enchaîniez avec "de nombreux tests". Mais votre thèse principale est tout simplement stupide - s'il y avait un moyen de rendre un système d'exploitation meilleur pour les tâches standard pour lesquelles tout le monde utilise le système d'exploitation, il serait mis en place de cette façon. Vous prétendez sérieusement que des experts en conception de machines virtuelles ayant des dizaines d'années d'expérience ont laissé un simple interrupteur dans la mauvaise position. C'est une position comiquement stupide. Vous pensez qu'ils ne peuvent pas savoir ce qu'est un jeu ou qu'ils pensent que les gens aiment les taux de rafraîchissement faibles ?

Je pense que Microsoft suppose que les quelques personnes qui ont des PC de jeu peuvent désactiver la pagefile si nécessaire en quelques clics. Si cela vous intéresse, voici un article, il est un peu ancien, mais il montre quelques benchmarks à la fin ( tweakhound.com/2011/10/10/… ). Malheureusement, mon nouveau PC sera en voyage pendant encore un mois, mais je pense que je ferai des benchmarks demain matin sur ma machine actuelle de 32 Go et je vous fournirai des nubers (ou je trouverai des liens). Pas maintenant, il est 5 heures du matin pour moi.

Note complémentaire : non, ce n'est pas drôle, parce que je n'ai pas donné de réponse sans fondement. J'ai quand même fait quelques tests : i7 4790k en stock, Titan X Pascal en stock, 32GB ddr3 1333, OS, tous les jeux et pagefile résidaient sur le même SSD Kingston 256GB. Pas de superfetch, le système a été redémarré après chaque test. Tous les tests ont été effectués 3 fois. Benchmark Time Spy : +0,2% score, +7% min fps, Fire Strike Ultra benchmark : +0.1% score, +13% min fps, Hitman:Absolution benchmark : +-0 fps moyen, +13% fps min, benchmark FFXV : -2 fps moyen, +15 fps min. Notez qu'il s'agit d'un très vieux PC, ce qui était le cas à l'époque où les jeux nécessitaient 2 à 4 Go de RAM.

Les PC de jeu modernes équipés de 64 Go, 128 Go et, je l'espère (j'espère qu'Intel présentera un bon processeur de jeu, et non les i7 et i9 à moitié construits qu'ils proposent actuellement) de 256 Go de RAM rapide bénéficieront très probablement encore plus de la désactivation de la pagefile dans les scénarios de jeu.

J'aimerais ajouter mes 2 cents que, sur les systèmes (surtout les portables) avec un espace disque restreint (250 GB SSD) et beaucoup de Ram (32 gb), c'est une bonne idée de réduire le pagefile à une taille personnalisée (dans mon cas, 1 gb minimum et 4 gb max). En effet, Windows 7, par défaut, fixe la taille de la pagefile à celle de la mémoire vive disponible (32 Go, dans ce cas), ce qui revient à inutiliser près de 13 % de votre disque. Avec ces paramètres personnalisés, vous disposez toujours d'un fichier de pages pour décharger certains éléments du noyau et paginer la mémoire ancienne et inutilisée, sans compromettre une grande partie de votre SSD.

"Les personnes qui ont conçu le comportement de votre système d'exploitation ne sont pas des imbéciles" - et ces personnes ont ajouté des paramètres pour désactiver le fichier de page - ils ont définitivement optimisé la gestion de la mémoire pour ce cas :)

Je suis fondamentalement en désaccord avec cette réponse et je suis d'accord avec Fred dans ces commentaires. Vous ne cessez de parler de "choses périmées" qui peuvent être retirées. Pour les personnes comme moi qui ont beaucoup de processus ouverts mais la ram pour les supporter, je veux instantané basculement de la touche alt-tab vers les anciens processus sans délai. L'utilisation d'un fichier de pagination, même avec 90 % de RAM libre, ne permet pas cela. Fenêtres se mettre en cache les processus qui ne sont pas utilisés depuis longtemps, même si cela n'est pas nécessaire. Pour beaucoup de gens comme moi, il s'agit d'un coût de performance inacceptable et inutile qui est simplement codé dans Windows sans raison valable.

@DavidSchwartz Si vous avez 5000 EXABYTES de RAM mais vous aurez toujours besoin de Fichier de pages parce que les "experts" l'ont dit ;-)

@user4779 Il les écrira dans le cache mais ne les supprimera pas de la RAM. Cela permet au système d'aller plus vite en cas de pression de la mémoire, car il n'est pas nécessaire de les écrire en premier lorsque le système rencontre une pression de la mémoire et que les E/S sont précieuses. En cas de pression de la mémoire, tout ce que vous faites ralentit, quoi que vous fassiez. Il n'existe pas de méthode magique pour remédier à la pression de la mémoire lorsque l'ensemble de travail dépasse la RAM. Comme je l'ai dit, les personnes qui ont conçu le comportement de votre système d'exploitation ne sont pas des imbéciles. Si vous pensez vraiment qu'ils le sont, utilisez un autre système d'exploitation.