1 votes

Pourquoi `hdparm -t` prend-il autant de temps pour produire des résultats précis sur mon instance EC2 ?

Je suis en train de profiler un programme de traitement de données que j'ai écrit et je veux comprendre le débit théorique de la machine sur laquelle je me trouve. Plus précisément, je veux mesurer la vitesse de lecture de disque que mon instance EC2 g4dn fournit à mon application. Cette instance particulière a un lecteur NVMe éphémère, ce qui est ce que je veux évaluer.

Je remarque qu'il faut pas mal de passages de hdparm jusqu'à ce que le débit qu'il signale cesse d'augmenter. Ma question est la suivante : pourquoi hdparm faut-il plusieurs passages pour obtenir un débit de lecture complet ? Qu'y a-t-il dans le noyau Linux, le pilote de disque, le contrôleur de disque ou le matériel réel qui nécessite plusieurs exécutions de l'algorithme de lecture ? hdparm pour obtenir des résultats précis ?

Je sais que les pages de manuel disent de l'exécuter plusieurs fois, mais d'après mon expérience, il faut beaucoup plus que les 3 fois recommandées pour que le débit soit maximal.

-t     Perform timings of device reads for benchmark and
       comparison purposes.  For meaningful results, this
       operation should be repeated 2-3 times on an otherwise
       inactive system (no other active processes) with at least
       a couple of megabytes of free memory.  This displays the
       speed of reading through the buffer cache to the disk
       without any prior caching of data.  This measurement is an
       indication of how fast the drive can sustain sequential
       data reads under Linux, without any filesystem overhead.
       To ensure accurate measurements, the buffer cache is
       flushed during the processing of -t using the BLKFLSBUF
       ioctl.

J'exécute ce qui suit pour recueillir la vitesse de lecture :

#!/usr/bin/env bash
while true; do
   sudo hdparm -t /dev/nvme0n1p1;
   sleep 1;
done

et obtenir le résultat suivant :

$ while true; do sudo hdparm -t /dev/nvme0n1p1; sleep 1; done

/dev/nvme0n1p1:
 Timing buffered disk reads: 470 MB in  3.09 seconds = 152.30 MB/sec

/dev/nvme0n1p1:
 Timing buffered disk reads: 490 MB in  3.10 seconds = 158.21 MB/sec

/dev/nvme0n1p1:
 Timing buffered disk reads: 526 MB in  3.02 seconds = 174.43 MB/sec

Il faut une vingtaine d'exécutions avant qu'il ne se stabilise autour de 330 Mo/sec.

Notez que j'utilise une AMI qui possède les bons pilotes NVMe.

1voto

cade Points 121

Il s'avère que les lecteurs nvme locaux disponibles par défaut sur certaines instances EC2 ne sont pas prêts à être utilisés, et que le périphérique nvme "prêt à l'emploi" est en fait un volume EBS monté comme un lecteur nvme. Ceci explique le faible débit (300MB/s) et le lent temps de chauffe (20 exécutions).

Pour référence future, j'ai obtenu des vitesses de lecture séquentielles de 1,7 Go/s à partir de la première série d'essais de l'ordinateur. hdparm quand j'ai formaté et monté mon réel nvme conduit. Ils seront visibles à partir de lsblk .

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X