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 ?

Convertir un système d'exploitation qui a été conçu à la base pour ne pas utiliser de swap est beaucoup plus difficile qu'il n'y paraît.

Les Macs modernes ont une partition de récupération - une partie du disque principal avec un système d'exploitation dépouillé qui peut réparer ou restaurer le système principal. À l'époque des installateurs de DVD, ils exécutaient un processus personnalisé, le système crée maintenant un disque RAM pour la partition d'échange car on ne peut pas garantir qu'un installateur dispose d'un espace disque fonctionnel. Le système d'exploitation comprend les cadres nécessaires pour exécuter le logiciel de maintenance inclus, qui est identique aux utilitaires disponibles après l'installation. Beaucoup moins de travail pour tout le monde.

En limitant le système à une seule application à la fois, la mémoire tampon n'est pratiquement jamais utilisée, mais le système d'exploitation s'attend à ce qu'elle soit là.

Mon système a 24GB de RAM, pour cette raison, j'ai désactivé le pagefile pour éviter l'usure de mon SSD sans avoir aucun problème. J'ai récemment créé un disque RAM, en utilisant 4 Go de ma mémoire pour stocker les fichiers de cache de Google Chrome, juste pour voir si cela augmenterait les performances des jeux en ligne Flash Player et de la navigation générale sur Internet. J'ai constaté une nette amélioration des performances grâce à cette expérience. Puisque j'avais plus d'espace disponible sur mon disque RAM, j'ai activé mon pagefile et défini la taille minimale et maximale à 1 Go, et je l'ai déplacé sur le disque RAM. Bien que je ne puisse pas dire qu'il y ait eu une augmentation des performances, mon système semble fonctionner de manière plus stable.

Déplacer la pagefile vers la RAM est une notion ridicule. Désactivez-la et ajoutez de la RAM.

Quelle que soit la quantité de RAM dont vous disposez, vous voulez que le système soit capable de l'utiliser efficacement. L'absence totale de fichier de pagination oblige le système d'exploitation à utiliser la RAM de manière inefficace pour deux raisons. Premièrement, il ne peut pas rendre les pages jetables, même si elles n'ont pas été accédées ou modifiées depuis très longtemps, ce qui oblige le cache disque à être plus petit. Deuxièmement, il doit réserver de la RAM physique pour soutenir des allocations qui sont très peu susceptibles d'en avoir besoin (par exemple, un mappage de fichier privé et modifiable), ce qui conduit à un cas où vous pouvez avoir beaucoup de RAM physique libre et pourtant les allocations sont refusées pour éviter le surengagement.

Prenons l'exemple d'un programme qui établit un mappage en mémoire privée et accessible en écriture d'un fichier de 4 Go. Le système d'exploitation doit réserver 4 Go de RAM pour ce mappage, car le programme pourrait modifier chaque octet et il n'y a pas d'autre endroit que la RAM pour le stocker. Ainsi, 4 Go de RAM sont immédiatement gaspillés (ils peuvent être utilisés pour mettre en cache des pages de disque propres, mais c'est à peu près tout).

La gestion de la mémoire est gérée par l'unité centrale et le fait que le fichier de pages soit activé ou désactivé ne fait pas la moindre différence dans la façon dont les pages sont traitées. C'est transparent pour Windows.

La priorité de la page ne change pas, les pages seront rejetées de la même manière. Les fichiers de pages sont utilisés par le CPU comme stockage secondaire, pas par le système d'exploitation. Ce n'est rien de plus qu'un cache de niveau 2 lorsque le niveau 1 (RAM) est épuisé.

Un exemple rapide et très sale : ma machine a 16 Go de RAM et pas de pagefile. Il y a 5 minutes, avec 13 Go en veille et seulement 2 Go libres, j'ai chargé Fallout 4. Les pages de faible priorité ont été supprimées pendant le chargement de Fallout.

Par ailleurs, le blogue Technet de 2008 sur le thème "Pushing Windows Memory Limits" est très trompeur - je dirais même jusqu'à la tromperie. https://i.stack.imgur.com/wXkmi.png Je ne suis pas certain que Mark l'ait écrit, mais j'espère que non, car cela changerait mon point de vue sur lui......

En fait, il y a des trous béants dans l'article et je suis stupéfait que personne ne les ait relevés vu le nombre de fois où ce blog a été référencé.

• Le fichier de pages et son emplacement sont gérés par Windows, le piégeage de l'accès mémoire à des emplacements qui ont été paginés sur le disque serait pris en compte par le CPU, mais transmis au système d'exploitation pour récupérer la page du disque et la charger.

En tout cas, voici une description pas si vague :

Windows ne peut pas atteindre des adresses plus élevées que celles du CPU - ce n'est pas possible.

Peu importe ce dont le système d'exploitation est capable, il est toujours limité par le matériel sur lequel il fonctionne parce que le système d'exploitation est en fait le CPU lui-même (registres internes).

Le pagefile est donc une zone du disque dur que le CPU utilise pour étendre l'espace d'adressage physique lorsqu'il ne peut pas physiquement ou architecturalement utiliser plus de RAM.

Sur une architecture x86 32 bits segmentée, par exemple, il existe deux segments de RAM de 2 Go.

Un est alloué au noyau. Les 2 autres Go sont pour le mode utilisateur. C'est tout ce que le RAM le CPU peut utiliser 32 broches de DRAM, mais un processus 32bit a 4GB disponibles, alors que faire ? Heureusement, le CPU peut utiliser le stockage secondaire, c'est-à-dire le disque dur, pour stocker les 2 Go supplémentaires de pages. Parce qu'il a des registres internes
Les emplacements physiques où les pages virtuelles référencées par le processus n'ont pas besoin d'être stockés en RAM. Mais ils doivent être stockés quelque part par le CPU.

Le processeur ne peut pas donner les 4 Go de RAM à l'application, mais il peut lui donner 4 Go d'adresse en utilisant le disque dur comme cache secondaire (ce qu'est réellement le disque dur).

Les pages sont déplacées dans et hors de la RAM par le biais du mécanisme de pagination interne, mais ce n'est pas la même chose qu'un fichier de pages. La pagination se produit toujours....

Le résultat final n'est vraiment pas si compliqué. Au cours des 15 dernières années environ, de nombreux utilisateurs finaux ont eu l'impression qu'un fichier de pages faisait partie intégrante du système d'exploitation. Il ne l'a jamais été. Cette idée fausse est en partie alimentée par des sociétés comme Intel et Microsoft.

La RAM est un dispositif de stockage rapide, le disque dur est un dispositif de stockage plus lent, donc essentiellement la RAM est un cache de niveau 1, le disque dur est de niveau 2 (sans tenir compte du cache du CPU pour cette analogie). L'unité centrale peut accéder aux deux.

Si l'unité centrale ne dispose pas de suffisamment de RAM pour stocker les pages dont elle a besoin, le disque dur peut être utilisé comme débordement. S'il y a beaucoup de RAM, alors le PF est redondant.

Jusqu'au Core 2, les processeurs Intel avaient un bus DRAM à 32 broches et 32 registres, ce qui signifie que le CPU avait accès à 4 Go de RAM et à 4 Go d'espace disque (pagefile). Il s'agit d'une limitation matérielle architecturale, et non d'une limitation Windows.

Le total disponible pour les processus était de 3,5 Go, car une table de pages occupe 512 Mo. C'est pourquoi 3,5 Go apparaissent dans Windows avec les CPU Intel (jusqu'au Core 2). Ajoutez un GPU et vous obtenez encore moins.

Xeon pouvait accéder à un total de 32 Go de RAM, 64 Go d'espace physique avec disque dur inclus (pagefile à nouveau). ( Cette page couvre le PAE, d'autres suivront avec des liens ajoutés. ).

http://www.windowsdevcenter.com/pub/a/Windows/2004/04/27/pagefile.html

Source de la troisième capture d'écran : Interface binaire de l'application System V Supplément processeur de l'architecture AMD64 Version préliminaire 0.99.7

J'ai l'intention de continuer à améliorer cette réponse et d'ajouter des sources et des informations pertinentes. J'aimerais trouver un équilibre entre le manque d'informations et l'excès d'informations techniques. Les suggestions sont les bienvenues. S'il vous plaît, ne votez pas à la baisse juste parce que c'est peut-être moins bien écrit.

@DavidSchwartz The information you give is technically correct, and it's good information to know. But the conclusion that you come to that you should always have a page file regardless of how much RAM you have is not correct and I stand by my claim that this should not be the accepted answer. – 
Jason Wheeler
 Feb 21

Jason a tout à fait raison. Maintenant que nous utilisons tous des serveurs à mémoire 64 BIT, les configurations de fichiers NO page sont excellentes pour les serveurs WEB, par exemple. Et comme les serveurs Windows sont EXTRÊMEMENT stables maintenant, le risque est de de manière significative réduit, SURTOUT si vous exécutez le scénario SDCARD/RAM que la plupart des boutiques VM haut de gamme utilisent : Conclusion : Les configurations de serveurs NO SWAPFILE, en particulier les serveurs virtualisés, sont maintenant une considération tout à fait raisonnable. Je veux dire, savez-vous combien coûtent les SDCARDs rapides ? ? Je travaille sous Windows depuis des décennies et je peux vous dire que j'ai utilisé des serveurs de fichiers sans permutation au fil des ans pour résoudre de nombreux problèmes. Dites-moi la dernière fois que vous avez eu un BSOD ? IMHO, nous devrions tous réaliser qu'il est temps de tester les configurations de fichiers zéro swap.