Cache disque : un buffer qui pourrait permettre une amélioration des performances disques durs en augmentant sa taille. IOPageLockLimit - LargeSystemCache

cr  01.04.2012      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Accélérer les écritures disques par l'augmentation de la taille du buffer disque - Doutes et risques

La manipulation de IOPageLockLimit et de LargeSystemCache est un réglage douteux et scabreux. Nous recommandons vivement de ne jamais y toucher.

L'augmentation de la taille de ce qui est appelé, par erreur, cache disque, semble donner des résultats sur des machines ayant des entrées / sorties disques extrêmement intensives (des machines utilisées en serveurs, ou des machines utilisant des systèmes de gestion de base de données).

Le terme de « Cache disque », largement employé, est faux. Microsoft elle-même ne l'utilise pas. Il s'agit d'un système de « bufferisation » (remplir petit à petit et vider d'un seul coup (écrire sur le disque), une « mémoire tampon » appelée « buffer » en anglais). Ce « buffer » est pris sur la mémoire RAM de l'ordinateur (avec les mêmes vitesses que la RAM). Un cache, lui, est une petite (car coûteuse) mémoire ultra rapide dans un composant électronique séparé.

« Caches » et « buffers » relèvent du principe général d'accélération par l'anticipation.

Avec les « buffers », on est de RAM à RAM, pas de RAM à cache. Le cache disque se trouve dans l'électronique embarquée des disques et est géré par le firmware (le logiciel microcodé) du disque, dans le disque. Cela n'a rien à voir avec le pilote du disque, ni avec Windows.

Cette « bufferisation » (ou « bufferisassion ») est la réponse de MS-DOS puis Windows, depuis la création de la société Microsoft et des PC d'IBM, à son orientation native vers la gestion de fichiers sans structure interne. Windows voit les fichiers comme d'uniques documents contenant des données en vrac (un document de traitement de texte, par exemple), et non pas comme une structure de données répétitives (un fichier articles, fournisseurs, employés...) gérés sous des méthodes d'accès indexées (séquentiel indexé, ISAM, Arbre B (BTree), etc. ...). S'il faut le faire, Windows aura besoin de s'adjoindre un vrai système de gestion de base données (MySQL, etc. ...).

Même le pseudo système de gestion de base de données de Microsoft Office, Access, fait monter l'intégralité de la base de données (du fichier) en mémoire RAM. Il n'y a pas de notion d'accès physique à un « enregistrement logique » décrit par la structure de la base et des relations entre les champs de données qui la constitue. Disons, pour simplifier, « aux lignes horizontales » de la vision que peut avoir un particulier non informaticien d'un fichier fait de « fiches » (de lignes), comme les lignes horizontales d'un tableau dans un tableur).

Le « buffer » va stocker des données à envoyer sur un disque (à écrire) et un dispositif va prendre en charge cette écriture, tandis que l'application qui demande l'écriture passe rapidement à autre chose. Plus le « buffer » (la mémoire tampon) est grand, moins les applications qui écrivent sur disque on à attendre que les écritures physiques, sur le disque, soient terminées pour passer à autre chose, ou rendre le contrôle (« passer la main ») au système pour partager le temps avec d'autres applications.

Agrandir le « buffer » serait donc un accélérateur. Mais, sur un PC de « monsieur tout le monde » (pas un serveur ou un gestionnaire de base de données), les petits doigts de l'humain sont particulièrement lents par rapport à l'ordinateur, et l'utilisateur ne manipule qu'un fichier à la fois. L'augmentation de la taille de ce « buffer » n'aura aucune incidence apparente (si ce n'est un catastrophique ralentissement de la machine, voire un plantage total et définitif).

Augmentation de la taille du cache disque - Le risque dramatique

Vous savez qu'un périphérique connecté en USB, par exemple un disque dur externe, ne doit jamais être déconnecté sans avoir demandé son « éjection ». Pourquoi ? Entre autre, pour que le système vide le « buffer » de tout ce qui est en attente dedans (écrive sur le disque ce qui est en attente d'écriture depuis le « buffer ») avant de « démonter » le périphérique puis de vous dire que vous pouvez le déconnecter.

Donner le temps de vider le buffer disque

Donner le temps de vider le buffer disque

Un risque dramatique est introduit par l'extension de la taille de ce « buffer » : celui de la fermeture de Windows ou de la coupure de secteur. Lors de la fermeture de Windows, celui-ci met du temps à se fermer. Tout le monde l'a remarqué et tout le monde hurle contre cette temporisation honnie et crispante.

Pourquoi cette temporisation ? Parce que Windows attend que les applications ouvertes soient fermées (qu'il n'y ait plus d'entrées / sorties physiques en cours, qu'il y ait libération des ressources mobilisées de manière exclusive, dont les fichiers ouverts, etc. ...). Or, une application n'a aucun contrôle sur ce qui se passe au niveau système. A la demande de fermeture d'une application, par l'utilisateur, l'application envoie le/les fichiers, ouverts et modifiés, en écriture et fermeture, ce qui est intercepté par le « gestionnaire de bufférisassion », et l'application dit au système « Vas-y, moi j'ai fini ». Windows, heureusement, donne le temps aux « buffers » de se vider - ce temps n'est pas « intelligent » mais arbitraire : 30 secondes ! C'est beaucoup puisque, normalement, quelques millisecondes devraient suffire, mais c'est prudent, ce que l'on ne va pas lui reprocher.

Là où le bât blesse, c'est lors de l'extinction brutale - la coupure de courant (coupure secteur, arrachage de la prise, appui durant 8 secondes sur le bouton arrêt, etc.). Si, à ce moment précis, Windows n'a pas fini d'écrire le contenu des « buffers » vers les disques, les données risquent d'être corrompues, voire les fichiers perdus (même si le système de gestion NTFS contient des sécurités). Or, plus le buffer est grand, plus le temps nécessaire à l'écriture de son contenu est grand ! C'est du simple bon sens.

Donc, la tendance des impatients à agrandir les « buffers » et à raccourcir les délais est une très mauvaise idée en termes de sécurité et intégrité des données, d'autant que l'on allume et éteint rarement son ordinateur.

Une expérience a été conduite par Assiste.com : extension du buffer à 8MO sur une machine 64bits sous Windows 7 64bits intégral, 8GO de RAM, deux disques, dont un externe en SATA. Lancement d'une application faisant de nombreuses entrées / sorties disque (un client Torrent). Lancement d'une application manipulant un fichier et utilisation du raccourci clavier « Ctrl + S » pour forcer un enregistrement. Le ressenti est un allongement dramatique du temps mis par « Ctrl + S » pour « rendre la main ».

La taille de 0,5 MO (512 KO) choisie par Microsoft est donc un compromis vitesse / sécurité qu'il ne semble pas judicieux de modifier.

Windows utilise un « buffer » de 512 KO pour ses échanges avec les disques durs.

Recommandation : ne touchez à rien.

Si vous tenez à y toucer, lancez l'éditeur du Registre (RegEdit - Mode d'emploi) avec privilèges d'administration.

La situation par défaut se trouve dans la clé du registre Windows
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ :

• IoPageLockLimit
  Dans la base de registre, la valeur IoPageLockLimit n'existe pas par défaut - supprimez-la si vous l'avez créée pour faire des tests.

• LargeSystemCache
  La valeur LargeSystemCache est à 0.
  

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\

La manipulation suivante permet de modifier cette taille.

HKLM est une abréviation pour HKEY_LOCAL_MACHINE

1. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\IoPageLockLimit
   Cette valeur de clé n'existe pas, par défaut, et Windows utilise un cache de 512 KO pour ses échanges avec les disques durs. La taille de cette pagination en cache peut être augmentée.
   Créer la valeur DWORD IoPageLockLimit
   Lui donner une valeur décimale, en octets, oscillant entre :
   
   1 MO (1024 KO) à exprimer en octets soit 1024 x 1024 = 1048576
   2 MO (2048 KO) à exprimer en octets soit 2048 x 1024 = 2097152
   4 MO (4096 KO) à exprimer en octets soit 4096 x 1024 = 4194304
   8 MO (8192 KO) à exprimer en octets soit 8192 x 1024 = 8388608
   16 MO (16384 KO) à exprimer en octets soit 16384 x 1024 = 16777216
   
   Fermer puis redémarrer l'ordinateur.
   Il n'y a pas de règle et la méthode des essais et erreurs est la seule. Après redémarrage, travailler et observer, ou non, une amélioration. Conserver la valeur donnant les meilleurs résultats (apparents ou mesurés avec un outil de mesure de performances - benchmark).
   

2. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache
   Mettre cette clé à 1
   (Uniquement sur les versions 32bits de Windows antérieures à Vista, c'est à dire tous les Windows XP 32 bits, tous les Windows 2000 et tous les Windows NT. Mettre ou maintenir impérativement à zéro sous Vista, 7 et 8).

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit

Accélérer l'ordinateur - Optimiser l'ordinateur - Accélérer Windows - Accélérer disque dur - IoPageLockLimit