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

Dans cet article, nous examinerons certains aspects de la sous-système d'entrée-sortie et leur impact sur les performances.

Il y a quelques semaines, je me suis heurté à la question de savoir pourquoi un NVMe sur un serveur était plus lent qu'un SATA sur un autre. J'ai consulté les caractéristiques des serveurs et j'ai réalisé que c'était une question piégée : le NVMe provenait du segment grand public, tandis que le SSD provenait du segment serveur.

Il est évident qu'il est incorrect de comparer des produits provenant de segments différents dans des environnements différents, mais ce n'est pas une réponse technique exhaustive. Nous allons examiner les bases, réaliser des expériences et répondre à la question posée.

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

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

Il existe plusieurs tâches pour lesquelles il est nécessaire de s'assurer que les modifications d'un fichier sont enregistrées sur le disque et non dans un tampon intermédiaire. Cette certitude peut être obtenue en utilisant l'appel système fsync, compatible POSIX. L'appel fsync initie une écriture forcée depuis le tampon vers le disque.

Nous démontrerons l'impact des tampons à travers un exemple simple sous forme d'un court programme en 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 « réponse à la question fondamentale de la vie, de l'univers et de tout le reste » sera mis en cache par le système d'exploitation, et si le serveur est redémarré 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 travaillent simultanément avec de nombreux fichiers, elles veulent donc être sûres que les données qu'elles écrivent seront enregistrées sur le disque, car cela dépend de la cohérence des données au sein de la BDD. Les bases de données sont conçues pour enregistrer toutes les transactions complètes et être prêtes à une coupure d'alimentation à tout moment. Ce comportement les oblige à utiliser fsync de manière constante en grande quantité.

Quel est l'impact d'une utilisation fréquente de fsync

Lors d'opérations d'entrée-sortie normales, le système d'exploitation tente d'optimiser la communication avec les disques, car dans la hiérarchie de la mémoire, les dispositifs de stockage externes sont les plus lents. Par conséquent, le système d'exploitation essaie d'écrire le plus de données possible lors d'un seul accès au dispositif.

Nous allons démontrer l'influence de l'utilisation de fsync à travers un exemple concret. Les disques solides que nous allons utiliser sont les suivants :

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 Gb/s.

Les tests sont réalisés sur Intel® Xeon® W-2255 sous Ubuntu 20.04. Pour tester les disques, nous utilisons sysbench 1.0.18. Un seul partitionnement a été effectué sur les disques, formaté en ext4. La préparation au test consiste à créer des fichiers d'une taille de 100 Go :

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

Lancement des tests :

# Без 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+

Lecture sans fsync, MiB/s
5734.89
9028.86

Écriture sans fsync, MiB/s
3823.26
6019.24

Lecture avec fsync, MiB/s
37.76
3.27

Écriture avec fsync, MiB/s
25.17
2.18

Il n'est pas difficile de constater que le NVMe du segment client domine lorsque le système d'exploitation décide par lui-même comment travailler avec les disques, et qu'il perd lorsque fsync est utilisé. Cela soulève deux questions :

Pourquoi, dans le test sans fsync, la vitesse de lecture dépasse-t-elle la capacité physique de la bande passante ?
Pourquoi les SSD du segment serveur gèrent-ils mieux 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é effectué sur 100 Go 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, accélérant considérablement l'exécution.

Si l'on remet en question tous les résultats de sysbench, on peut 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+

Lecture sans fsync, MiB/s
45.5
178

Écriture sans fsync, MiB/s
30.4
119

Lecture avec fsync, MiB/s
32.6
20.9

Écriture avec fsync, MiB/s
21.7
13.9

La tendance à la chute de performance du NVMe lors de l'utilisation de fsync est bien marquée. Nous pouvons maintenant passer à la réponse à la deuxième question.

Optimisation ou bluff

Nous avons précédemment mentionné que les données sont stockées dans un tampon, mais nous n'avons pas précisé lequel, car cela n'était pas essentiel. Nous ne nous attarderons pas sur les subtilités des systèmes d'exploitation et mettrons en évidence deux types généraux de tampons :

logiciel ;
matériel.

Le terme "cache logiciel" désigne les caches présents dans le système d'exploitation, tandis que le "cache matériel" fait référence à la mémoire volatile du contrôleur de disque. L'appel système fsync envoie au disque une commande pour écrire les données de son cache dans le stockage principal, mais ne peut en aucun cas vérifier la bonne exécution de cette commande.

Puisque les SSD affichent de meilleures performances, deux hypothèses peuvent être formulées :

le disque est conçu pour supporter une charge de ce type ;
le disque "ment" et ignore la commande.

Un comportement inapproprié du disque peut être remarqué en effectuant un test avec une coupure de courant. Cela peut être vérifié avec le script diskchecker.pl, qui a été créé en 2005.

Ce script nécessite deux machines physiques — un "serveur" et un "client". Le client écrit un petit volume de données sur le disque 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 le démarrage du script, il est nécessaire de couper l'alimentation du "client" et de ne pas rétablir l'alimentation pendant plusieurs minutes. Il est important de couper l'alimentation du testeur, et pas seulement d'effectuer un arrêt brutal. Après un certain temps, le serveur peut être reconnecté et démarré sur le système d'exploitation. Une fois le système d'exploitation chargé, il faut relancer diskchecker.pl, mais avec l'argument verify.

.\/diskchecker.pl -s  verify

À la fin de la vérification, vous verrez le nombre d'erreurs. S'il y en a 0, cela signifie que le disque a réussi l'épreuve. Pour éviter des circonstances favorables au disque, il est possible de répéter l'expérience plusieurs fois.

Notre S4500 n'a montré aucune erreur lors d'une coupure de courant, ce qui signifie qu'on peut affirmer qu'il est prêt pour des charges avec un grand nombre d'appels fsync.

Conclusion

Lors du choix des disques ou des configurations prêtes à l'emploi, il convient de se rappeler la spécificité des tâches à réaliser. À première vue, il semble évident que NVMe, c'est-à-dire SSD avec interface PCIe, est plus rapide que le SSD SATA "classique". Cependant, comme nous l'avons compris aujourd'hui, cela peut ne pas être le cas dans des conditions spécifiques et avec des tâches particulières.

Comment testez-vous les composants serveurs lors de la location chez un fournisseur IaaS ?
Nous vous attendons dans les commentaires.

Source : habr.com