Clever Geek Handbook

Pourquoi mon NVMe est-il plus lent que mon 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 le SSD provenait du segment des serveurs.



De toute évidence, comparer des produits de différents segments dans différents environnements est incorrect, mais ce n'est pas une réponse technique exhaustive. Apprenons les bases, expérimentons et répondons à la question.



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é se présente pour enregistrer le contenu de la mémoire 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 de la mémoire tampon seront perdues.



Il existe un certain nombre de tâches dans lesquelles vous devez vous assurer que les modifications d'un fichier sont écrites sur le lecteur et non dans une mémoire tampon intermédiaire. Cette confiance peut être acquise en utilisant l'appel système fsync compatible POSIX. L'appel fsync lance une écriture forcée du tampon vers le lecteur.



Démontrons l'effet des tampons avec un exemple artificiel sous la forme d'un programme court 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, "42\n", 3); 

    return 0;
}


Les commentaires expliquent bien la séquence des actions du 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 "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 simultanément avec de nombreux fichiers, ils veulent donc être sûrs que les données qu'ils écrivent seront enregistrées sur le lecteur, car la cohérence des données à l'intérieur de 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 pour les pannes de courant à tout moment. Ce comportement nous oblige à utiliser fsync en grande quantité tout le temps.



Quels sont les effets de l'utilisation fréquente de fsync

Avec des E / S normales, le système d'exploitation essaie d'optimiser sa communication avec 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 appel au lecteur.



Dé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, PCIe 3.0 x4, ~ 31 Gbit / s.


Les tests sont effectués sur Intel® Xeon® W-2255 exécutant Ubuntu 20.04. Sysbench 1.0.18 est utilisé pour tester les disques. Une partition est créée sur les disques, formatée en ext4. La préparation du 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.

Tester Intel® S4500 Samsung 970 EVO +
Lecture sans fsync, MiB / s 5734,89 9028,86
Enregistrement sans fsync, MiB / s 3823,26 6019,24
Lire avec fsync, MiB / s 37,76 3,27
Enregistrement Fsync, MiB / s 25,17 2,18
Il est facile de voir que NVMe du segment client mène avec 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 dans le test sans fsync la vitesse de lecture dépasse la bande passante physique?
  2. Pourquoi un SSD côté serveur est-il meilleur 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 monotones 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
Tester Intel® S4500 Samsung 970 EVO +
Lecture sans fsync, MiB / s 45,5 178
Enregistrement sans fsync, MiB / s 30,4 119
Lire avec fsync, MiB / s 32,6 20,9
Enregistrement Fsync, MiB / s 21,7 13,9
La tendance à la baisse des performances NVMe lors de l'utilisation de fsync est clairement visible. Vous pouvez passer à la réponse à 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é lequel, car ce n'était pas important. Nous n'entrerons pas dans les subtilités des systèmes d'exploitation maintenant et identifierons deux types généraux de tampons:



  • programme;
  • Matériel.


Le tampon logiciel fait référence aux tampons qui se trouvent 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 des données de sa mémoire tampon vers le stockage principal, mais il ne peut pas contrôler l'exactitude de l'exécution de la commande.



Étant donné que les SSD fonctionnent mieux, deux hypothèses peuvent être faites:



  • le disque est conçu pour une telle charge;
  • le disque bluffe et ignore la commande.


Vous pouvez voir le comportement malhonnête du lecteur si vous exécutez un test de panne de courant. Vous pouvez vérifier cela à l'aide du script diskchecker.pl , qui a été créé en 2005.



Ce script nécessite deux machines physiques - «serveur» et «client». Le client écrit une petite quantité 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 avoir exécuté le script, il est nécessaire de mettre hors tension le «client» et de ne pas le remettre sous tension pendant plusieurs minutes. Il est important de déconnecter la personne testée de l'électricité, et pas seulement d'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 le démarrage du système d'exploitation, vous devez exécuter à nouveau diskchecker.pl , mais avec l'argument verify . 



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


À la fin du contrôle, vous verrez le nombre d'erreurs. S'il y a 0, le disque a réussi le test. Pour exclure une combinaison de circonstances réussies 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, on peut donc affirmer qu'il est prêt pour des charges avec beaucoup d'appels fsync.



Conclusion

Lorsque vous choisissez des disques ou des configurations prêtes à l'emploi, vous devez vous rappeler les spécificités des tâches à résoudre. À 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, dans des conditions spécifiques et avec 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?

Nous vous attendons dans les commentaires.





More articles:


All Articles