Latences typiques des SSD
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bonsoir, Je suis en train de jouer avec des SSD Samsung 860 que je vais utiliser en cache ZFS (SLOG et L2ARC). Je m’intéresse tout particulièrement à la latence des io en écriture et j'ai des résultats qui me confondent ... Sur un Samsung SSD 860 EVO mSATA 500GB : dd if=/dev/zero of=/dev/sda bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 70,2861 s, 5,8 MB/s Soit une latence de 702 us ? Euuuh, c'est pas un peu élevé pour un SSD ? D'une magnitude ~ 100. Ca fait un poil mieux que 1000 iops ça. C'est encore pire sur un Samsung SSD 860 PRO 256GB : # dd if=/dev/zero of=/dev/sdc bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 96,5073 s, 4,2 MB/s Soit une latence de 960 us, presque 1ms ... Alors qu'il devrait être légèrement meilleur. Je suis arrivé là parce que j'utilise ces disques en ZIL/SLOG dans un pool ZFS que je mets en sync=always. Mes tests précédents ne montraient pas ça et avec des SSD plus vieux (toujours samsung et/ou ... Kingston). J'ai raté un firmware ou un paramètre quelconque de mon kernel ? Merci, Julien -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJazQ/qAAoJEOWv2Do/Mctu/8oQALAcv+aqd9OPhbnEGDwqYO78 F3U7nyhiS7Ia/9cfl9WfgBj8GJetbkDitwh5Go/hN6K+1POsJlzT/VF/OQKIqFsN pJdCy76mohdU3p8/xm6WMCAoHI97VtAE49Cq/w844hBs1j/QTlf6QhMniBFs+PeE XmtDFK/0Irm6niiHUWayzBb78Ifq1Pjw9jyDKQ8nrUWbFiDCBGQKBvyprTB3pym6 HAh7r6q+mfaOa2NUGwaeLw9W+9OA69L8UV3n0gGRzlRe2J6hbTRowxoBN2TlUs6s Z0k6uZkHM9eKVpozaCzfAZQCFLi/8FwN/J3xKXgGPb42/T6MlPl3GNN79YVLsBEz T7sTH8h6yjcA9dZe+13khtJHcIoEiJu/e3At8g6TH00pgxKtntYuh5YauSn1DJS6 UpkmnBHJZxHlpsqRUMErZtlKLvA2ddakab6HIJPHn+ATutiZFVdIFQF3+9LP2rqG nXCQo7pvECA4NxyDfTijoRbopS6DFsugqrBvapP43Ld/GaVuNUxxYxk3vMGR5EDT UoxPGxzZvWxRz0LFyE0emL7P2AkYS9KXfhaf+73FJ1C6q8vyvGwYOvPYXH5Vev8e nlaupVadtR2j2aOmxipR1YTYO40dE5RJ9H96xDFvnddcT/yOa+3B8dd8hzVmepiG 0d2IRZBZfJP3P76AIC7U =UJS1 -----END PGP SIGNATURE-----
Bonsoir, Note : je ne suis pas certain de ce que j'avance. Corrigez-moi si je me trompe :) La mesure des ~1ms de latence (temps entre la demande d'écriture et le début effectif de l'écriture) est correct. Sans réellement savoir comment mesurer le nombre d'IOPS, je dirais que le nombre d'IOPS atteignable est en utilisant plusieurs files de transfert ? Donc sur ton dd (séquentiel, sur un seul transfert continu d'octets 0 et en n'utilisant pas de cache), tu as un nombre faible d'<IOPS>. Mais sur N dd simultanés, obtiens-tu un nombre total d'IOPS de <IOPS>/N ou <IOPS> * N ? Je penche pour la deuxième option. (avec <IOPS> le nombre d'IOPS que tu mesure sur un seul dd) Bref, pour moi l'erreur est sur ta façon de compter le nombre d'IOPS ? Alexis Prodhomme Le 10/04/2018 à 21:26, Julien Escario a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Bonsoir, Je suis en train de jouer avec des SSD Samsung 860 que je vais utiliser en cache ZFS (SLOG et L2ARC).
Je m’intéresse tout particulièrement à la latence des io en écriture et j'ai des résultats qui me confondent ...
Sur un Samsung SSD 860 EVO mSATA 500GB : dd if=/dev/zero of=/dev/sda bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 70,2861 s, 5,8 MB/s
Soit une latence de 702 us ? Euuuh, c'est pas un peu élevé pour un SSD ? D'une magnitude ~ 100. Ca fait un poil mieux que 1000 iops ça.
C'est encore pire sur un Samsung SSD 860 PRO 256GB : # dd if=/dev/zero of=/dev/sdc bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 96,5073 s, 4,2 MB/s
Soit une latence de 960 us, presque 1ms ... Alors qu'il devrait être légèrement meilleur.
Je suis arrivé là parce que j'utilise ces disques en ZIL/SLOG dans un pool ZFS que je mets en sync=always.
Mes tests précédents ne montraient pas ça et avec des SSD plus vieux (toujours samsung et/ou ... Kingston).
J'ai raté un firmware ou un paramètre quelconque de mon kernel ?
Merci, Julien
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJazQ/qAAoJEOWv2Do/Mctu/8oQALAcv+aqd9OPhbnEGDwqYO78 F3U7nyhiS7Ia/9cfl9WfgBj8GJetbkDitwh5Go/hN6K+1POsJlzT/VF/OQKIqFsN pJdCy76mohdU3p8/xm6WMCAoHI97VtAE49Cq/w844hBs1j/QTlf6QhMniBFs+PeE XmtDFK/0Irm6niiHUWayzBb78Ifq1Pjw9jyDKQ8nrUWbFiDCBGQKBvyprTB3pym6 HAh7r6q+mfaOa2NUGwaeLw9W+9OA69L8UV3n0gGRzlRe2J6hbTRowxoBN2TlUs6s Z0k6uZkHM9eKVpozaCzfAZQCFLi/8FwN/J3xKXgGPb42/T6MlPl3GNN79YVLsBEz T7sTH8h6yjcA9dZe+13khtJHcIoEiJu/e3At8g6TH00pgxKtntYuh5YauSn1DJS6 UpkmnBHJZxHlpsqRUMErZtlKLvA2ddakab6HIJPHn+ATutiZFVdIFQF3+9LP2rqG nXCQo7pvECA4NxyDfTijoRbopS6DFsugqrBvapP43Ld/GaVuNUxxYxk3vMGR5EDT UoxPGxzZvWxRz0LFyE0emL7P2AkYS9KXfhaf+73FJ1C6q8vyvGwYOvPYXH5Vev8e nlaupVadtR2j2aOmxipR1YTYO40dE5RJ9H96xDFvnddcT/yOa+3B8dd8hzVmepiG 0d2IRZBZfJP3P76AIC7U =UJS1 -----END PGP SIGNATURE----- _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir, Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko. Sachant qu'un SSD fonctionne par bloc de 512 Ko à 4Mo (selon les modèles), qui doivent être effacés et réécrits pour écrire ces 4ko, cela veut dire que le SSD a effectivement ecrit en interne 52Go sur le test (surement un peu moins, parce qu'il y a des caches malins dans le SSD) Avec un bs=512k, le resultat devrait être bien meilleur. En vrai, il faudrait faire le test en se basant sur le cas d'usage effectif du cache ZFS, notamment la granularité d'écriture, pour avoir un test pertinent. Enfin, selon toute vraisemblance, le PRO est plus lent car il ne fait que 256 Go, il a sûrement des bloc plus gros, et donc il doit effacer plusieurs fois les mêmes blocs. Et les anciens disques devaient avoir des blocs plus petits, donc moins d'amplification d'écriture, et j'imagine que tu avais fait des tests avec des kernels pré-Meltdown, qui a un impact assez notable sur les IO Nicolas Le 10/04/2018 à 21:43, Alexis Prodhomme a écrit :
Bonsoir,
Note : je ne suis pas certain de ce que j'avance. Corrigez-moi si je me trompe :)
La mesure des ~1ms de latence (temps entre la demande d'écriture et le début effectif de l'écriture) est correct.
Sans réellement savoir comment mesurer le nombre d'IOPS, je dirais que le nombre d'IOPS atteignable est en utilisant plusieurs files de transfert ? Donc sur ton dd (séquentiel, sur un seul transfert continu d'octets 0 et en n'utilisant pas de cache), tu as un nombre faible d'<IOPS>. Mais sur N dd simultanés, obtiens-tu un nombre total d'IOPS de <IOPS>/N ou <IOPS> * N ? Je penche pour la deuxième option. (avec <IOPS> le nombre d'IOPS que tu mesure sur un seul dd)
Bref, pour moi l'erreur est sur ta façon de compter le nombre d'IOPS ?
Alexis Prodhomme
Le 10/04/2018 à 21:26, Julien Escario a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Bonsoir, Je suis en train de jouer avec des SSD Samsung 860 que je vais utiliser en cache ZFS (SLOG et L2ARC).
Je m’intéresse tout particulièrement à la latence des io en écriture et j'ai des résultats qui me confondent ...
Sur un Samsung SSD 860 EVO mSATA 500GB : dd if=/dev/zero of=/dev/sda bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 70,2861 s, 5,8 MB/s
Soit une latence de 702 us ? Euuuh, c'est pas un peu élevé pour un SSD ? D'une magnitude ~ 100. Ca fait un poil mieux que 1000 iops ça.
C'est encore pire sur un Samsung SSD 860 PRO 256GB : # dd if=/dev/zero of=/dev/sdc bs=4k count=100000 oflag=dsync 100000+0 enregistrements lus 100000+0 enregistrements écrits 409600000 bytes (410 MB, 391 MiB) copied, 96,5073 s, 4,2 MB/s
Soit une latence de 960 us, presque 1ms ... Alors qu'il devrait être légèrement meilleur.
Je suis arrivé là parce que j'utilise ces disques en ZIL/SLOG dans un pool ZFS que je mets en sync=always.
Mes tests précédents ne montraient pas ça et avec des SSD plus vieux (toujours samsung et/ou ... Kingston).
J'ai raté un firmware ou un paramètre quelconque de mon kernel ?
Merci, Julien
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJazQ/qAAoJEOWv2Do/Mctu/8oQALAcv+aqd9OPhbnEGDwqYO78 F3U7nyhiS7Ia/9cfl9WfgBj8GJetbkDitwh5Go/hN6K+1POsJlzT/VF/OQKIqFsN pJdCy76mohdU3p8/xm6WMCAoHI97VtAE49Cq/w844hBs1j/QTlf6QhMniBFs+PeE XmtDFK/0Irm6niiHUWayzBb78Ifq1Pjw9jyDKQ8nrUWbFiDCBGQKBvyprTB3pym6 HAh7r6q+mfaOa2NUGwaeLw9W+9OA69L8UV3n0gGRzlRe2J6hbTRowxoBN2TlUs6s Z0k6uZkHM9eKVpozaCzfAZQCFLi/8FwN/J3xKXgGPb42/T6MlPl3GNN79YVLsBEz T7sTH8h6yjcA9dZe+13khtJHcIoEiJu/e3At8g6TH00pgxKtntYuh5YauSn1DJS6 UpkmnBHJZxHlpsqRUMErZtlKLvA2ddakab6HIJPHn+ATutiZFVdIFQF3+9LP2rqG nXCQo7pvECA4NxyDfTijoRbopS6DFsugqrBvapP43Ld/GaVuNUxxYxk3vMGR5EDT UoxPGxzZvWxRz0LFyE0emL7P2AkYS9KXfhaf+73FJ1C6q8vyvGwYOvPYXH5Vev8e nlaupVadtR2j2aOmxipR1YTYO40dE5RJ9H96xDFvnddcT/yOa+3B8dd8hzVmepiG 0d2IRZBZfJP3P76AIC7U =UJS1 -----END PGP SIGNATURE----- _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) : dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s dd if=/dev/zero of=/dev/sdc bs=8k count=10000 oflag=dsync 81920000 bytes (82 MB, 78 MiB) copied, 9,79604 s, 8,4 MB/s dd if=/dev/zero of=/dev/sdc bs=512k count=10000 oflag=dsync 5242880000 bytes (5,2 GB, 4,9 GiB) copied, 33,53 s, 156 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=10000 oflag=dsync 10485760000 bytes (10 GB, 9,8 GiB) copied, 55,5287 s, 189 MB/s # dd if=/dev/zero of=/dev/sdc bs=4M count=10000 oflag=dsync 41943040000 bytes (42 GB, 39 GiB) copied, 188,248 s, 223 MB/s Donc pas vraiment mieux. Après, j'ai peur que la vitesse du bus SATA finisse par devenir le bottleneck ici (SATA 3Gbps, j'ai réservé mes ports 6Gbps pour le L2ARC).
En vrai, il faudrait faire le test en se basant sur le cas d'usage effectif du cache ZFS, notamment la granularité d'écriture, pour avoir un test pertinent.
# zfs get sync drbdpool/test drbdpool/test sync always inherited from drbdpool # dd if=/dev/zero of=/dev/zvol/drbdpool/test bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 93,0686 s, 440 kB/s OK, là, c'est vraiment tout pourri sur deux disques trad en mirroir. # zpool add -f drbdpool log /dev/sdc # dd if=/dev/zero of=/dev/zvol/drbdpool/test bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 12,2612 s, 3,3 MB/s C'est mieux mais loin d'être transcendant. En tout cas nettement plus faible que ce que j'ai pu tester dans des conditions similaires il y a tout juste un mois. Je ne sais plus trop quoi faire d'autre comme test à ce stade.
Et les anciens disques devaient avoir des blocs plus petits, donc moins d'amplification d'écriture, et j'imagine que tu avais fait des tests avec des kernels pré-Meltdown, qui a un impact assez notable sur les IO
Je n'ai plus les machine sous la main mais je les ai installées au mois de mars donc vraisemblablement avec des kernels qui étaient déjà patchés. Je vais voir si je peux remettre le main sur un disque des OS de l'époque qu'on a dû mettre de côté. Julien -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJazyy0AAoJEOWv2Do/Mctu+60QAKEvJ5vHrrVjK64IcdbxdPk0 Y5IAn1k0ZILBkRRZLV8galYiAfiTlWev7zozgmX8Shaw/kwPfH7X/+yt3d1VcUKT SxY18VdhL8CA3GK4AZ25HdIbJ/Qx3UaddT+zILuLAjs66eyQeN5/lqQfifYGGRU0 7/z1QMti5aAcr0DVpM+/PWXKzkT+xs4TBuBwZxh2tBrF/o6hef1RkqTvPccw+jRb OR8FsHBv8/W0oGqD7m/Yta3vk/kGbS5S093ZhOHUGq6Fgmj3X19UJGRXY3lak1R7 +lEzF2GzlJUCV7TYHVuZqGG6Rr6CcNzuKYTzUxH8P46x1yY5/0zvafuf9YRAjI8F OwrAXndTVnG2Pmjx4kEifLGkBu0Q7lLgee2aZV4MHHskAADc34YRkhCHdh1kiNoq ji7H1aQ7qk8KhsfIrYqnHsnzkCKyhUez8gQe0Wn4tH27y7f3asDe+cnYP+MLuUPu aXWdCsEZLS8U5je/oIx1yn1qyxvq93Kbs1USD84oB94KJwdmzJHxzz3aL8EjPAxO BqU0V81S8IKcPaaJzbzPsOYIDbQERMMaMmqpyT1ssImECkWy/5P7NyBr5DV+D5Xz +RUv+zXUtIoN2PxWbrawbqL0ofeHM2fnnYVFO6/idLXGR7w8UDyemUjg4Z5CMCyC FLHHXBlWYUja5KoZFTjk =TCCI -----END PGP SIGNATURE-----
Le 12/04/2018 à 11:54, Julien Escario a écrit :
Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) :
dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s
Update : j'ai fini par obtenir des résultats plutôt corrects avec la commande : # echo temporary write through > /sys/class/scsi_disk/3\:0\:0\:0/cache_type Là, ça poussait à 90Mo/s avec des blocks de 4k. Mais j'ai deux problèmes : * Je n'ai pas encore bien compris ce que fait cette commande ni si elle est dangereuse sur un ZIL * Revenir en write back fonctionne mais je ne peux plus revenir en 'temporary write through', même après un reboot. Ca me bouffe cette histoire. Julien
Salut, si tu veux quelques benchs de differents ssd en 4k + fsync, voici un article interessant sur ceph et les disques ssd pour le journal. https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is... ----- Mail original ----- De: "Julien Escario" <julien.escario@altinea.fr> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Jeudi 12 Avril 2018 16:29:18 Objet: Re: [FRsAG] Latences typiques des SSD Le 12/04/2018 à 11:54, Julien Escario a écrit :
Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) :
dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s
Update : j'ai fini par obtenir des résultats plutôt corrects avec la commande : # echo temporary write through > /sys/class/scsi_disk/3\:0\:0\:0/cache_type Là, ça poussait à 90Mo/s avec des blocks de 4k. Mais j'ai deux problèmes : * Je n'ai pas encore bien compris ce que fait cette commande ni si elle est dangereuse sur un ZIL * Revenir en write back fonctionne mais je ne peux plus revenir en 'temporary write through', même après un reboot. Ca me bouffe cette histoire. Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Très intéressant. A première vue, je n'aurais pas misé sur le bon cheval avec mes 850 PRO. Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel. Julien Le 15/04/2018 à 12:37, Alexandre DERUMIER a écrit :
Salut, si tu veux quelques benchs de differents ssd en 4k + fsync, voici un article interessant sur ceph et les disques ssd pour le journal.
https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is...
----- Mail original ----- De: "Julien Escario" <julien.escario@altinea.fr> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Jeudi 12 Avril 2018 16:29:18 Objet: Re: [FRsAG] Latences typiques des SSD
Le 12/04/2018 à 11:54, Julien Escario a écrit :
Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) :
dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s
Update : j'ai fini par obtenir des résultats plutôt corrects avec la commande : # echo temporary write through > /sys/class/scsi_disk/3\:0\:0\:0/cache_type
Là, ça poussait à 90Mo/s avec des blocks de 4k.
Mais j'ai deux problèmes : * Je n'ai pas encore bien compris ce que fait cette commande ni si elle est dangereuse sur un ZIL * Revenir en write back fonctionne mais je ne peux plus revenir en 'temporary write through', même après un reboot.
Ca me bouffe cette histoire.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel.
si je me souviens bien, oui, c'est exactement ca. c'est quand meme risqué, sauf si le ssd à un supercapacitor qui peux garder en mémoire les données en cas de coupure electrique. ----- Mail original ----- De: "Julien Escario" <julien.escario@altinea.fr> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Lundi 16 Avril 2018 10:48:03 Objet: Re: [FRsAG] Latences typiques des SSD Bonjour, Très intéressant. A première vue, je n'aurais pas misé sur le bon cheval avec mes 850 PRO. Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel. Julien Le 15/04/2018 à 12:37, Alexandre DERUMIER a écrit :
Salut, si tu veux quelques benchs de differents ssd en 4k + fsync, voici un article interessant sur ceph et les disques ssd pour le journal.
https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is...
----- Mail original ----- De: "Julien Escario" <julien.escario@altinea.fr> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Jeudi 12 Avril 2018 16:29:18 Objet: Re: [FRsAG] Latences typiques des SSD
Le 12/04/2018 à 11:54, Julien Escario a écrit :
Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) :
dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s
Update : j'ai fini par obtenir des résultats plutôt corrects avec la commande : # echo temporary write through > /sys/class/scsi_disk/3\:0\:0\:0/cache_type
Là, ça poussait à 90Mo/s avec des blocks de 4k.
Mais j'ai deux problèmes : * Je n'ai pas encore bien compris ce que fait cette commande ni si elle est dangereuse sur un ZIL * Revenir en write back fonctionne mais je ne peux plus revenir en 'temporary write through', même après un reboot.
Ca me bouffe cette histoire.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 16/04/2018 à 13:59, Alexandre DERUMIER a écrit :
Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel.
si je me souviens bien, oui, c'est exactement ca.
c'est quand meme risqué, sauf si le ssd à un supercapacitor qui peux garder en mémoire les données en cas de coupure electrique.
Dans l'absolu, oui, sauf que mon cas très spécifique, le ZFS est utilisé en backend pour du DRBD qui lui, assure une couche d'atomicité des écritures (protocol C). Mais clairement, je vais voir pour virer ces Samsung et utiliser des disques plus véloces. Le soucis, c'est que pas mal de SSD semblent tout simplement ignorer les CMD_FLUSH au niveau hard, même sans capa donc les tests peuvent montrer des jolis résultats mais avec un SSD grand public, je n'aurais jamais aucune garantie à ce niveau là. Par exemple : le Kingston V300 qui est donné à 200Mo/s dans le tableau de l'url que tu m'as filée. J'ai quand même un gros gros doute. Julien
Ce n'est pas ma spécialité, loin s'en faut, mais j'avais cru comprendre que la gamme Enterprise des SSD Samsung était un cran au-dessus en terme de perfs. Le 16 avr. 2018 à 14:37, Julien Escario a écrit :
Le 16/04/2018 à 13:59, Alexandre DERUMIER a écrit :
Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel.
si je me souviens bien, oui, c'est exactement ca.
c'est quand meme risqué, sauf si le ssd à un supercapacitor qui peux garder en mémoire les données en cas de coupure electrique.
Dans l'absolu, oui, sauf que mon cas très spécifique, le ZFS est utilisé en backend pour du DRBD qui lui, assure une couche d'atomicité des écritures (protocol C).
Mais clairement, je vais voir pour virer ces Samsung et utiliser des disques plus véloces.
Le soucis, c'est que pas mal de SSD semblent tout simplement ignorer les CMD_FLUSH au niveau hard, même sans capa donc les tests peuvent montrer des jolis résultats mais avec un SSD grand public, je n'aurais jamais aucune garantie à ce niveau là.
Par exemple : le Kingston V300 qui est donné à 200Mo/s dans le tableau de l'url que tu m'as filée. J'ai quand même un gros gros doute.
Julien <julien_escario.vcf>_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ce n'est pas ma spécialité, loin s'en faut, mais j'avais cru comprendre que la gamme Enterprise des SSD Samsung était un cran au-dessus en terme de perfs.
oui, les ssd entreprise, il y a forcement un supercapacitor et au niveau fsync, ca n'a rien à voir effectivement. Pour du journal zfs -> ssd enterprise quasiment obligé. (et attention au dwpd également) perso, en prod, j'utilise du Samsung PM863 , intel s3610 , intel s3710. aucun soucis au niveau perf (journal zfs && ceph) ----- Mail original ----- De: "David Ponzone" <david.ponzone@gmail.com> À: "Julien Escario" <julien.escario@altinea.fr> Cc: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Lundi 16 Avril 2018 14:41:27 Objet: Re: [FRsAG] Latences typiques des SSD Ce n'est pas ma spécialité, loin s'en faut, mais j'avais cru comprendre que la gamme Enterprise des SSD Samsung était un cran au-dessus en terme de perfs. Le 16 avr. 2018 à 14:37, Julien Escario a écrit :
Le 16/04/2018 à 13:59, Alexandre DERUMIER a écrit :
Il faut que je creuse ça encore, notamment sur ce que fait réellement le 'echo temporary write through'. Je penche sur un mécanisme qui fait ignorer les CMD_FLUSH par le kernel.
si je me souviens bien, oui, c'est exactement ca.
c'est quand meme risqué, sauf si le ssd à un supercapacitor qui peux garder en mémoire les données en cas de coupure electrique.
Dans l'absolu, oui, sauf que mon cas très spécifique, le ZFS est utilisé en backend pour du DRBD qui lui, assure une couche d'atomicité des écritures (protocol C).
Mais clairement, je vais voir pour virer ces Samsung et utiliser des disques plus véloces.
Le soucis, c'est que pas mal de SSD semblent tout simplement ignorer les CMD_FLUSH au niveau hard, même sans capa donc les tests peuvent montrer des jolis résultats mais avec un SSD grand public, je n'aurais jamais aucune garantie à ce niveau là.
Par exemple : le Kingston V300 qui est donné à 200Mo/s dans le tableau de l'url que tu m'as filée. J'ai quand même un gros gros doute.
Julien <julien_escario.vcf>_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 16/04/2018 à 16:54, Alexandre DERUMIER a écrit :
Ce n'est pas ma spécialité, loin s'en faut, mais j'avais cru comprendre que la gamme Enterprise des SSD Samsung était un cran au-dessus en terme de perfs.
oui, les ssd entreprise, il y a forcement un supercapacitor et au niveau fsync, ca n'a rien à voir effectivement.
Et une différence de prix qui se justifie difficilement, à part le DWPD qui est essentiellement dû à une surcapacité permettant une wear leveling plus propre.
Pour du journal zfs -> ssd enterprise quasiment obligé. (et attention au dwpd également)
perso, en prod, j'utilise du Samsung PM863 , intel s3610 , intel s3710. aucun soucis au niveau perf (journal zfs && ceph)
Y compris avec sync=always ? Mon problème pour le choix, c'est que les iops annoncés sont en QD32. A ce compte là, mon samsung 850 devrait poutrer à 36k iops en random write 4k. Mais dans les faits (sync=always), ça ne suit pas ... Du coup, je suis un peu perdu sur le choix. Julien
Hello, Je regarde ce thread et je me pose une question : as-tu essayé des SSD MVMe ? J'en ai quelques un chez moi au taf et ça fonce un max. Par contre, c'est sur je suis en ZFS sur du FreeBSD donc ça ne compte pas :) (ok je troll un peu, mais il est probable que certains trucs parasitent ton test... exemple le scheduler de ton linux : cfq/deadline/noop...). A bientôt, Xavier
Le 16/04/2018 à 21:53, Xavier Beaudouin a écrit :
Hello,
Je regarde ce thread et je me pose une question : as-tu essayé des SSD MVMe ?
J'en ai quelques un chez moi au taf et ça fonce un max.
Neeeeed. C'est pas sympa de faire envie : je n'ai pas les ports pour ça encore. Ca sera pour les prochaines machines. Pour l'instant, je suis bloqué avec du SATA (même pas SAS). J'avais même plutôt envie de passer sur des SLOG au format PCIe. A priori, les perfs du nvme seront les mêmes puisque nvme, c'est juste un format différent de port pour du pcie.
Par contre, c'est sur je suis en ZFS sur du FreeBSD donc ça ne compte pas :) (ok je troll un peu, mais il est probable que certains trucs parasitent ton test... exemple le scheduler de ton linux : cfq/deadline/noop...).
Bah justement, j'ai lu (je ne sais plus où) hier que BSD (pas certain de la variante) ignore tout simplement les D_SYNC. Du coup, j'ai une conf à peu près similaire avec 'temporary write through' et les perf sont correctes. Mais encore une fois, le sujet est touchy à comprendre et je me base sur ce que je lis ici et là, parfois contradictoire, souvent incomplet. Donc je peux raconter des âneries. Et j'ai testé cfg/deadline/noop, ça faisait partie de ma liste de params à tester avec DRBD (cf doc DRBD9). Julien
Hello,
Je regarde ce thread et je me pose une question : as-tu essayé des SSD MVMe ?
J'en ai quelques un chez moi au taf et ça fonce un max.
j'ai un cluster ceph 3 nodes, 24 x 3,2TB nvme au total ( HGST Ultrastar SN200 3DWPD 3.2TB). Ca torche pas mal en effet :) (bencher à 1 million d'ios 4k en read, mais je suis limité en cpu). Pas testé avec zfs par contre. ----- Mail original ----- De: "Xavier Beaudouin" <kiwi@oav.net> À: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Lundi 16 Avril 2018 21:53:41 Objet: Re: [FRsAG] Latences typiques des SSD Hello, Je regarde ce thread et je me pose une question : as-tu essayé des SSD MVMe ? J'en ai quelques un chez moi au taf et ça fonce un max. Par contre, c'est sur je suis en ZFS sur du FreeBSD donc ça ne compte pas :) (ok je troll un peu, mais il est probable que certains trucs parasitent ton test... exemple le scheduler de ton linux : cfq/deadline/noop...). A bientôt, Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (6)
-
Alexandre DERUMIER -
Alexis Prodhomme -
David Ponzone -
Julien Escario -
Nicolas Charles -
Xavier Beaudouin