Carte extension 4 NVME
J'ai "repéré" cette carte avec un libellé accrocheur :
Carte contrôleur PCIe 3.0 x4 pour 4 SSD M.2 NVMe M Key SANS MODE BIFURCATION
Pour un prix "correct" (moins de 60 Euros).
Dès la livraison je mé précipite et après quelques difficultés pour monter deux barettes NVME de 1To, car les vis fournies étaient "un peu" courtes, avec d'autres vis tout est rentré dans l'ordre et le montage dans la machine se fait ensuite sans problèmes.
Après un reboot la carte est repérée de suite et "lspci" donne :
05:00.0 Non-Volatile memory controller: Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03)
06:00.0 Non-Volatile memory controller: Micron/Crucial Technology P1 NVMe PCIe SSD[Frampton] (rev 03)
Les "disques" sont parfaitement visibles avec "fdisk -l | grep /dev/nvme" :
Disk /dev/nvme0n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk /dev/nvme1n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Et après création d'une partition "raid" sur chacun de mes nouveaux disques la même commande donne :
Disk /dev/nvme0n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
/dev/nvme0n1p1 2048 1953523711 1953521664 931,5G Linux RAID
Disk /dev/nvme1n1: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
/dev/nvme1n1p1 2048 1953523711 1953521664 931,5G Linux RAID
Ensuite création du raid logiciel (miroir : raid 1) avec les commandes suivantes :
#!/bin/bash
P1=/dev/nvme0n1p1
P2=/dev/nvme1n1p1
MD=/dev/md200
# Only if md exists
### mdadm --zero-superbloc ${P1}
### mdadm --zero-superbloc ${P2}
mdadm --create ${MD} --level=1 --raid-disks=2 ${P1} ${P2}
mdadm --examine --scan ${MD}
Remarque : au cours de la création de mon RAID 1 (miroir) j'ai constaté de très grosses variations dans la vitesse de synchronisation des disques, au plus bas un peu moins de 40Mo/seconde, au plus haut plus de 400Mo/sec ... mais cela dure "un bon moment", plus d'une heure ...
J'aime bien LVM et je transforme mon Raid en PV, pui j'y crée UN VG (ici VG_200) et un volume logique de 32Go pour effectuer quelques tests de vitesse.
Le tout se retrouve enfin accessible dans /dev/mapper/VG_200-TEST_200.
TEST A : un bon vieux DD depuis /dev/zero
dd if=/dev/zero of=/dev/mapper/VG_200-TEST_200 bs=65536 count=10240
10240+0 records in
10240+0 records out
671088640 bytes (671 MB, 640 MiB) copied, 1,23197 s, 545 MB/s
Tests avec un "vrai" filesystem, ici en ext4 :
mkfs -t ext4 /dev/VG_200/TEST_200
mount /dev/VG_200/TEST_200 /mnt
dd if=/dev/urandom of=/mnt/toto bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 19,1875 s, 350 MB/s
Le même test avec /dev/zero :
dd if=/dev/zero of=/mnt/toto bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 9,72867 s, 690 MB/s
Il semble que mon "/dev/urandom" soit nettement moins rapide que "/dev/zero".
En lecture maintenant en se servant du fichier généré avec "rarndom" et après avoir droppé les caches, sans ça c'est pas bon ! ...
dd if=/mnt/toto of=/dev/null bs=65536 count=102400
102400+0 records in
102400+0 records out
6710886400 bytes (6,7 GB, 6,2 GiB) copied, 8,33121 s, 806 MB/s
Un autre petit test avec "hdparm" :
hdparm -Tt /dev/mapper/VG_200-TEST_200
/dev/mapper/VG_200-TEST_200:
Timing cached reads: 36548 MB in 1.97 seconds = 18525.92 MB/sec
Timing buffered disk reads: 2194 MB in 3.00 seconds = 730.92 MB/sec
Un petit test avec "ioping" :
ioping -c 10 /mnt
--- /mnt (ext4 /dev/dm-0 31.2 GiB) ioping statistics ---
9 requests completed in 1.47 ms, 36 KiB read, 6.12 k iops, 23.9 MiB/s
generated 10 requests in 9.00 s, 40 KiB, 1 iops, 4.44 KiB/s
min/avg/max/mdev = 107.7 us / 163.5 us / 209.1 us / 36.7 us
Et sur un HDD "classique" (WDC WD20EARX-00P), lui aussi monté en RAID 1 :
--- /RAIDHOME (ext4 /dev/md0 393.4 GiB) ioping statistics ---
9 requests completed in 62.1 ms, 36 KiB read, 144 iops, 579.4 KiB/s
generated 10 requests in 9.02 s, 40 KiB, 1 iops, 4.43 KiB/s
min/avg/max/mdev = 131.4 us / 6.90 ms / 18.6 ms / 7.71 ms
Les résultats sont plutôt encourageants ...
ClickHouse est la base la plus récente du lot (publiée en juin 2016), elle a été prévue pour traiter de grandes quantités de données à une grande vitesse, c'est une base "orientée colonnes" et qui est disponible en Open Source.