La profondeur de file d'attente et la taille des blocs modifient la latence de lecture aléatoire car elles contrôlent la quantité de travail soumise à la fois et la quantité de données transférées par chaque opération. Un test à faible file d'attente et petits blocs mesure la rapidité d'exécution d'une requête, tandis qu'un test à file d'attente élevée mesure la quantité de travail parallèle que le chemin de stockage peut soutenir.
Le même NAS peut donc afficher des IOPS 4K QD1 modestes, des IOPS 4K QD32 beaucoup plus élevés et un débit important avec de gros blocs sans contradiction. Chaque résultat décrit une charge de travail différente, et le chiffre de benchmark le plus rapide peut être le moins représentatif d'une base de données interactive, d'une bibliothèque photo ou d'une application conteneurisée.
Que contrôlent réellement la profondeur de file d'attente et la taille des blocs ?
La profondeur de file d'attente est le nombre d'opérations d'E/S en cours à un niveau mesuré. la profondeur de file d'attente contrôle les requêtes d'E/S en cours, tandis que la taille des blocs définit la charge utile transférée par chaque requête.
Un test avec QD1 soumet une opération et attend sa fin avant d'en lancer une autre. Un test QD32 permet à plusieurs opérations d'attendre ou de s'exécuter en parallèle, offrant au disque, au contrôleur, à l'ensemble et au réseau plus d'opportunités de superposer le travail.
Ces valeurs existent à plusieurs niveaux. La file d'attente du thread de benchmark, la file d'attente des blocs du système d'exploitation, le HBA, la file d'attente de soumission NVMe, les crédits du protocole NAS et les disques individuels peuvent tous voir des nombres de requêtes en cours différents.
Pourquoi QD1 expose-t-il le temps de service du stockage ?
Avec une seule requête en cours, l'opération suivante ne peut pas se cacher derrière un travail parallèle, donc QD1 expose le temps de service d'une seule requête. Le résultat inclut le temps de service du dispositif ainsi que les surcharges du protocole, du système de fichiers, du contrôleur, du réseau et du client.
QD1 est donc utile pour les tâches orientées utilisateur qui émettent une ou quelques lectures dépendantes : ouverture des métadonnées, chargement d'une page de base de données, lecture d'une miniature ou suivi d'un pointeur vers la structure suivante.
Ce n'est pas un test de capacité complet. Un SSD moderne ou un ensemble en bande peut supporter beaucoup plus de travail parallèle que ce que fournit QD1, donc le résultat peut sous-estimer le nombre maximal d'IOPS agrégés tout en représentant avec précision la réactivité d'une seule requête.
Pourquoi une profondeur de file d'attente plus élevée peut-elle augmenter à la fois les IOPS et la latence ?
Plus de travail en attente peut maintenir les canaux de stockage occupés et augmenter les opérations complétées par seconde, mais une profondeur de file d'attente plus élevée peut augmenter simultanément les IOPS et la latence. Chaque requête peut passer plus de temps à attendre avant le service.
Le benchmark rapporte plus de complétions totales parce que le système superpose le travail, pas parce que chaque requête est devenue plus rapide. Une fois que le périphérique ou le groupe atteint sa capacité de service, une profondeur de file d'attente supplémentaire allonge surtout la file d'attente.
C'est pourquoi les IOPS à haute profondeur de file d'attente et la faible latence interactive sont des objectifs distincts. Un serveur de sauvegarde ou un travail analytique peut bénéficier d'un parallélisme profond, tandis qu'une requête d'application se soucie du temps d'achèvement d'une lecture critique.
Comment la taille des blocs modifie-t-elle les IOPS, le débit et le temps d'attente ?
Les IOPS comptent les opérations sans décrire combien d'octets chaque opération déplace. la taille des blocs change l'équilibre entre IOPS et débit. Mille lectures 4K déplacent bien moins de données que mille lectures 128K.
Les petits blocs mettent en avant le surcoût par opération et sont courants pour les pages de base de données, les métadonnées et l'état des applications. Les blocs plus grands améliorent l'efficacité du transfert et le débit mais occupent le périphérique, le réseau et le contrôleur pour plus d'octets par requête.
Un bloc plus grand peut réduire le nombre d'IOPS nécessaires pour une bande passante donnée tout en augmentant le temps de service de chaque opération. Les applications mixtes ont besoin des deux dimensions car un NAS peut servir de petites lectures de métadonnées à côté de gros transferts médias ou de sauvegarde.
Pourquoi le cache et le parallélisme donnent-ils des résultats meilleurs que ce que ressentent les applications ?
Les résultats du benchmark peuvent être dominés par la RAM, le cache du contrôleur, le cache client ou l'accès répété à un petit ensemble de travail. le cache et la concurrence peuvent masquer la latence des lectures froides.
Les travailleurs de benchmark parallèles peuvent également répartir les requêtes plus efficacement entre les disques, les canaux NAND, les cœurs CPU, les canaux SMB ou les files d'attente NVMe qu'un seul thread d'application. Le test prouve une montée en charge globale, pas qu'une seule lecture froide d'application bénéficie du même avantage.
Utilisez un ensemble de données plus grand que les caches pertinents lors du test du support de stockage, et effectuez des tests séparés avec cache chaud lorsque la mise en cache applicative fait partie de la conception réelle. Mélanger les deux produit un chiffre dont le goulot d'étranglement est incertain.
Comment un test de lecture aléatoire NAS domestique doit-il correspondre aux charges de travail réelles ?
Un benchmark utile varie les dimensions que les applications réelles varient. les tests réalistes doivent correspondre à la profondeur de file d'attente de la charge de travail plutôt que de rapporter une seule valeur maximale d'IOPS.
Testez QD1 et quelques profondeurs modérées, incluez des lectures petites 4K ou 8K et les blocs plus grands utilisés par les outils médias ou de sauvegarde, et enregistrez la latence moyenne ainsi que p95, p99 et maximale. Gardez le client, le protocole, le chiffrement et l'ensemble de données constants lors de la comparaison des changements de stockage.
Effectuez le test de lecture aléatoire à la fois seul et à côté des charges de travail en arrière-plan qui partagent réellement le NAS. Un benchmark isolé peut mesurer proprement le chemin de stockage, mais il ne peut pas révéler la latence que les utilisateurs subissent lors d'applications, sauvegardes, indexations ou contentions de parité.
| Forme du test | Ce qu'il met en avant | Mauvaise interprétation courante |
|---|---|---|
| 4K QD1 | Temps de réponse d'une seule petite lecture | Supposer qu'il montre les IOPS maximales de l'appareil |
| 4K haute QD | Capacité d'E/S petites parallèles | Supposer que chaque requête a une faible latence |
| 128K faible QD | Efficacité des grandes requêtes | Comparer directement ses IOPS avec du 4K |
| Lectures aléatoires en cache | Performance de la mémoire et du chemin logiciel | Attribuer le résultat au support de stockage |
FAQ
Une profondeur de file d'attente plus élevée est-elle toujours meilleure ?
Non. Cela peut améliorer le débit global jusqu'à saturation du chemin de stockage, mais les requêtes peuvent attendre plus longtemps et la latence interactive peut s'aggraver.
Pourquoi les chiffres de lecture aléatoire 4K sont-ils couramment rapportés ?
Les petits blocs ressemblent aux pages de base de données, aux métadonnées et à l'état des applications, et ils exposent les frais généraux par opération que les transferts séquentiels importants cachent.
Un benchmark NAS doit-il utiliser QD32 ?
Seulement lorsque la charge de travail attendue peut générer autant d'E/S parallèles. Incluez QD1 et des profondeurs modérées pour les applications de serveur domestique interactives.
La latence réseau peut-elle dominer un test de lecture aléatoire ?
Oui. Les allers-retours SMB ou NFS, le traitement côté client, le chiffrement et les files d'attente des commutateurs peuvent dépasser le temps de service de l'appareil, surtout à faible profondeur de file d'attente.
Conclusion finale
La profondeur de la file d'attente détermine combien d'E/S peuvent attendre ou s'exécuter en parallèle, tandis que la taille des blocs détermine la quantité de données déplacées par chaque opération. Une profondeur de file d'attente plus élevée peut augmenter le nombre total d'IOPS tout en augmentant la latence par requête, et des blocs plus grands peuvent améliorer le débit tout en réduisant le nombre d'opérations. Un benchmark NAS domestique utile correspond à la concurrence réelle, aux tailles de données, à l'état du cache et aux exigences de latence de queue au lieu de sélectionner le plus grand chiffre en titre.
Centre Tech & IA
Plus à lire

État d’exécution vs état persistant dans Home Assistant : que doit survivre à un redémarrage ?
Home Assistant ne conserve pas chaque valeur en temps réel ; la configuration, les registres, certains états restaurés, l’historique et les données de déploiement...

Comment Home Assistant authentifie-t-il les sessions locales et distantes ?
Les sessions Home Assistant locales et distantes utilisent le même modèle d’identité côté serveur ; l’accès à distance modifie le chemin et la limite...

Pourquoi les requêtes d’historique de Home Assistant peuvent-elles ralentir à mesure que les données de l’enregistreur augmentent ?
L’augmentation du nombre d’enregistrements peut accroître le coût des requêtes d’historique lorsque la plage demandée concerne davantage de lignes, que les défauts de cache...

