La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 23 juin 2017 à 09:27:56
-
J'entends souvent dire qu'un disque SATA 7200tr/min sait réaliser des transfert a plusieurs centaines de Mo/s. Vous allez voir que dans la vraie vie sur un serveur, c'est 20 Mo max.
Oui, un disque traditionnel sait monter a des très haut débit dans un bench, avec une lecture séquentielle, mais pour la lecture de nombreux fichiers sur un serveur, on est loin du compte.
Cette nuit, une personne a cloné le miroir Ubuntu.
J'ai deux disques dur sur le miroir Ubuntu:
- sda : Un disque dur SATA 3,5 pouces 7200tr/min de 500Go type serveur, qui héberge 293 Go d'archive (les moins consultées) + le système
- sdb : Un SSD grand public de 1 To qui héberge 829 Go d'archive (les plus consultées)
L'objectif était de mettre tous le miroir sur le SSD, mais il dépasse maintenant 1To.
Le disque SATA a été utilisé plus d'une heure à 100% de sa capacité lors du clonage du miroir, ce qui permet de voir les débit qu'il est capable de délivrer :
(https://lafibre.info/images/stats/201706_ubuntu_diskstats_utilization.png) (https://lafibre.info/images/stats/201706_ubuntu_diskstats_latency.png)
On ne dépasse pas 20 Mo sur un disque dur SATA sur ce type d'utilisation ! (le SSD monte à 70 Mo/s mais il n'a pas été utilisé au maximum, cf courbe précédente)
(https://lafibre.info/images/stats/201706_ubuntu_diskstats_throughput.png) (https://lafibre.info/images/stats/201706_ubuntu_diskstats_iops.png)
L’utilisation du disque dur classique, comme du SSD entraîne un échauffement du disque : (ils sont positionnées au niveau de l’entrée d'air du serveur, donc ce ne peut pas etre le CPU qui les chauffe)
(https://lafibre.info/images/stats/201706_ubuntu_hddtemp_smartctl.png)
Le fait d'attendre les entrée / sortie du disque SATA provoque une explosion des i/o wait et du load average :
(https://lafibre.info/images/stats/201706_ubuntu_cpu.png) (https://lafibre.info/images/stats/201706_ubuntu_load.png)
Comme cela se fait probablement avec une seulle connexion TCP, coté Apache, on ne vois rien sur les accés et les slots utilisés :
(https://lafibre.info/images/stats/201706_ubuntu_apache_processes.png) (https://lafibre.info/images/stats/201706_ubuntu_apache_accesses.png)
Cela se voir sur le volume utilisé par Apache et la carte réseau : On ne dépasse pas 1 Gb/s de trafic mais comme ces fichiers ne sont pas en cache ram, cela consomme beaucoup plus de ressources que les pic à 4 Gb/s qui concernent des données en cache.
(https://lafibre.info/images/stats/201706_ubuntu_apache_volume.png) (https://lafibre.info/images/stats/201706_ubuntu_if_p1p1.png)
-
Il y a un mois, j'avais l'archive Ubuntu qui était pour grande partie sur un SSD de 1 to et sur un disque dur classique de 500 Go.
Depuis trois semaines, j'ai maintenant tout sur SSD (un RAID 0 hardware Dell PERC H330 de deux SSD Intel de 960 Go chacun, connecté en SATA et avec des puces MLC)
J'ai donc ouvert le serveurs aux connexions rsync comme le font presque tous les serveurs par défaut pour un pays et je vois que c'était attendu car sans même communiquer sur cette nouvelle fonctionnalité, j'ai eu plusieurs synchronisations.
Problème : je suis déçu par les performances des SSD, vous allez comprendre dans les stats : je sature un RAID 0 de deux SSD avec un débit en lecture de 100 Mo/s (800 Mb/s). Pourquoi ?
Rsync: Quantités de données échanges via Rsync, par période de 5 minutes, en Go :
(https://lafibre.info/images/stats/201712_ubuntu_rsync_bytes.png)
On est a environ 19 Go/5minutes soit environ 500 Mb/s.
Rsync: Nombre de fichiers échangés par période de 5 minute :
(https://lafibre.info/images/stats/201712_ubuntu_rsync_count.png)
On est a environ 10k fichiers/5minutes, soit 33 fichiers par seconde environ (pic de 65k fichiers/5minutes, soit 220 fichiers par seconde
Regardez l'impact sur l'utilisation disque :
Pourcentage d'utilisation des disques: (c'est un RAID 0 hardware constitué de deux SSD Intel 960Go MLC en SATA)
(https://lafibre.info/images/stats/201712_ubuntu_diskstats_utilization.png)
"sda" correspond au RAID 0 hardware de deux SSD Intel
Les caractéristiques de la carte RAID Dell PERC H330 dans le lscpi -v :
03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3008 [Fury] (rev 02)
DeviceName: Integrated RAID
Subsystem: Dell PERC H330 Adapter
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at 3000 [size=256]
Memory at 95c00000 (64-bit, non-prefetchable) [size=64K]
Memory at 95b00000 (64-bit, non-prefetchable) [size=1M]
Expansion ROM at <ignored> [disabled]
Capabilities: [50] Power Management version 3
Capabilities: [68] Express Endpoint, MSI 00
Capabilities: [d0] Vital Product Data
Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [1e0] #19
Capabilities: [1c0] Power Budgeting <?>
Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
Kernel driver in use: megaraid_sas
Kernel modules: megaraid_sas
Débit en Mo/s lu / écrit sur les disques: (Ne correspond pas au trafic réseau, car la RAM cache les données les plus lues)
(https://lafibre.info/images/stats/201712_ubuntu_diskstats_throughput.png)
On est sur un trafic de 650 à 800 Mb/s, soit 150 à 300 Mb/s de plus que le débit RSYNC => C'est lié au fait que le transfert RSYNC doit vider du cache disque des fichiers fortement demandés.
Nombre de IOPS sur les disques (opérations d'entrée-sortie par seconde) :
(https://lafibre.info/images/stats/201712_ubuntu_diskstats_iops.png) (https://lafibre.info/images/stats/201712_ubuntu_diskstats_iops_2.png)
Latence accès disque (enfin le RAID 0 de SSD) :
(https://lafibre.info/images/stats/201712_ubuntu_diskstats_latency.png)
Avec un disque saturé à 100% en E/S, le Load average explose et le CPU attend les E/S (iowait) :
(https://lafibre.info/images/stats/201712_ubuntu_load.png) (https://lafibre.info/images/stats/201712_ubuntu_cpu.png)
Bien sur il n'y a pas que RSYNC qui charge le serveur, il y a les requêtes http de mise à jour de milliers d'ordinateurs, mais c'est toujours les mêmes fichiers qui sont chargés et le contenu est probablement en cache RAM (il y a 32 Go de RAM)
Débit des connexions Apache (mises à jour via http/https) en Mo/s : Nombre de fichiers téléchargés par seconde :
(https://lafibre.info/images/stats/201712_ubuntu_apache_volume.png) (https://lafibre.info/images/stats/201712_ubuntu_apache_accesses.png)
Trafic réseau en Mb/s sur la carte réseau : (comprend donc les requêtes http/https et rsync)
(https://lafibre.info/images/stats/201712_ubuntu_if.png)
-
Avec un disque saturé à 100% en E/S, le Load average explose et le CPU attend les E/S (iowait) :
Ce n'est pas le CPU qui attend en IOWait mais les process/threads.
Un CPU en iowait veut simplement dire qu'il est idle (rien d'autre à traiter), avec au moins process/threads en attente d'IO.
%iowait
Show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
Aussi, tu indiques que le logical disk est saturé, ce n'est pas certain : il suffit qu'il ait en moyenne toujours une I/O en cours de traitement pour être comptabilisé à 100% Busy par l'OS, mais avec le Command Queuing il peut accepter plusieurs I/O simultanèment donc peut-être a-t-il de la réserve en pratique.
As-tu fais un bench avec un outil comme fio ou IOmeter pour voir ce que peut réellement encaisser ton système IO ?
-
Non, je n'ai pas fait de bench, mais j'ai été un peu horrifié par le load average :
(https://lafibre.info/images/stats/201712_ubuntu_load.png)
Donc malgré un load average de 30,la machine n'aurais pas été à la peine ?
Les stats loadtime (temps d'attente en milliseconde pour charger les stats munin) est resté très faible (à 0) :
(https://lafibre.info/images/stats/201712_ubuntu_http_loadtime.png)
-
Il faudrait réaliser quel test avec fio ?
Voici un autre cas, arrivé hier à 11h00 et là on voit que cela à impacté le temps de chargement des autres fichiers.
Trafic réseau en Mb/s ou Gb/s généré par les mises à jour (via http/htps/rsync) sur la carte Intel X710 :
(https://lafibre.info/images/stats/201708_miroir_ubuntu_if_enp2s0f0.png)
Débit des connexions Apache (mises à jour via http/https) en Mo/s : On voit que la charge a cette vois ci été réalisée par Apache.
(https://lafibre.info/images/stats/201708_miroir_ubuntu_apache_volume.png)
Temps d'attente (en milliseconde) pour charger un fichier Apache local : On note une belle dégradation avec un temps moyen d'attente de100 millisecondes pendant que les E/S disques sont saturées.
(https://lafibre.info/images/stats/201708_miroir_ubuntu_http_loadtime.png)
Pourcentage d'utilisation des disques: (c'est un RAID 0 hardware constitué de deux SSD Intel 960Go MLC en SATA) On est à 100%
(https://lafibre.info/images/stats/201708_miroir_ubuntu_diskstats_utilization.png)
Débit en Mo/s lu / écrit sur les disques: (Ne correspond pas au trafic réseau, car la RAM cache les données les plus lues)
(https://lafibre.info/images/stats/201708_miroir_ubuntu_diskstats_throughput.png)
Nombre de IOPS (opérations d'entrée-sortie par seconde) sur la carte RAID Dell PERC H330 :
(https://lafibre.info/images/stats/201708_miroir_ubuntu_diskstats_iops.png)
Latence (IO Wait) sur la carte RAID Dell PERC H330 :
(https://lafibre.info/images/stats/201708_miroir_ubuntu_diskstats_latency.png)
Load average (moyenne de la charge système) :
(https://lafibre.info/images/stats/201708_miroir_ubuntu_load.png)
Usage du processeur Xeon E3-1240 v6 (1 cœur=100% => 4 cœurs hyper-threading, donne un maximum de 800%) :
(https://lafibre.info/images/stats/201708_miroir_ubuntu_cpu.png)
-
Changer le scheduler pour BFQ n'est pas envisageable ? D'autant qu'il est désormais présent officiellement dans le noyau :)
-
Il faudrait réaliser quel test avec fio ?
Par exemple (sur un Crucial_CT275MX300SSD1)
87% [jack:/tmp]fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=2G --readwrite=randrw --rwmixread=75 --numjobs=10
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
...
fio-3.6
Starting 10 processes
...
test: (groupid=0, jobs=1): err= 0: pid=12854: Sat Aug 11 16:07:01 2018
read: IOPS=4733, BW=18.5MiB/s (19.4MB/s)(1536MiB/83094msec)
bw ( KiB/s): min=11568, max=22240, per=10.02%, avg=18919.69, stdev=1605.23, samples=166
iops : min= 2892, max= 5560, avg=4729.88, stdev=401.29, samples=166
write: IOPS=1576, BW=6305KiB/s (6457kB/s)(512MiB/83094msec)
bw ( KiB/s): min= 3696, max= 7296, per=9.99%, avg=6300.14, stdev=563.09, samples=166
iops : min= 924, max= 1824, avg=1574.99, stdev=140.76, samples=166
cpu : usr=0.64%, sys=4.79%, ctx=614219, majf=0, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=393302,130986,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=184MiB/s (193MB/s), 18.4MiB/s-18.6MiB/s (19.3MB/s-19.5MB/s), io=14.0GiB (16.1GB), run=82570-83280msec
WRITE: bw=61.6MiB/s (64.6MB/s), 6293KiB/s-6357KiB/s (6444kB/s-6510kB/s), io=5127MiB (5376MB), run=82570-83280msec
Disk stats (read/write):
dm-0: ios=3924303/1312639, merge=0/0, ticks=3300496/585920, in_queue=3890160, util=96.47%, aggrios=3925265/1312898, aggrmerge=5171/1910, aggrticks=3114496/580884, aggrin_queue=2347912, aggrutil=96.07%
sdc: ios=3925265/1312898, merge=5171/1910, ticks=3114496/580884, in_queue=2347912, util=96.07%
-
J'entends souvent dire qu'un disque SATA 7200tr/min sait réaliser des transfert a plusieurs centaines de Mo/s. Vous allez voir que dans la vraie vie sur un serveur, c'est 20 Mo max.
Dans "la vraie vie sur un serveur" un disque SATA est dans un groupe RAID. A partir de la tout ce qui suit est purement académique... ;)
-
Dans "la vraie vie sur un serveur" un disque SATA est dans un groupe RAID. A partir de la tout ce qui suit est purement académique... ;)
Toi, faire du raid ?
Il est temps de ne plus faire de raid !
-
Je me suis amusé à tester les performances de mes SSD via l'outil Gnome Disque (installé avec les distributions Debian, Ubuntu, Linux Mint, Trisquel, Fedora, Red Hat Enterprise Linux, CentOS et autres distributions Gnome).
Si vous avez un PC sous Windows, vous pouvez faire le test via une clé de boot USB Linux.
J'ai rajouté un "0" au nombre d'échantillons proposé par défaut : 1000 échantillons pour le test de débit en lecture et 10 000 pour le temps d'accès.
(https://lafibre.info/testdebit/ubuntu/201808_Performance_disque.png)
Avec un vieux SSD Kingston de 60 Go : (test réalisé avec un PC Core i3-4150 @3.50GHz sous Ubuntu 18.04 avec un kernel 4.15)
(https://lafibre.info/testdebit/ubuntu/201808_Performance_SSD_Kingston_60Go.png)
On note qu'il y a régulièrement des tests avec un nettement en dessous e de la moyenne.
Les performances seraient un peu meilleures au début du disque ?
Avec un Samsung 850 EVO 250 Go qui a déjà été bien utilisé (11 mois sous tension, 2 To écrit) : (test réalisé avec un PC Core i7-2600 @3.40GHz sous Ubuntu 18.04 avec un kernel 4.15)
(https://lafibre.info/testdebit/ubuntu/201808_Performance_SSD_Samsung_8501_EVO_250Go.png)
tout est parfait
Avec un SSD SanDisk Ultra II de 480 Go acheté i y a presque deux ans : (test réalisé avec un PC Core i3-4150 @3.50GHz sous Ubuntu 18.04 avec un kernel 4.15)
(https://lafibre.info/testdebit/ubuntu/201808_Performance_SSD_SanDisk_Ultra_II_480Go.png)
Les performances seraient un peu meilleures à la fin du disque ?
Avec le SSD Sk hynix SC311 livré avec mon PC portable Dell acheté en février 2018 : (test réalisé avec un PC Core i5-8250U @1.60GHz sous Ubuntu 18.04 avec un kernel 4.15)
(https://lafibre.info/testdebit/ubuntu/201808_Performance_SSD_Sk_hynix_SC311_256Go.png)
-
Dans "la vraie vie sur un serveur" un disque SATA est dans un groupe RAID. A partir de la tout ce qui suit est purement académique... ;)
Pas avec les systèmes de stockage distribués, type Ceph, où les disques sont utilisés individuellement (passthrough), et pas dans un volume Raid. Et cela devient de plus en plus courant. A noter que le dernier contrôleur Raid de Dell, le Perc H740p, ne supporte pas encore ce mode.
-
Ceph ou RAID ca revient au meme. Le point est qu'on utilise rarement un disque seul.
-
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.
-
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.
Tu peux tout à fait mélanger sata, sas, nvme, ssd, disque dur, n'importes quoi, au sein d'une même "grappe" raid
Naturellement, cela tire la performance de l'ensemble vers la performance de l’élèment le plus lent
-
Mais dans un volume Ceph, on peut mélanger les SSDs et les disques SATA/SAS, ce qui n'est pas le cas dans un volume Raid, et je peux te dire que quand on a mis des disques SATA dans un volume Ceph avec des disques SSDs, cela fait sacrèment baisser les performances de l'ensemble.
Alors que l'inverse, bien configuré, ça met un joli coup de boost a ton cluster :)
-
Vous êtes sûrs de vous là pour une carte Dell Perc H730p en particulier ? Que l'on puisse avoir deux volumes Raid, l'un avec des SSDs, et l'autre avec des disques NLSAS, oui, mais mélanger les deux au sein d'un même "disque virtuel", ce n'est à ma connaissance pas possible.
Après lecture du manuel utilisateur de la carte H730p :
"La combinaison de disques SAS et SATA au sein d'un disque virtuel n'est pas prise en charge. De même, la combinaison de
disques durs et de SSD au sein d'un disque virtuel n'est pas prise en charge."
https://topics-cdn.dell.com/pdf/poweredge-rc-h330_users-guide_fr-fr.pdf
-
Vous êtes sûrs de vous là pour une carte Dell Perc H730p en particulier ? Que l'on puisse avoir deux volumes Raid, l'un avec des SSDs, et l'autre avec des disques NLSAS, oui, mais mélanger les deux au sein d'un même "disque virtuel", ce n'est à ma connaissance pas possible.
Je te parle de raid
Sur cette carte en particulier, aucune idée, je ne connais pas
-
Là, je me demande si vous ne me parlez pas de raid logiciel (madm) ?
-
Salut
Juste pour dire que je peux en parti expliquer le pourquoi des benchmark aux résultats étrange. Faut juste que je trouve un peu de temps et un clavier (mieux que le smartphone).
Mais en résumé un bench de SSD tout seul ne donnera sûrement pas le même résultat tout le temps suivant l'utilisation du SSD.
Quoi qu'il en soit vivien, est-ce que le raid géré par le controlleur supporte le passage du trim aux SSD? Et aussi pour aider les écritures (surtout s'il n'y a pas de trim), est-ce que tu as dimensionné le raid pour utiliser 85/90% des 2 SSD?
-
Je suis intéressé pour voir les performances du SSD avec l'outil de test intégré dans Ubuntu.
Un boot sur une clé USB avec Ubuntu 18.04 est suffisant.
=> https://lafibre.info/tutoriels-linux/performance-des-ssd-disques/msg567103/#msg567103
A ta demande vivien, j'ai fait le test sur mon SSD Samsung 970 EVO 250Go M.2 PCIe NVMe.
-
Bon,
Je vais commencer par un petit speach sur le fonctionnement d'une flash.
Pour accéder à une mémoire flash, une adresse est définie par page (p = puissance de 2, par exemple 8KB), secteur (x pages) et bank (y secteurs).
Pourquoi cette subdivision ?
Parce que quand on fait un accès à la flash, la mémoire convertie l'adresse donnée en une page qu'elle charge ensuite dans un buffer (mémoire) interne. Ce qui permet à la flash une fois la page préchargée d'envoyer les données très rapidement (burstée). La page est donc le plus petit élèment accédé sur une flash. Ensuite x pages (tjrs une puissance de 2) forment un secteur. Un secteur est le plus petit élèment effaçable sur une flash. Dans une flash on n'efface jamais une page mais un secteur tout entier. Il faut noter que l'effacement d'un secteur de flash prend un temps très long (par rapport à la lecture). Sur les premières flash (NOR) cela pouvait prendre de l'ordre de quelques centaines de ms.... Maintenant ça c'est amélioré mais bon cela reste très long. Enfin la bank est la dernière séparation. Une bank est le nombre de secteurs auquel il ne faut plus accéder lors d'un effacement. Et oui, l'effacement d'un secteur étant très long, c'est fait de manière asynchrone (ordre d'effacement, puis lecture à intervalle régulier du status). Problème, il faut laisser la flash "travailler" et donc ne pas accéder aux données en cours d'effacement. Mais en fait c'est même plus compliqué que cela, c'est toute une bank (y secteurs) qui est inaccessible lors d'un effacement.
Pour résumer:
- page: plus petit élèment accédé
- secteur: plus petit élèment effacé
- bank: plus petit élèment inaccessible lors d'un effacement
Côté fonctionnement, une flash contient initialement que des bits à 1, et une écriture consiste à mettre à zéro des bits sur une page. On peut réécrire une page, seuls les nouveaux bits à zéros seront écrits. Il n'est donc pas possible d'écrire un bit à 1. Et donc un effacement consiste à remettre TOUS les bits d'un secteur à 1. Et enfin il faut savoir qu'une page supporte un nombre limite d'écriture de zéros avant de commencer à flancher (= ne pas écrire le zéro). Sur les premiers modèles c'était de l'ordre de plusieurs milliers, maintenant cela se compte en centaines... Mais bon, cela reste des statistiques.
Vous commencez à voir les problèmes avec les filesystem conçus pour fonctionner avec un disque dur (et donc possible d'écrire des zéros et des 1 dans un secteur) ?
Un processeur flash fait donc y*x*p bytes.
Du moins commercialement, car une page c'est un peu plus qu'une puissance de 2...
En fait, il est d'usage de rajouter quelques octets APRES la page. Je ne me rappelle plus combien mais c'est de l'ordre de 16 octets par KO. Pourquoi ces données en plus ? En fait il y a plusieurs raisons à cela:
- cela contient un code correcteur d'erreur (3 octets/512 octets) qui permet de détecter et potentiellement corriger une erreur d'un bit (un seul)/512 octets
- cela contient surtout des paramètres sur l'état de la page et qui est propre à l'algorithme implèmenté dans le contrôleur et qui va s'interfacer avec le PC
Quoi qu'il en soit, dans un SSD affiché à 960GB, il y a des chances pour qu'il y ait au moins 1TB voir même beaucoup plus, ceci sans compter les données extras par page.
Bon, toute cette introduction est là pour dire qu'au final ce qui donne de bonne performances à un SSD c'est surtout l’intelligence (= l'algorithme) de son contrôleur.
En effet, celui ci devra gérer: plusieurs chip flash en parallèle, plusieurs bank inaccessibles lors des effacements, le wear-leveling (= répartition du nombre d'écriture sur la totalité de la flash), et tout ça en prenant bien garde de ne pas perdre de données si le courant est coupé.
D'ailleurs, comme le wear-leveling est très (de plus en plus) important, on va détailler un peu ce que cela doit faire.
Pour le wear-leveling, cela est important car comme une page à un nombre (de plus en plus) limité d'écriture avant erreur, cet algorithme doit répartir les écritures sur le plus de pages différentes de flash possible (donc sur la totalité de la flash). Cela implique obligatoirement que le contrôleur est capable de faire une translation d'adresse du type secteur logique (LBA) -> adresse en flash (complètement différente). Et si jamais une écriture dans un secteur logique a lieu, il faut que le contrôleur choisisse une nouvelle adresse en flash vierge (effacée), écrive les nouvelles données dessus, sauvegarde dans sa structure la nouvelle translation LBA->adresse, et enfin marque la précédente adresse en flash comme "invalide - à effacer". C'est aussi pour ça qu'il y a toujours plus de flash qu'affiché (genre 1TB pour 960GB affiché), cela permet à l'algorithme de wear-leveling de toujours trouver une page vierge.
Avec le wear-leveling vient aussi le garbage collector. Son but c'est d'effacer la flash en background en se basant sur les pages marquées "à effacer". Par exemple quand un secteur logique LBA a été écrit 2 fois. Là c'est facile, l'ancienne adresse en flash de la première écriture doit être effacé. A noter, le TRIM aide énormèment. Dans un filesystem classique prévue pour un disque dur lent, effacer un fichier consiste juste à réécrire quelques secteurs contenant la position du fichier sur le disque et voilà. Ce qui fait qu'avec un SSD on se retrouve avec des données effacés sur le filesystem mais pas en flash et là le garbage collector rame pour trouver des secteurs à effacer. Alors qu'avec le TRIM, on envoi en plus toute la position du fichier effacé sur le disque au controleur du SSD qui peut directement marquer les pages de la totalité du fichier comme "à effacer". Mais comme sur une flash on n'efface pas une page mais un secteur, comment on fait ? Et là c'est la magie du garbage collector qui parfois se retrouve à déplacer quelques pages pour effacer tout un secteur.
Et enfin, si jamais le contrôleur tombe sur une page qui nécessite une correction d'erreur, la page doit être marqué comme "à ne plus utiliser" et les données déplacées sur une nouvelle page.
En fait les problèmes que les contrôleurs doivent gérer en plus avec les filesystem:
- la translation LBA->adresse en flash
- la réécriture d'un secteur
- je n'en ai pas parlé, mais un secteur logique ne fait pas forcement la taille d'une page (512B ou 4KB vs des pages de 8KB parfois)
- le TRIM qui permet de marquer très tôt un fichier à effacer
- le pool de pages vierges
Voilà donc ce qui fait que 2 benchmark ne donnent que rarement le même résultat:
- la translation LBA->adresse en flash peut prendre plus de temps suivant qu'il s'agit d'un secteur jamais accédé avant ou pas
- la translation LBA->adresse en flash peut prendre plus de temps suivant qu'il y ait une grosse fragmentation
- si le garbage collector travail plus ou moins
- suivant le remplissage du SSD
- suivant les performances au globale du contrôleur
- s'il y a des effacements à gérer en parallèle
- ou pas...
- si on écrit que des 1
....
Bref le benchmark rapide d'un SSD cela ne sert quasi à rien pour avoir une idée de ce que cela donnera en condition réelle.
Mes conseils sur les SSD:
- bien vérifier que le TRIM arrive bien aux SSD malgré le RAID
- aider le garbage collector en allouant des partitions un peu plus petites que la taille du disque (genre 10/15% en moins) même s'il y a déjà de la mémoire en plus
- faire plus confiance aux sites qui vérifient la stabilité des performances suivant le remplissage
- les meilleurs performances seront souvent atteint pour une quantité limité de données
-
Note:
j'ai déjà bossé sur des flash mais cela commence à dater un peu (les dernières supportaient 10000 écritures). Autant sur les SSD cela reste des contrôleurs parfois sur base ARM (de ce que j'ai vu), autant je n'ai aucune idée de comment sont intégrées les flash NVMe vu les besoins en performance de l'interface. S'agit-t-il d'ASIC dédiés avec toujours le même algorithme, ou de contrôleurs ultra rapide (surtout pour faire la translation d'adresse), ou plus bêtement tout l'aspect translation d'adresse et gestion du wear-leveling est fait sur le le processeur principale du PC suivant une norme intégré dans les BIOS modernes....
Quoi qu'il en soit à l'époque j'ai halluciné des gains en performances possible pour linux (3.x à l'époque...) à condition d'accepter du dédié machine. Par exemple la lecture d'une page se fait en 2 fois: la page est lue puis les données extra (la fin de la page). Sachant que cela implique 2 fois la latence de lecture d'une page, on double les performances FS très simplement en lisant d'une passe la page et les extras ! Et encore il y avait d'autres gains faciles à intégrer (alignement de page, lecture initiale, etc)... Bref peut-être aujourd'hui c'est (j'espère) mieux géré mais à l'époque c'était encore le far-west...
-
@Zeda impressionnant le gain de débit lecture du SSD Samsung 970 EVO 250Go M.2 PCIe NVMe
Il multiplie les performances SATA du test par 6 !
@Fuli10 Merci pour ces explications. Dans mon cas (serveur miroir) je n'ai presque aucun besoin en écriture et mes problèmes sont en lecture, sachant que c'est de nombreux petits fichiers qu'il faut lire et pas des gros blocs contigus.
Le système de fichier est Ext4, il y a beaucoup de place disponible (utilisation à 60%) et le kernel Linux est récent (4.13)
Les SSD et la carte RAID sont ceux d'origine de Dell, j'ai juste reconfiguré le RAID 1 d'origine en RAID 0, car Dell ne sait pas proposer un RAID 0 pré-installé.
=> Le RAID 0 est composé de deux SSD Intel 960Go MLC en SATA connecté à la sur la carte RAID Dell PERC H330. C'est du matériel qui a un an (commandé à la rentrée 2017 et installé fin 2017)
-
Pour tester le trim:
https://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2/
Pour les performances en lecture, cela vient peut être (supposition maraboutesque) du contrôleur qui "cache" la translation secteur logique->adresse flash. Et dans le cas de lecture de beaucoup de fichiers, si c'est reparti sur tout le disque logique le cache est dépassé...
Note: si le trim ne fonctionne pas, même si le disque est rempli qu'à 60%, le garbage collector n'aura pas effacé 40% du SSD car il ne saura pas si une page contient un fichier effacé ou pas. Du coup le pool de pages libre est réduit.
-
Performances des clé USB :
USB 3.1 Gen 1 :
- 4 Go : 80 Mo/s en lecture, 12 Mo/s en écriture
- 8 Go & 16 Go : 165 Mo/s /s en lecture, 22 Mo/s en écriture
- 32 Go : 250 Mo/s en lecture, 40 Mo/s en écriture
- 64 Go : 250 Mo/s en lecture, 85 Mo/s en écriture
- 128 Go : 250 Mo/s en lecture, 85 Mo/s en écriture
USB 2.0 :
- 4 Go : 30 Mo/s en lecture, 12 Mo/s en écriture
- 8 Go à 128 Go : 30 Mo/s en lecture, 20 Mo/s en écriture
J'ai pris ici les débits communiqués par Kingston pour sa clé USB chiffrée IronKey D300S (utilise la technologie de chiffrement matériel AES 256-bit en mode XTS).
A noter que la clé D300S est maintenant compatible Linux (contrairement a sa version précédente D300), elle prend en charge un nombre restreint de commandes Linux, notamment celles de connexion, de déconnexion, d’initialisation, celles d’à-propos et d’oubli de mot de passe.
Nouvel exemple de la limitation des SSD :
Rsync: Débit en Mb/s à gauche et nombre de fichiers échangés par seconde à droite :
(https://lafibre.info/images/stats/201902_ubuntu_rsync_bytes.png) (https://lafibre.info/images/stats/201902_ubuntu_rsync_count.png)
Débit en Mo/s lu / écrit sur les disques à gauche et Pourcentage d'utilisation des disques: (c'est un RAID 0 hardware constitué de deux SSD Intel 960Go MLC en SATA) à droite :
(https://lafibre.info/images/stats/201902_ubuntu_diskstats_throughput.png) (https://lafibre.info/images/stats/201902_ubuntu_diskstats_utilization.png)
Nombre de IOPS (opérations d'entrée-sortie par seconde) sur la carte RAID Dell PERC H330 à gauche et latence à droite :
(https://lafibre.info/images/stats/201902_ubuntu_diskstats_iops.png) (https://lafibre.info/images/stats/201902_ubuntu_diskstats_latency.png)
Ce transfert à 400 Mb/s a eu de lourds impacts:
Usage du processeur Xeon E3-1240 v6 à gauche et Load average (moyenne de la charge système) à droite :
(https://lafibre.info/images/stats/201902_ubuntu_cpu.png) (https://lafibre.info/images/stats/201902_ubuntu_load.png)
Coté trafic réseau, le gros du trafic est généré par Apache, avec des fichiers qui sont toujours les mêmes et qui sont donc dans le cache 25 Go en RAM.
(https://lafibre.info/images/stats/201902_ubuntu_if.png)
-
Depuis trois semaines, j'ai maintenant tout sur SSD (un RAID 0 hardware Dell PERC H330 de deux SSD Intel de 960 Go chacun, connecté en SATA et avec des puces MLC)
J'ai donc ouvert le serveurs aux connexions rsync comme le font presque tous les serveurs par défaut pour un pays et je vois que c'était attendu car sans même communiquer sur cette nouvelle fonctionnalité, j'ai eu plusieurs synchronisations.
Problème : je suis déçu par les performances des SSD, vous allez comprendre dans les stats : je sature un RAID 0 de deux SSD avec un débit en lecture de 100 Mo/s (800 Mb/s). Pourquoi ?
Le serveur va être remplacé, voici les performances du transfert pour remplir le nouveau serveur. On est à environ 2 Gb/s soit 250 Mo/s pour un rsync de 1,7 To constitué de nombreux fichiers.
Ce qui limite le débit c'est les deux SSD Intel 960 GB MLC en RAID 0 sur une carte Dell PERC H330.
Bref, le débit utile d'un SSD sata de ce type est de 1 Gb/s soit 125 Mo/s.
(https://lafibre.info/images/stats/202111_ubuntu_perm_raid0_2ssd_sata_1.svg)
(https://lafibre.info/images/stats/202111_ubuntu_perm_raid0_2ssd_sata_2.svg)
-
On est à environ 2 Gb/s soit 250 Go/s
Plutôt des Mo/s non ? :D
-
Oui, corrigé.