Qu'est-ce que le cache dans les disques durs

Mise en cache des enregistrements sur un périphérique de stockage est appelé en utilisant une mémoire volatile à grande vitesse pour accumuler les commandes d'écriture envoyées aux périphériques de stockage et les mettre en cache jusqu'à ce que des supports plus lents (soit des disques physiques, soit une mémoire flash peu coûteuse) puissent les gérer. La plupart des périphériques utilisant la mise en cache en écriture nécessitent une alimentation électrique ininterrompue.

Pour gérer la mise en cache des écritures sur disque, ouvrez Panneau de configuration - Gestionnaire de périphériques.

Au chapitre Périphériques de disque double-cliquez sur le lecteur souhaité.

Allez dans l'onglet Les politiciens

Retrait rapide

Cette valeur est généralement le meilleur choix pour les périphériques qui peuvent avoir besoin d'être retirés du système fréquemment, tels que les lecteurs flash USB, SD, MMC, Compact Flash ou des cartes mémoire similaires et d'autres périphériques de stockage externes enfichables.

Si l'option est sélectionnée Retrait rapide, alors Windows contrôle les commandes transmises à l'appareil à l'aide d'une méthode appelée cache pass-through... Avec la mise en cache directe, le périphérique traite les commandes d'écriture comme si le cache n'était pas présent. Le cache peut offrir un petit avantage en termes de performances, mais l'accent est mis sur l'optimisation de la sécurité des données en interceptant les commandes envoyées au périphérique de stockage principal. Le principal avantage est la possibilité de retirer rapidement un périphérique de stockage sans risque de perte de données. Par exemple, si vous retirez accidentellement un lecteur flash de son port, la probabilité de perdre des données écrites sur celui-ci est considérablement réduite.

Cette option est généralement optimale pour les appareils qui doivent fournir les performances les plus rapides possibles ; pour les appareils qui sont rarement supprimés du système. Si cette option est sélectionnée et que l'appareil est déconnecté du système avant que toutes les données y soient écrites (par exemple, lors du retrait d'une clé USB), des données peuvent être perdues.

Si l'option est sélectionnée Performances optimales, Windows utilise une technique appelée mise en cache en écriture différée. Cette méthode permet au périphérique de stockage de déterminer lui-même si le cache haute vitesse fera gagner du temps lors de l'exécution des commandes d'écriture. Si tel est le cas, le périphérique indique à l'ordinateur que les données ont été enregistrées avec succès, même si les données ne se trouvent pas réellement sur le périphérique de stockage principal (tel qu'un disque ou une mémoire flash). Cette méthode améliore considérablement les performances des opérations d'écriture, qui sont souvent le principal goulot d'étranglement pour les performances globales du système. Mais si, pour une raison quelconque, l'alimentation électrique de l'appareil est perdue, toutes les données du cache (que l'ordinateur considère comme stockées en toute sécurité) peuvent être perdues.

Écrire le cache sur le disque

Par Windows par défaut utilise le cache d'écriture sur le disque. Cela signifie que le système demandera périodiquement au périphérique de stockage d'envoyer toutes les données du cache au périphérique de stockage principal. La sélection de ce paramètre désactive ces commandes de transfert de données périodiques. Tous les appareils ne prennent pas en charge toutes ces fonctionnalités.

Si la principale préoccupation est grande vitesse transfert de données, vous devez activer les deux paramètres : dans la section Politique de suppression sélectionner un article Performances optimales, et dans la rubrique Politique de mise en cache des enregistrements sélectionner un article Autoriser la mise en cache en écriture pour cet appareil(si le matériel du système et le périphérique de stockage prennent en charge ces fonctionnalités).

Comment modifier les options de mise en cache d'écriture pour un appareil ?

La plupart des périphériques de stockage grand public tels que les clés USB, les cartes SD ou MMC, ou disques externes, ne permet pas de modifier les paramètres de mise en cache de l'appareil. Interne disques durs avec les interfaces SATA ou SAS fournies avec Windows permettent généralement de modifier ces paramètres (selon le fabricant de l'appareil). Pour comprendre les capacités de mise en cache d'un périphérique particulier et pour déterminer les options qui correspondent le mieux à vos besoins, reportez-vous à la documentation du fabricant.

En savoir plus sur la prévention de la perte de données

Les systèmes sur lesquels la mise en cache en écriture est activée n'importe où entre l'application et le périphérique de stockage doivent être stables et ne pas subir de surtensions. Si un périphérique connecté au système utilise la mise en cache d'écriture, les algorithmes de mise en cache de périphérique supposent une disponibilité continue de l'alimentation à la fois pour le cache et pour déplacer les données vers et depuis le cache. Si l'on sait que le système ou l'alimentation a des problèmes potentiels d'alimentation, ces opportunités ne doivent pas être utilisées.

Vous devez également retirer soigneusement les périphériques de stockage amovibles tels que les clés USB, les cartes SD, MMC ou Compact Flash et les lecteurs externes. Lors de l'utilisation du paramètre Retrait en toute sécurité Windows sera en mesure de protéger les données des utilisateurs dans la plupart des scénarios. Cependant, certains pilotes ou applications peuvent ne pas correspondre au modèle Windows, ce qui peut entraîner une perte de données lors de la suppression de ces périphériques. Si possible, ouvrez l'application Safely Remove avant de retirer tout périphérique de stockage externe du système.

Sources : Documentation d'aide de Windows.

AZPC - Ordinateur personnel de A à Z. Portail Internet sur les ordinateurs fonctionnant sous Windows.

Permettez-moi de vous rappeler que l'utilitaire Seagate SeaTools Enterprise permet à l'utilisateur de gérer la politique de mise en cache et, en particulier, de basculer les derniers disques Seagate SCSI entre deux différents modèles mise en cache - Mode Bureau et Mode Serveur. Cet élément du menu SeaTools s'appelle Mode Performance (PM) et peut avoir deux valeurs - Activé (Mode Bureau) et Désactivé (Mode serveur). Les différences entre ces deux modes sont purement logicielles - dans le cas du mode bureau, la mémoire cache disque dur est divisé en un nombre fixe de segments de taille constante (égale), puis ils sont utilisés pour mettre en cache les accès en lecture et en écriture. De plus, dans un élément de menu séparé, l'utilisateur peut même attribuer lui-même le nombre de segments (gérer la segmentation du cache) : par exemple, au lieu des 32 segments par défaut, définissez une valeur différente (dans ce cas, le volume de chaque segment sera être proportionnellement réduite).

Dans le cas du mode serveur, les segments de tampon (cache disque) peuvent être (ré)affectés dynamiquement, en modifiant leur taille et leur nombre. Le microprocesseur (et le micrologiciel) du disque lui-même optimise dynamiquement le nombre (et la capacité) de segments de mémoire cache en fonction des commandes envoyées au disque pour exécution.

Ensuite, nous avons pu découvrir que l'utilisation des nouveaux disques Seagate Cheetah en mode "Desktop" (avec partitionnement fixe par défaut - 32 segments) au lieu du "Serveur" par défaut avec partitionnement dynamique peut légèrement augmenter les performances des disques dans un certain nombre de tâches plus typiques pour un ordinateur de bureau ou des serveurs multimédias. De plus, cette augmentation peut parfois atteindre 30-100 % (!) selon le type de tâche et le modèle de disque, bien qu'en moyenne elle soit estimée à 30 %, ce qui, voyez-vous, n'est pas mal non plus. Parmi ces tâches figurent le travail de routine d'un PC de bureau (tests WinBench, PCmark, H2bench), la lecture et la copie de fichiers, la défragmentation. Dans le même temps, dans les applications purement serveur, les performances des disques ne baissent presque pas (si c'est le cas, elles ne baissent pas de manière significative). Cependant, nous avons pu observer un gain notable en utilisant le mode bureau uniquement sur le disque Cheetah 10K.7, tandis que sa sœur aînée Cheetah 15K.4 ne se souciait pas du mode dans lequel travailler sur les applications de bureau.

Essayer de comprendre davantage comment le sharding de la mémoire cache de ces disques durs sur les performances dans diverses applications et quels modes de segmentation (combien de segments de mémoire) sont les plus avantageux lors de l'exécution de certaines tâches, j'ai étudié l'effet du nombre de segments de mémoire cache sur les performances Disque Seagate Cheetah 15K.4 dans une large gamme de valeurs - de 4 à 128 segments (4, 8, 16, 32, 64 et 128). Les résultats de ces études sont présentés à votre attention dans cette partie de la revue. Permettez-moi de souligner que ces résultats sont intéressants non seulement pour ce modèle de disques (ou les disques SCSI de Seagate en général) - la segmentation de la mémoire cache et le choix du nombre de segments est l'une des principales directions d'optimisation des firmwares, notamment de bureau disques avec interface ATA, qui sont désormais également majoritairement équipés d'un buffer de 8 Mo. Par conséquent, les résultats de performances du lecteur décrits dans cet article dans diverses tâches en fonction du partitionnement de sa mémoire cache sont également pertinents pour l'industrie des lecteurs ATA de bureau. Et puisque la méthodologie de test a été décrite dans la première partie, passons directement aux résultats eux-mêmes.

Cependant, avant de passer à la discussion des résultats, examinons de plus près la structure et le fonctionnement des segments de mémoire cache du disque Seagate Cheetah 15K.4 afin de mieux comprendre ce qui est en jeu. Sur les huit mégaoctets de la mémoire cache réelle (c'est-à-dire pour les opérations de mise en cache), 7077 Ko sont disponibles ici (le reste est la zone de service). Cette zone est divisée en segments logiques (Page de sélection de mode 08h, octet 13), qui sont utilisés pour la lecture et l'écriture de données (pour effectuer des fonctions de lecture anticipée à partir de plateaux et d'écriture différée sur la surface du disque). Pour accéder aux données sur des plateaux magnétiques, les segments utilisent l'adressage logique des blocs d'entraînement. Les disques de cette série prennent en charge un maximum de 64 segments de cache, la longueur de chaque segment étant un nombre entier de secteurs de disque. La quantité de mémoire cache disponible est apparemment répartie également entre les segments, c'est-à-dire que s'il y a, disons, 32 segments, la taille de chaque segment est d'environ 220 Ko. Avec la segmentation dynamique (en mode PM = off), le nombre de segments peut être modifié automatiquement par le disque dur en fonction du flux de commandes de l'hôte.

Les applications de serveur et de bureau nécessitent diverses opérations mise en cache à partir des disques pour des performances optimales, il est donc difficile de fournir une configuration unique pour effectuer au mieux ces tâches. Selon Seagate, les applications "de bureau" nécessitent la configuration de la mémoire cache pour répondre rapidement aux demandes répétées un grand nombre petits segments de données sans délais pour la lecture anticipée des segments adjacents. En revanche, les tâches côté serveur nécessitent que le cache soit configuré pour fournir de grandes quantités de données séquentielles dans des requêtes non répétitives. Dans ce cas, la capacité de la mémoire cache à stocker plus de données à partir de segments contigus pendant la lecture anticipée est plus importante. Par conséquent, pour le mode bureau, le fabricant recommande d'utiliser 32 segments (dans les versions antérieures de Cheetah, 16 segments étaient utilisés), et pour le mode serveur, le nombre adaptatif de segments commence à partir de trois pour l'ensemble du cache, bien qu'il puisse augmenter pendant le fonctionnement. . Dans nos expériences sur l'effet du nombre de segments sur les performances dans diverses applications, nous nous limiterons à la plage de 4 segments à 64 segments, et à titre de vérification, nous « exécuterons » le disque également avec 128 segments installés dans le Programme SeaTools Enterprise (le programme n'informe pas que ce nombre de segments dans ce disque est invalide).

Résultats des tests physiques

Il ne sert à rien d'afficher des graphiques de vitesse de lecture linéaire avec différents nombres de segments de mémoire cache - ils sont identiques. Mais d'après la vitesse de l'interface Ultra320 SCSI mesurée par les tests, vous pouvez observer une image très curieuse : avec 64 segments, certains programmes commencent à déterminer de manière incorrecte la vitesse de l'interface, la réduisant de plus d'un ordre de grandeur.

En termes de temps d'accès moyen mesuré, les différences entre les différents nombres de segments de cache deviennent plus visibles - à mesure que la segmentation diminue, la moyenne mesurée sous Heure Windows l'accès en lecture croît légèrement, et des lectures significativement meilleures sont observées en mode PM = off, bien qu'il soit difficile d'affirmer que le nombre de segments est très petit ou au contraire très grand sur la base de ces données. Il est possible que le disque dans ce cas commence simplement à ignorer la prélecture lors de la lecture afin d'exclure des délais supplémentaires.

Vous pouvez essayer de juger de l'efficacité des algorithmes d'écriture différée du micrologiciel du disque et de la mise en cache des données écrites dans la mémoire tampon du lecteur en fonction de la baisse du temps d'accès en écriture moyen mesuré par le système d'exploitation par rapport à la lecture avec la mise en cache de réécriture activée du lecteur. (il a toujours été activé dans nos tests). Pour ce faire, nous utilisons généralement les résultats du test C"T H2benchW, mais cette fois nous allons compléter l'image avec un test dans le programme IOmeter, les motifs de lecture et d'écriture pour lesquels un accès aléatoire 100% utilisé par blocs de 512 octets avec une profondeur unitaire de la file d'attente des requêtes. (Bien sûr, vous ne devriez pas penser que le temps d'accès en écriture moyen dans les deux diagrammes ci-dessous reflète vraiment cela physique caractéristiques des lecteurs! Il s'agit simplement d'un certain paramètre mesuré par programme à l'aide d'un test, par lequel on peut juger de l'efficacité de la mise en cache de l'écriture dans le tampon du disque. Le temps d'accès en écriture réel moyen déclaré par le fabricant pour le Cheetah 15K.4 est de 4,0 + 2,0 = 6,0 ms). Soit dit en passant, anticipant les questions, je note que dans ce cas (c'est-à-dire lorsque l'écriture paresseuse est activée sur le disque), le lecteur informe l'hôte de la réussite de la commande d'écriture (état BON) dès qu'ils sont écrites dans la mémoire cache, et non directement sur le support magnétique... C'est la raison de la valeur plus faible du temps d'accès en écriture moyen mesuré de l'extérieur que pour le paramètre analogue en lecture.

Selon les résultats de ces tests, il existe une dépendance claire de l'efficacité de la mise en cache de l'écriture aléatoire de petits blocs de données sur le nombre de segments de mémoire cache - plus il y a de segments, mieux c'est. Avec quatre segments, l'efficacité chute fortement et le temps moyen d'accès en écriture monte quasiment aux valeurs de lecture. Et en "mode serveur" le nombre de segments dans ce cas est évidemment proche de 32. Les cas de 64 et "128" segments sont totalement identiques, ce qui confirme la limitation logicielle au niveau des 64 segments en partant du haut.

Fait intéressant, le test IOmeter dans les modèles les plus simples pour un accès aléatoire par blocs de 512 octets donne exactement les mêmes valeurs lors de l'écriture que le test C "T H2BenchW (avec une précision de littéralement des centièmes de milliseconde), tandis que lors de la lecture IOmeter il a montré un résultat légèrement surestimé dans toute la plage de segmentation - peut-être une différence de 0,1 à 0,19 ms avec d'autres tests pour le temps d'accès aléatoire en lisant pour des raisons "internes" à l'IOmeter (ou la taille du bloc est de 512 octets au lieu de 0 octet, comme cela est idéalement requis pour de telles mesures). Cependant, les résultats de lecture de l'IOmeter coïncident pratiquement avec ceux du test de disque du programme AIDA32.

Performances dans les applications

Passons aux benchmarks des performances de stockage dans les applications. Et tout d'abord, essayons de savoir dans quelle mesure les disques sont optimisés pour le multithreading. Pour ce faire, j'utilise traditionnellement des tests dans le programme NBench 2.4, où des fichiers de 100 Mo sont écrits et lus à partir du disque par plusieurs threads simultanés.

Ce diagramme nous permet de juger de l'efficacité des algorithmes d'écriture paresseuse multi-thread des disques durs dans des conditions réelles (et non synthétiques, comme c'était le cas dans le diagramme avec le temps d'accès moyen) lorsque le système d'exploitation travaille avec des fichiers. Le leadership des deux disques Maxtor SCSI lors de l'enregistrement dans plusieurs flux simultanés ne fait aucun doute, mais à Chita, nous observons déjà un certain optimum dans la région entre 8 et 16 segments, tandis qu'à des valeurs supérieures et inférieures, la vitesse du disque pour ces tâches diminue. . Pour le mode serveur, le nombre de segments est évidemment de 32 (avec une bonne précision :)), et les segments "128" sont en fait de 64.

Pour les lectures multithread, les disques Seagate s'améliorent nettement par rapport aux disques Maxtor. Quant à l'influence de la segmentation, alors, comme en enregistrement, on observe un certain optimum plus proche de 8 segments (lors de l'enregistrement, il était plus proche de 16 segments), et avec une segmentation très élevée (64), la vitesse du disque diminue significativement (comme en enregistrement) ... Il est gratifiant que le mode serveur "surveille le bazar" de l'hôte ici et modifie le sharding de 32 lors de l'écriture à ~ 8 lors de la lecture.

Voyons maintenant comment les disques se comportent dans les "anciens" mais toujours populaires tests Disk WinMark 99 du package WinBench 99. Permettez-moi de vous rappeler que nous effectuons ces tests non seulement pour le "début", mais aussi pour le "milieu" ( en termes de volume) des supports physiques pour les deux systèmes de fichiers, et les diagrammes montrent les résultats moyens. Bien entendu, ces tests ne sont pas des "profils" pour les disques SCSI, et nous présentons ici leurs résultats plutôt pour rendre hommage au test lui-même et à ceux qui sont habitués à juger la vitesse du disque par les tests WinBench 99. En guise de "consolation", notons que ces tests nous montreront avec un certain degré de certitude quelles sont les performances de ces disques d'entreprise lors de l'exécution de tâches plus typiques d'un ordinateur de bureau.

De toute évidence, il y a une segmentation optimale ici, et avec un petit nombre de segments, le disque semble inexpressif, et avec 32 segments - la meilleure voie(c'est peut-être la raison pour laquelle les développeurs de Seagate ont "déplacé" le paramètre par défaut du mode bureau de 16 à 32 segments). Cependant, pour les tâches en mode serveur dans les tâches bureautiques (Business), la segmentation n'est pas tout à fait optimale, tandis que pour les performances professionnelles (haut de gamme), la segmentation est plus qu'optimisée, surpassant sensiblement même la segmentation "constante" optimale. Apparemment, c'est lors de l'exécution du test qu'il change en fonction du flux de commandes et de ce fait, un gain de performance globale est obtenu.

Malheureusement, une telle optimisation "pendant le test" n'est pas observée pour les tests complexes de "piste" plus récents pour évaluer les performances "de bureau" des disques dans les packages PCMakr04 et C "T H2BenchW.

Sur les deux (ou plutôt sur 10 différentes) "pistes d'activité", l'intelligence du mode serveur est sensiblement inférieure à la segmentation constante optimale, qui pour PCmark04 est d'environ 8 segments, et pour H2benchW - 16 segments.

Pour ces deux tests, 4 segments de cache s'avèrent très indésirables, et 64 aussi, et il est difficile de dire où le Mode Serveur gravite le plus dans ce cas.

Contrairement à ceux-ci, bien sûr, tous les mêmes tests synthétiques (bien que très similaires à la réalité) - un test complètement "réel" de la vitesse des disques avec un fichier temporaire Programmes Adobe Photoshop. Ici, la situation est bien plus sombre - plus il y a de segments, mieux c'est ! Et le mode serveur l'a presque "attrapé", en utilisant 32 segments pour son travail (bien que 64 serait encore un peu mieux).

Benchmarks Intel Iometer

Passons aux tâches plus typiques des profils d'utilisation de lecteurs SCSI - le fonctionnement de divers serveurs (Base de données, serveur de fichiers, serveur Web) et d'un poste de travail (Workstation) selon les modèles correspondants dans Intel IOmeter version 2003.5.10.

Maxtor est le meilleur pour simuler un serveur de base de données, tandis que le Mode Serveur est le plus rentable pour Seagate, bien qu'en réalité ce dernier soit très proche de 32 segments persistants (environ 220 Ko chacun). Moins ou plus de segmentation est pire dans ce cas. Cependant, ce modèle est trop simple en termes de type de requêtes - voyons ce qui se passe pour des modèles plus complexes.

En imitant serveur de fichiers la segmentation adaptative est à nouveau en tête, bien que le retard de 16 segments constants soit négligeable (32 segments sont un peu moins bons ici, bien qu'ils soient également tout à fait suffisants). Avec une petite segmentation, il y a une détérioration dans une grande file d'attente de commandes, et avec une trop grande (64) toute file d'attente est généralement contre-indiquée - apparemment, dans ce cas, la taille des secteurs de cache s'avère trop petite (inférieure à 111 Ko, c'est-à-dire seulement 220 blocs sur le support) pour mettre en cache efficacement des quantités de données de taille raisonnable.

Enfin, pour un serveur Web, nous voyons une image encore plus amusante - avec une file d'attente de commandes NON-UN, le mode serveur est équivalent tout niveau de segmentation, sauf 64, bien qu'en simple c'est un peu mieux que tout le monde.

En raison de la moyenne géométrique des charges de serveur illustrées ci-dessus par les modèles et les files d'attente de requêtes (sans pondération), nous constatons que le sharding adaptatif est le meilleur pour de telles tâches, bien que 32 segments persistants soient légèrement en retard et que 16 segments aient également une bonne apparence globale. En général, le choix de Seagate est tout à fait compréhensible.

Quant au motif " poste de travail", le mode serveur ici est clairement le meilleur.

Et l'optimum pour une segmentation permanente est de 16 segments.

Maintenant - nos modèles pour IOmeter, qui sont plus proches des PC de bureau, bien que certainement indicatifs pour les périphériques de stockage d'entreprise, car dans les systèmes "profondément professionnels", les disques durs lisent et écrivent des fichiers volumineux et petits, et parfois copient des fichiers. Et puisque la nature des appels dans ces modèles dans ces modèles dans le test Iometer (à des adresses aléatoires dans l'ensemble du volume de disque) est plus typique pour les systèmes de classe serveur, l'importance de ces modèles pour les disques à l'étude est plus élevée.

La lecture de gros fichiers est encore meilleure pour le mode serveur, à l'exception d'un creux incompréhensible à QD = 4. Cependant, un petit nombre de gros segments est nettement préférable pour le disque sur ces opérations (ce qui, en principe, est prévisible et est en excellent accord avec les résultats de lecture de fichiers multi-thread, voir ci-dessus).

Sporadique enregistrement Les fichiers volumineux, en revanche, sont encore trop difficiles pour l'intelligence du mode serveur, et ici, une segmentation constante au niveau de 8 à 16 segments est plus avantageuse, comme avec l'enregistrement de fichiers multithread, voir ci-dessus. Séparément, nous notons que dans ces opérations, un large cache sharding est extrêmement nocif - au niveau de 64 segments. Cependant, il s'avère utile pour les opérations de lecture avec de petits fichiers avec une grande file d'attente de requêtes :

Je pense que c'est exactement ce que Server Mode utilise pour sélectionner le mode adaptatif - leurs graphiques sont très similaires.

Dans le même temps, lors de l'écriture de petits fichiers à des adresses aléatoires, 64 segments échouent à nouveau et le mode serveur est ici inférieur à une segmentation constante avec un niveau de 8 à 16 segments par cache, bien que le mode serveur essaie d'utiliser réglages optimaux(uniquement avec 32-64 segments sur la file d'attente 64 a échoué ;)).

La copie de fichiers volumineux est un échec évident du mode serveur ! Ici, le sharding avec le niveau 16 est clairement plus avantageux (c'est l'optimum, puisque 8 et 32 sont moins bons sur la file 4).

En ce qui concerne la copie de petits fichiers, les segments 8-16-32 sont pratiquement égaux ici, surpassant les 64 segments (assez curieusement), et le mode serveur est un peu "bizarre".

Sur la base des résultats de la moyenne géométrique des données pour la lecture, l'écriture et la copie aléatoires de fichiers volumineux et petits, nous constatons que le meilleur résultat en moyenne est donné par une segmentation constante avec un niveau de seulement 4 segments par cache (c'est-à-dire des tailles de segment sur 1,5 Mo!), Alors que 8 et 16 segments sont à peu près égaux et n'ont presque pas pris de retard sur 4 segments, mais 64 segments sont clairement contre-indiqués. En moyenne, le mode Adaptive Server n'a que peu cédé à une segmentation constante - une perte d'un pour cent peut difficilement être considérée comme notable.

Il reste à noter que lors de la simulation de la défragmentation, nous observons une égalité approximative de tous les niveaux de segmentation constante et un léger avantage du mode serveur (par le même 1%).

Et dans le modèle de lecture-écriture en continu en gros et petits blocs, il est légèrement plus rentable d'utiliser un petit nombre de segments, bien que là encore, les différences de vitesse des configurations de mémoire cache ici, assez curieusement, soient homéopathiques.

conclusions

Ayant réalisé dans la deuxième partie de notre revue une étude plus détaillée de l'influence du sharding de la mémoire cache sur les performances du disque Seagate Cheetah 15K.4 dans diverses tâches, je voudrais noter que les développeurs n'ont pas nommé les modes de mise en cache comme ils les appelaient pour une raison : en mode serveur, l'adaptation du sharding est souvent effectuée en mémoire cache pour la tâche en cours, et cela conduit parfois à de très bons résultats - en particulier lors de l'exécution de tâches "lourdes", y compris les modèles de serveur dans Intel IOmeter, et High-End Disk WinMark 99, et lecture aléatoire de petits blocs sur tout le disque... Dans le même temps, le choix du niveau de partitionnement de la mémoire cache en mode serveur s'avère souvent sous-optimal (et nécessite un travail supplémentaire pour améliorer les critères d'analyse du flux de commandes de l'hôte), puis Desktop Mode sort avec un sharding fixe au niveau de 8, 16 ou 32 segments par cache. De plus, selon le type de tâche, il est parfois plus rentable d'utiliser 16 et 32, et parfois - 8 ou seulement 4 segments de mémoire ! Ces derniers incluent des lectures et des écritures multithread (à la fois aléatoires et séquentielles), des tests de suivi comme PCMark04 et des tâches de streaming avec lecture et écriture simultanées. Bien que le "synthétique" pour l'accès en écriture aléatoire montre clairement que l'efficacité des écritures paresseuses (à des adresses arbitraires) diminue considérablement avec la diminution du nombre de segments. C'est-à-dire qu'il y a une lutte entre deux tendances - et c'est pourquoi, en moyenne, il est plus efficace d'utiliser 16 ou 32 segments par mémoire tampon de 8 Mo. En doublant la taille du tampon, on peut prédire qu'il est plus rentable de maintenir le nombre de segments au niveau de 16-32, mais en augmentant proportionnellement la capacité de chaque segment, les performances moyennes du lecteur peuvent augmenter considérablement. Apparemment, même inefficace maintenant dans la plupart des tâches, segmenter un cache avec 64 segments en doublant la taille du buffer peut s'avérer très utile, alors qu'utiliser 4 voire 8 segments dans ce cas deviendra inefficace. Cependant, ces conclusions dépendent également fortement des blocs que le système d'exploitation et les applications préfèrent fonctionner avec le lecteur, et des fichiers utilisés dans ce cas. Il est tout à fait possible que lorsque l'environnement change, le partitionnement optimal de la mémoire cache puisse changer dans un sens ou dans l'autre. Eh bien, nous souhaitons à Seagate de réussir dans l'optimisation de l'"intelligence" du mode serveur, qui, dans une certaine mesure, peut lisser cette "dépendance du système" et cette "dépendance des tâches" en apprenant à sélectionner la segmentation la plus optimale en fonction du flux de commandes de l'hôte dans la meilleure voie.

Le plus célèbre d'Alyosha Runet partage des informations choquantes.
http://www.exler.ru/blog/item/12406/?25

Je me souviens que dans les années 90 j'utilisais des contrôleurs dits de cache sur divers ordinateurs pour lesquels les performances étaient importantes lorsqu'on travaillait avec un disque dur : il s'agissait de cartes équipées de slots pour mémoire vive, dans laquelle une certaine quantité de cette mémoire a été insérée, et à l'aide de la carte, elle a été utilisée pour mettre en cache les données du disque dur. Une telle chose a considérablement accéléré le travail avec le disque dur, en particulier lors de l'utilisation de logiciels graphiques comme Corel Draw.

Surtout lorsque vous utilisez des packages graphiques comme Corel Draw. Exactement.
(crépitement des gabarits qui éclatent, un coup sourd de la tête sur la table)

Tout d'abord, définissons ce qu'est le cache disque matériel.
Dans l'ensemble, il s'agit d'un petit élément fonctionnel, "cousu" dans l'électronique du disque dur.

La mémoire cache agit comme un tampon pour stocker des données intermédiaires qui ont déjà été lues à partir du disque dur mais n'ont pas encore été soumis à un traitement ultérieur, et pour stocker les données auxquelles le système accède assez souvent... Le besoin de stockage direct est dû à la différence entre la vitesse de lecture des données du disque dur et le débit du système.

Si un fichier est fréquemment utilisé par le système, il sera alors placé dans le cache disque afin 1) de ne pas extraire le disque inutilement et 2) d'accélérer l'accès à ce fichier. D'une pierre deux coups.

De manière générale, ce n'est pas un fichier qui est placé dans le cache, mais tout contenu des blocs du disque dur qui est lu fréquemment. Par exemple, les données de service système de fichiers... Ou MBR. Ou 12 ko à partir du milieu d'un fichier de base de données d'un gigaoctet. Le disque ne fait pas la distinction entre son contenu, il s'en moque.
La situation avec le dossier est donnée pour plus de clarté.

Le problème est que dans les années 90, les disques étaient produits soit sans cache, soit ils étaient trop petits pour stocker les données nécessaires. Et ce problème a été vraiment résolu en utilisant des contrôleurs de cache.

Ensuite, les disques sont devenus sensiblement plus rapides, le système d'exploitation a commencé à faire une mise en cache décente et certains contrôleurs de cache se sont lentement éteints, d'autant plus qu'ils n'étaient pas bon marché, et que vous deviez toujours acheter de la mémoire pour eux.

En termes de vitesse relative, les disques durs n'étaient pas loin de la vitesse dans les années 90 : ils sont toujours la partie la plus lente d'un ordinateur. Mais les progrès technologiques ont permis de mettre suffisamment de mémoire cache dans les disques. Assez pour éliminer le besoin de contrôleurs de cache séparés.

De plus, dans le système d'exploitation Unix, la RAM "supplémentaire" (inutilisée) agit comme un cache supplémentaire. Soi-disant, cache disque logiciel... Il est parfois appelé "cache tampon", mais c'est quelque peu différent.

Windows l'a également, mais tous ses avantages sont entièrement compensés par une utilisation inadéquate du fichier d'échange.
L'état normal du système est que le contenu de la RAM est sur le disque (pagefile.sys) et que le contenu du disque est dans la RAM (cache du disque logiciel). Schizophrénie.

Il n'y a pas si longtemps, ces contrôleurs de cache ont commencé à revenir, mais déjà sous la forme de disques SSD. Tout d'abord, les disques dits hybrides sont apparus - des disques durs ordinaires, dans lesquels un petit SSD séparé (16-32 Go) était également intégré, qui était utilisé exclusivement pour la mise en cache.

L'auteur ne comprend pas que rien n'est allé nulle part, de sorte qu'il peut maintenant revenir avec des feux d'artifice et des fanfares.
Et que les disques hybrides sont un stratagème marketing (pour une raison quelconque, un SSD de 16 Go a été inséré dans une vis ordinaire, et même avec des fonctionnalités réduites).
Et quoi de plus logique, plus simple et plus correct d'utiliser deux vis : un SSD rapide pour le système et une vis ordinaire pour les données. Pour une cache de 16 concerts, c'est un non-sens enchanteur (avec une mise en garde : au ce moment ).

Et maintenant, ils ont commencé à produire des SSD séparés, qui sont également utilisés spécifiquement pour la mise en cache.

Lire - SSD standard avec le lettrage rouge "Cache Only".

Aujourd'hui, le stockage commun de l'information est magnétique Disque dur... Il dispose d'une certaine quantité de mémoire dédiée au stockage des données de base. Il dispose également d'une mémoire tampon dont le but est de stocker des données intermédiaires. Les professionnels appellent le tampon du disque dur le terme « mémoire cache » ou simplement « cache ». Voyons pourquoi le tampon HDD est nécessaire, ce qu'il affecte et quelle est sa taille.

Le tampon du disque dur aide système opérateur stocker temporairement les données qui ont été lues à partir de la mémoire principale du disque dur, mais qui n'ont pas été transférées pour traitement. Le besoin d'un stockage de transit est dû au fait que la vitesse de lecture des informations du disque dur et débit Le système d'exploitation varie considérablement. Par conséquent, l'ordinateur doit stocker temporairement des données dans le "cache" et les utiliser ensuite uniquement aux fins prévues.

Le tampon du disque dur lui-même n'est pas un secteur séparé, comme le pensent les utilisateurs d'ordinateurs incompétents. Il s'agit d'une puce mémoire spéciale située sur la carte HDD interne. De tels microcircuits sont capables de fonctionner beaucoup plus rapidement que le lecteur lui-même. En conséquence, ils provoquent une augmentation (de plusieurs pour cent) des performances d'un ordinateur qui est observée pendant le fonctionnement.

Il convient de noter que la taille de la "mémoire cache" dépend du modèle de disque spécifique. Auparavant, il était d'environ 8 mégaoctets et ce chiffre était considéré comme satisfaisant. Cependant, avec l'avancement de la technologie, les fabricants ont pu produire des puces avec plus de mémoire. Par conséquent, la plupart des disques durs modernes ont un tampon dont la taille varie de 32 à 128 mégaoctets. Bien sûr, la plus grande "cache" est installée dans des modèles coûteux.

Comment la mémoire tampon du disque dur affecte les performances

Voyons maintenant pourquoi la taille de la mémoire tampon du disque dur affecte les performances de l'ordinateur. Théoriquement, plus il y aura d'informations dans la "mémoire cache", moins le système d'exploitation accédera au disque dur. Cela est particulièrement vrai pour un scénario de travail lorsqu'un utilisateur potentiel traite un grand nombre de petits fichiers. Ils se déplacent simplement vers la mémoire tampon du disque dur et y attendent leur tour.

Cependant, si un PC est utilisé pour traiter des fichiers volumineux, alors le "cache" perd de sa pertinence. Après tout, les informations ne peuvent pas tenir sur des microcircuits dont le volume est petit. En conséquence, l'utilisateur ne remarquera pas d'augmentation des performances de l'ordinateur, car le tampon sera à peine utilisé. Cela se produit dans les cas où des programmes d'édition de fichiers vidéo, etc. seront lancés dans le système d'exploitation.

Ainsi, lors de l'achat d'un nouveau disque dur, il est recommandé de ne faire attention à la taille du "cache" que si vous envisagez de traiter en permanence le traitement de petits fichiers. Ensuite, vous remarquerez vraiment une augmentation de la productivité de votre ordinateur personnel... Et si le PC sera utilisé pour des tâches quotidiennes ordinaires ou pour le traitement de gros fichiers, alors vous ne pourrez attacher aucune importance au presse-papiers.

Une forme très importante et spécifique de mise en mémoire tampon est mise en cache ... Ce terme fait référence à l'utilisation d'une mémoire relativement petite mais rapide afin de réduire le nombre d'appels à une mémoire plus lente et plus grande.

L'idée derrière la mise en cache est basée sur ce qu'on appelle lien hypothèse de localité ... Cette hypothèse est la suivante. Si, à un moment donné, il y avait un accès à un certain élément de données, dans un proche avenir, il est possible avec une forte probabilité de s'attendre à une répétition d'appels vers les mêmes données ou vers des zones de données voisines. Bien entendu, la localité des liens ne peut être considérée comme une loi, mais la pratique montre que cette hypothèse est justifiée pour la grande majorité des programmes.

En moderne systèmes informatiques plusieurs niveaux de mise en cache peuvent être utilisés. V ce cours le cache matériel du processeur n'est pas pris en compte, ce qui permet de réduire le nombre d'accès à la mémoire principale du fait de l'utilisation de registres rapides. La mise en cache logicielle des périphériques à accès aléatoire (lecteurs de disque) est plus directement liée au fonctionnement du système d'exploitation. Dans ce cas, l'hypothèse sur la localité des liens peut être reformulée plus spécifiquement : si le programme lit ou écrit des données à partir d'un certain bloc du disque, il est très probable que dans un avenir proche, il y aura plus d'opérations de lecture ou d'écriture de données du même bloc.

Le rôle de la mémoire haute vitesse (cache) est ici un tableau de tampons situés dans la mémoire système. Chaque tampon est constitué d'un en-tête et d'un bloc de données correspondant en taille à un bloc (secteur) du disque. L'en-tête du tampon contient l'adresse du bloc disque, dont une copie est actuellement contenue dans le tampon, et plusieurs drapeaux caractérisant l'état du tampon.

Lorsque le système reçoit une demande de lecture ou d'écriture d'un bloc spécifique de données de disque, il vérifie d'abord si une copie de ce bloc se trouve actuellement dans l'un des tampons de cache. Cela nécessite une recherche dans les en-têtes de tampon. Si le bloc est trouvé dans le cache, le disque ne sera pas accessible. Au lieu de cela, les données sont lues à partir du tampon ou écrites dans le tampon, respectivement. Dans le cas de l'écriture de données, il convient également de noter dans l'en-tête du tampon à l'aide d'un drapeau spécial que le tampon est devenu " sale ", C'est à dire. son contenu ne correspond pas aux données sur le disque.

Si le bloc de disque requis n'est pas trouvé dans le cache, un tampon doit lui être alloué. Le problème est que le nombre total de tampons de cache est limité. Pour donner l'un d'eux pour le bloc requis, l'un des blocs qui y étaient stockés doit être "déplacé" du cache. Dans ce cas, si le bloc préempté est « sale », alors il doit être « nettoyé », c'est-à-dire écrit sur le disque. Lorsqu'un bloc "propre" est préempté, aucune opération sur le disque n'est nécessaire.

Quel bloc du cache choisir pour l'expulsion afin de réduire le nombre total d'accès au disque ? Il s'agit d'un problème extrêmement important, et s'il est résolu de manière incorrecte, l'ensemble du fonctionnement du système peut ralentir en raison d'accès constants au disque.

Il existe une solution théoriquement optimale à ce problème, qui est la suivante. Le nombre d'accès au disque sera minime si à chaque fois vous sélectionnez pour l'expulsion le bloc de données qui ne sera pas accédé le plus longtemps à l'avenir. Malheureusement, il est impossible d'utiliser cette règle en pratique, car la séquence d'accès aux blocs de disque est imprévisible. Ce résultat théorique n'est utile que comme idéal inaccessible auquel comparer les résultats de l'application d'algorithmes de sélection plus réalistes.

Parmi les algorithmes utilisés en pratique, le meilleur est celui LRU (Le moins récemment utilisé, traduit vaguement "pas utilisé depuis longtemps"). Il consiste en ce qui suit : le bloc qui n'a pas été accédé depuis le plus longtemps doit être choisi pour le déplacement. Ici, le principe de localité des liens est utilisé : puisqu'il n'y a pas eu d'appels depuis longtemps, alors, probablement, ils ne le seront pas dans un avenir proche.

Comment la sélection de blocs basée sur la règle LRU est-elle mise en œuvre dans la pratique ? La solution évidente consiste à enregistrer l'heure actuelle dans son en-tête à chaque accès au tampon, et lorsque vous choisissez de préempter, il est trop lourd et lent de rechercher le premier enregistrement. Il y a une bien meilleure opportunité.

Tous les tampons de cache sont liés dans une liste linéaire. L'en-tête de chaque tampon stocke une référence au tampon suivant dans l'ordre de la liste (en fait, l'index de ce tampon est stocké dans le tableau de tampons). Chaque fois qu'un bloc de données est accédé en lecture ou en écriture, le tampon correspondant est également déplacé à la fin de la liste. Cela ne signifie pas déplacer les données stockées dans le tampon, seuls quelques liens dans les en-têtes changent.

En raison du déplacement constant des blocs utilisés à la fin de la liste des tampons, cette liste est triée par ordre croissant du dernier temps d'accès. Au début de la liste se trouve le tampon dont les données n'ont pas été consultées depuis le plus longtemps. Il est ce dont nous avons besoin en tant que candidat à la répression.

En figue. 2-3 montre un tableau de tampons liés dans une liste.

Maintenant sur les tampons sales. Dans quels cas doivent-ils être "nettoyés", c'est-à-dire écrire un bloc de données du tampon de cache sur le disque ? Il existe trois cas de ce type.

· Sélection d'un bloc pour l'expulsion de la cache.

· Fermeture du fichier auquel appartiennent les blocs modifiés. Il est généralement admis que lorsqu'un fichier est fermé, il doit être enregistré sur le disque.

· Opération d'effacement forcé de tous les tampons ou uniquement des tampons liés à un fichier spécifique. Une opération similaire peut être effectuée pour améliorer la fiabilité du stockage des données, comme une assurance contre d'éventuelles pannes. Sous UNIX OS, par exemple, le vidage de tous les tampons est traditionnellement effectué toutes les 30 secondes.

Il faut reconnaître que la mise en cache des opérations d'écriture sur le disque, par opposition à la mise en cache des lectures, pose toujours un certain risque de perte de données. En cas de panne accidentelle du système, panne de courant, etc. il se peut que une information important qui aurait dû être écrit sur le disque est resté bloqué dans des tampons de cache sales et a donc été perdu. C'est un prix inévitable à payer pour une augmentation significative des performances du système. Les programmes qui nécessitent une grande fiabilité de travail avec les données (par exemple, les programmes bancaires) écrivent généralement les données directement sur le disque. Dans ce cas, soit le cache n'est pas utilisé du tout, soit une copie des données est écrite dans le tampon de cache, ce qui peut être utile pour les opérations de lecture ultérieures.

Le goulot d'étranglement de la mise en cache disque est de trouver le bloc de données requis dans le cache. Comme décrit ci-dessus, le système examine les en-têtes de tampon pour cela. Si le cache se compose de plusieurs centaines de tampons, le temps de recherche sera perceptible. L'une des astuces possibles pour l'accélération de la recherche UNIX est illustrée à la Fig. 2-4.

Sous UNIX, chaque tampon de cache peut apparaître simultanément dans deux listes linéaires. L'une d'entre elles, appelée "liste libre", est la liste LRU familière utilisée pour déterminer le bloc à expulser. Libre ne veut pas dire vide ; dans ce cas, ce mot signifie un bloc qui n'est pas actuellement occupé par une opération de lecture/écriture effectuée par un processus. Une autre liste est appelée "chaîne de hachage" et est utilisée pour accélérer la recherche du bloc souhaité.

Lors de l'écriture dans le tampon de données correspondant à un certain bloc du disque, le numéro de la chaîne de hachage, dans laquelle ce tampon sera placé, est déterminé comme le reste de la division du numéro de bloc par N - le nombre de chaînes de hachage. Pour plus de clarté, la figure a adopté la valeur N = 10. Ainsi, les blocs portant les numéros 120, 40, 90 tombent dans la chaîne 0, les blocs 91, 1, 71 - dans la chaîne 1, etc. Lorsque le système recherche dans le cache un bloc avec un certain nombre, tout d'abord, par le numéro de bloc, il détermine dans quelle chaîne de hachage ce bloc doit se trouver. Si le bloc n'est pas dans cette chaîne, alors il n'est pas du tout dans le cache. De cette façon, il est possible de raccourcir la recherche d'un facteur N au mieux (c'est-à-dire si toutes les chaînes sont de même longueur).

Déplacer un tampon d'une chaîne de hachage à une autre, comme le déplacer à la fin de la liste libre, ne nécessite pas de réécrire l'intégralité du bloc de données en mémoire et s'effectue en modifiant les références dans les en-têtes de bloc.

Une autre caractéristique de la mise en cache sur disque UNIX est que lorsque des tampons sales sont trouvés au début de la liste libre, le système commence à les vider, mais n'attend pas la fin de ces processus, mais sélectionne le premier bloc propre dans la liste pour l'expulsion. Lorsque le vidage est terminé, les blocs sont renvoyés en haut de la liste libre, restant les premiers candidats à la préemption.