Pourquoi mon NVMe est-il plus lent qu'un SSD ?

Dans cet article, nous examinerons certaines des nuances du sous-système d'E/S et leur impact sur les performances.

Il y a quelques semaines, je me suis demandé pourquoi NVMe sur un serveur est plus lent que SATA sur un autre. J'ai regardé les caractéristiques des serveurs et j'ai réalisé que c'était une question piège : NVMe appartenait au segment des utilisateurs et SSD était du segment des serveurs.

Il n’est évidemment pas correct de comparer des produits de différents segments dans différents environnements, mais il ne s’agit pas d’une réponse technique exhaustive. Nous étudierons les bases, mènerons des expériences et donnerons une réponse à la question posée.

Qu'est-ce que fsync et où est-il utilisé

Pour accélérer le travail avec les lecteurs, les données sont mises en mémoire tampon, c'est-à-dire stockées dans une mémoire volatile jusqu'à ce qu'une opportunité pratique se présente pour enregistrer le contenu du tampon sur le lecteur. Les critères d'opportunité sont déterminés par le système d'exploitation et les caractéristiques du lecteur. En cas de panne de courant, toutes les données du tampon seront perdues.

Il existe un certain nombre de tâches dans lesquelles vous devez vous assurer que les modifications apportées au fichier sont écrites sur le lecteur et ne se trouvent pas dans un tampon intermédiaire. Cette assurance peut être obtenue en utilisant l’appel système fsync conforme à POSIX. L'appel fsync force une écriture du tampon vers le lecteur.

Montrons l'effet des tampons avec un exemple artificiel sous la forme d'un court programme C.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

Les commentaires expliquent bien la séquence d'actions dans le programme. Le texte « la réponse à la question principale de la vie, de l'univers et tout ça » sera tamponné par le système d'exploitation, et si vous redémarrez le serveur en appuyant sur le bouton Reset pendant les « calculs », le fichier sera vide. Dans notre exemple, la perte de texte n'est pas un problème, donc fsync n'est pas nécessaire. Les bases de données ne partagent pas cet optimisme.

Les bases de données sont des programmes complexes qui fonctionnent avec de nombreux fichiers en même temps. Ils veulent donc être sûrs que les données qu'ils écrivent seront stockées sur le lecteur, car la cohérence des données dans la base de données en dépend. Les bases de données sont conçues pour enregistrer toutes les transactions terminées et être prêtes à tout moment en cas de panne de courant. Ce comportement vous oblige à utiliser fsync constamment et en grande quantité.

Qu'est-ce qui affecte l'utilisation fréquente de fsync

Avec des E/S normales, le système d'exploitation tente d'optimiser la communication entre les disques, car les disques externes sont les plus lents de la hiérarchie de la mémoire. Par conséquent, le système d'exploitation essaie d'écrire autant de données que possible en un seul accès au lecteur.

Montrons l'impact de l'utilisation de fsync avec un exemple spécifique. Nous avons les SSD suivants comme sujets de test :

• Intel® DC SSD S4500 480 Go, connecté via SATA 3.2, 6 Gb/s ;
• Samsung 970 EVO Plus 500 Go, connecté via PCIe 3.0 x4, ~ 31 Gbit/s.

Les tests sont effectués sur un Intel® Xeon® W-2255 exécutant Ubuntu 20.04. Pour tester les disques, sysbench 1.0.18 est utilisé. Les disques ont une seule partition formatée en ext4. Préparer le test consiste à créer des fichiers de 100 Go :

sysbench --test=fileio --file-total-size=100G prepare

Tests en cours :

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Les résultats des tests sont présentés dans le tableau.

test
Intel® S4500
Samsung 970 EVO+

Lire sans fsync, MiB/s
5734.89
9028.86

Écrire sans fsync, MiB/s
3823.26
6019.24

Lecture avec fsync, MiB/s
37.76
3.27

Enregistrement avec fsync, MiB/s
25.17
2.18

Il est facile de voir que NVMe du segment client mène en toute confiance lorsque le système d'exploitation lui-même décide comment travailler avec les disques et perd lorsque fsync est utilisé. Cela soulève deux questions :

1. Pourquoi la vitesse de lecture dépasse-t-elle la bande passante physique du lien lors du test sans fsync ?
2. Pourquoi un SSD de segment de serveur est-il plus efficace pour gérer un grand nombre de requêtes fsync ?

La réponse à la première question est simple : sysbench génère des fichiers remplis de zéros. Ainsi, le test a été réalisé sur 100 gigaoctets de zéros. Étant donné que les données sont très uniformes et prévisibles, diverses optimisations du système d'exploitation entrent en jeu et accélèrent considérablement l'exécution.

Si vous remettez en question tous les résultats de sysbench, vous pouvez utiliser fio.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

test
Intel® S4500
Samsung 970 EVO+

Lire sans fsync, MiB/s
45.5
178

Écrire sans fsync, MiB/s
30.4
119

Lecture avec fsync, MiB/s
32.6
20.9

Enregistrement avec fsync, MiB/s
21.7
13.9

La tendance à la baisse des performances dans NVMe lors de l'utilisation de fsync est clairement visible. Vous pouvez passer à la deuxième question.

Optimisation ou bluff

Plus tôt, nous avons dit que les données sont stockées dans un tampon, mais nous n'avons pas précisé dans lequel, car ce n'était pas important. Même maintenant, nous n'entrerons pas dans les subtilités des systèmes d'exploitation et distinguerons deux types généraux de tampons :

• programme;
• Matériel.

Le tampon logiciel fait référence aux tampons présents dans le système d'exploitation et le tampon matériel fait référence à la mémoire volatile du contrôleur de disque. L'appel système fsync envoie une commande au lecteur pour écrire les données de son tampon vers le stockage principal, mais il n'a aucun moyen de contrôler l'exécution correcte de la commande.

Puisque le SSD est plus performant, deux hypothèses peuvent être faites :

• le disque est conçu pour un chargement d'un plan similaire ;
• le disque « bluffe » et ignore la commande.

Un comportement malhonnête du lecteur peut être remarqué si vous effectuez un test avec une panne de courant. Vous pouvez vérifier cela avec un script. diskchecker.plqui était établi l'année 2005.

Ce script nécessite deux machines physiques : « serveur » et « client ». Le client écrit une petite quantité de données sur le lecteur testé, appelle fsync et envoie au serveur des informations sur ce qui a été écrit.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Après avoir exécuté le script, il est nécessaire de mettre le « client » hors tension et de ne pas remettre le courant pendant plusieurs minutes. Il est important de déconnecter le sujet de test de l'électricité et de ne pas simplement effectuer un arrêt brutal. Après un certain temps, le serveur peut être connecté et chargé dans le système d'exploitation. Après avoir démarré le système d'exploitation, vous devez recommencer diskchecker.pl, mais avec un argument vérifier.

./diskchecker.pl -s <server[:port]> verify <file>

A la fin du contrôle, vous verrez le nombre d'erreurs. S'ils sont 0, alors le disque a réussi le test. Pour exclure un concours de circonstances réussi pour le disque, l'expérience peut être répétée plusieurs fois.

Notre S4500 n'a montré aucune erreur de perte de puissance, ce qui signifie qu'il est prêt pour des charges avec de nombreux appels fsync.

Conclusion

Lorsque vous choisissez des disques ou des configurations entières prêtes à l'emploi, vous devez garder à l'esprit les spécificités des tâches à résoudre. À première vue, il semble évident que le NVMe, c'est-à-dire un SSD doté d'une interface PCIe, est plus rapide qu'un SSD SATA « classique ». Cependant, comme nous l'avons compris aujourd'hui, dans des conditions spécifiques et pour certaines tâches, cela peut ne pas être le cas.

Comment tester les composants du serveur lors de la location auprès d'un fournisseur IaaS ?
On vous attend dans les commentaires.

Source: habr.com