ເປັນຫຍັງ NVMe ຂອງຂ້ອຍຈຶ່ງຊ້າກວ່າ SSD?

ໃນບົດຄວາມນີ້ພວກເຮົາຈະເບິ່ງບາງສ່ວນຂອງ nuances ຂອງລະບົບຍ່ອຍ I / O ແລະຜົນກະທົບຂອງເຂົາເຈົ້າກ່ຽວກັບການປະຕິບັດ.

ສອງສາມອາທິດກ່ອນຫນ້ານີ້ຂ້ອຍໄດ້ປະເຊີນກັບຄໍາຖາມທີ່ວ່າ NVMe ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງຊ້າກວ່າ SATA ໃນເຄື່ອງອື່ນ. ຂ້າພະເຈົ້າໄດ້ເບິ່ງສະເພາະຂອງເຄື່ອງແມ່ຂ່າຍແລະຮູ້ວ່ານີ້ແມ່ນຄໍາຖາມທີ່ຫຍຸ້ງຍາກ: NVMe ແມ່ນມາຈາກພາກສ່ວນຜູ້ໃຊ້, ແລະ SSD ແມ່ນມາຈາກພາກສ່ວນຂອງເຄື່ອງແມ່ຂ່າຍ.

ແນ່ນອນ, ມັນບໍ່ຍຸດຕິທໍາທີ່ຈະປຽບທຽບຜະລິດຕະພັນຈາກພາກສ່ວນຕ່າງໆໃນສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ, ແຕ່ນີ້ບໍ່ແມ່ນຄໍາຕອບດ້ານວິຊາການທີ່ສົມບູນ. ໃຫ້ພວກເຮົາສຶກສາພື້ນຖານ, ດໍາເນີນການທົດລອງແລະໃຫ້ຄໍາຕອບຕໍ່ຄໍາຖາມທີ່ຕັ້ງຂຶ້ນ.

fsync ແມ່ນຫຍັງ ແລະມັນໃຊ້ຢູ່ໃສ?

ເພື່ອເລັ່ງການເຮັດວຽກກັບໄດຣຟ໌, ຂໍ້ມູນຈະຖືກ buffered, ນັ້ນແມ່ນ, ເກັບຮັກສາໄວ້ໃນຫນ່ວຍຄວາມຈໍາທີ່ປ່ຽນແປງຈົນກ່ວາໂອກາດທີ່ສະດວກຈະນໍາສະເຫນີຕົວຂອງມັນເອງເພື່ອຊ່ວຍປະຢັດເນື້ອໃນຂອງ buffer ເຂົ້າໄປໃນໄດ. ເງື່ອນໄຂສໍາລັບ "ໂອກາດ" ແມ່ນຖືກກໍານົດໂດຍລະບົບປະຕິບັດການແລະຄຸນລັກສະນະຂອງໄດ. ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ໄຟ​ຟ້າ​ລົ້ມ​ເຫຼວ​, ຂໍ້​ມູນ​ທັງ​ຫມົດ​ທີ່​ຢູ່​ໃນ buffer ຈະ​ສູນ​ເສຍ​ໄປ​.

ມີວຽກງານຈໍານວນຫນຶ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າການປ່ຽນແປງໄຟລ໌ຖືກຂຽນໄວ້ໃນໄດແລະບໍ່ແມ່ນຢູ່ໃນ buffer ກາງ. ການຮັບປະກັນນີ້ສາມາດໄດ້ຮັບໂດຍການໃຊ້ການໂທລະບົບ fsync ທີ່ສອດຄ່ອງກັບ POSIX. ການໂທຫາ fsync ບັງຄັບໃຫ້ຂຽນຈາກ buffer ໄປຫາໄດ.

ໃຫ້ສະແດງໃຫ້ເຫັນຜົນກະທົບຂອງ buffers ດ້ວຍຕົວຢ່າງປອມໃນຮູບແບບຂອງໂປແກຼມສັ້ນໃນ 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;
}

ຄໍາເຫັນອະທິບາຍໄດ້ດີລໍາດັບການປະຕິບັດໃນໂຄງການ. ຂໍ້ຄວາມ "ຄໍາຕອບຂອງຄໍາຖາມຕົ້ນຕໍຂອງຊີວິດ, ຈັກກະວານແລະສິ່ງທັງຫມົດ" ຈະຖືກຂັດຂວາງໂດຍລະບົບປະຕິບັດການ, ແລະຖ້າທ່ານ restart server ໂດຍການກົດປຸ່ມ Reset ໃນລະຫວ່າງ "ການຄິດໄລ່", ໄຟລ໌ຈະຫວ່າງເປົ່າ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ການສູນເສຍຂໍ້ຄວາມບໍ່ແມ່ນບັນຫາ, ດັ່ງນັ້ນ fsync ແມ່ນບໍ່ຈໍາເປັນ. ຖານຂໍ້ມູນບໍ່ໄດ້ແບ່ງປັນແງ່ດີນີ້.

ຖານຂໍ້ມູນແມ່ນໂຄງການທີ່ສະລັບສັບຊ້ອນທີ່ເຮັດວຽກພ້ອມກັນກັບຫຼາຍໄຟລ໌, ດັ່ງນັ້ນພວກເຂົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນທີ່ເຂົາເຈົ້າຂຽນຈະຖືກບັນທຶກໄວ້ໃນໄດ, ເພາະວ່າຄວາມສອດຄ່ອງຂອງຂໍ້ມູນພາຍໃນຖານຂໍ້ມູນແມ່ນຂຶ້ນກັບນີ້. ຖານຂໍ້ມູນຖືກອອກແບບມາເພື່ອບັນທຶກການເຮັດທຸລະກໍາທີ່ສໍາເລັດທັງຫມົດແລະພ້ອມທີ່ຈະສູນເສຍພະລັງງານໄດ້ທຸກເວລາ. ພຶດຕິກໍານີ້ຮຽກຮ້ອງໃຫ້ມີການນໍາໃຊ້ fsync ຢ່າງຕໍ່ເນື່ອງໃນປະລິມານຫຼາຍ.

ຜົນກະທົບຂອງການໃຊ້ fsync ເລື້ອຍໆແມ່ນຫຍັງ?

ໃນ​ລະ​ຫວ່າງ I/O ປົກ​ກະ​ຕິ​, ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ​ພະ​ຍາ​ຍາມ​ປັບ​ການ​ສື່​ສານ​ກັບ​ແຜ່ນ​, ເນື່ອງ​ຈາກ​ວ່າ​ການ​ຂັບ​ພາຍ​ນອກ​ແມ່ນ​ຊ້າ​ທີ່​ສຸດ​ໃນ​ລໍາ​ດັບ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​. ດັ່ງນັ້ນ, ລະບົບປະຕິບັດການພະຍາຍາມຂຽນຂໍ້ມູນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ໃນຫນຶ່ງການເຂົ້າເຖິງໄດ.

ໃຫ້ສະແດງໃຫ້ເຫັນຜົນກະທົບຂອງການນໍາໃຊ້ fsync ດ້ວຍຕົວຢ່າງສະເພາະ. ພວກເຮົາມີ SSDs ຕໍ່ໄປນີ້ເປັນການທົດສອບຂັບ:

• Intel® DC SSD S4500 480 GB, ເຊື່ອມຕໍ່ຜ່ານ SATA 3.2, 6 Gbit/s;
• Samsung 970 EVO Plus 500GB, ເຊື່ອມຕໍ່ຜ່ານ PCIe 3.0 x4, ~31 Gbit/s.

ການທົດສອບແມ່ນດໍາເນີນຢູ່ໃນ Intel® Xeon® W-2255 ທີ່ໃຊ້ Ubuntu 20.04. Sysbench 1.0.18 ຖືກນໍາໃຊ້ເພື່ອທົດສອບແຜ່ນ. ຫນຶ່ງໃນພາທິຊັນໄດ້ຖືກສ້າງຂື້ນຢູ່ໃນແຜ່ນ, ຟໍແມັດເປັນ ext4. ການກະກຽມສໍາລັບການທົດສອບກ່ຽວຂ້ອງກັບການສ້າງໄຟລ໌ 100 GB:

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

ການ​ທົດ​ສອບ​ການ​ແລ່ນ​:

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

ຜົນໄດ້ຮັບການທົດສອບແມ່ນນໍາສະເຫນີຢູ່ໃນຕາຕະລາງ.

ທົດສອບ
Intel® S4500
Samsung 970 EVO+

ການອ່ານໂດຍບໍ່ມີການ fsync, MiB/s
5734.89
9028.86

ການບັນທຶກໂດຍບໍ່ມີການ fsync, MiB/s
3823.26
6019.24

ການອ່ານດ້ວຍ fsync, MiB/s
37.76
3.27

ການບັນທຶກດ້ວຍ fsync, MiB/s
25.17
2.18

ມັນງ່າຍທີ່ຈະເຫັນວ່າ NVMe ຈາກພາກສ່ວນລູກຄ້າມີຄວາມຫມັ້ນໃຈໃນການນໍາພາໃນເວລາທີ່ລະບົບປະຕິບັດການຕົວເອງຕັດສິນໃຈເຮັດວຽກກັບແຜ່ນ, ແລະສູນເສຍເມື່ອ fsync ຖືກນໍາໃຊ້. ນີ້ເຮັດໃຫ້ສອງຄໍາຖາມ:

1. ເປັນຫຍັງຄວາມໄວການອ່ານໃນການທົດສອບໂດຍບໍ່ມີ fsync ເກີນແບນວິດທາງດ້ານຮ່າງກາຍຂອງຊ່ອງທາງ?
2. ເປັນຫຍັງພາກສ່ວນເຊີຟເວີ SSD ຈຶ່ງດີກວ່າໃນການຈັດການການຮ້ອງຂໍ fsync ຈໍານວນຫລາຍ?

ຄໍາຕອບຂອງຄໍາຖາມທໍາອິດແມ່ນງ່າຍດາຍ: sysbench ສ້າງໄຟລ໌ທີ່ເຕັມໄປດ້ວຍສູນ. ດັ່ງນັ້ນ, ການທົດສອບໄດ້ຖືກປະຕິບັດຫຼາຍກວ່າ 100 gigabyte ຂອງສູນ. ເນື່ອງຈາກຂໍ້ມູນມີຄວາມເປັນເອກະພາບ ແລະສາມາດຄາດເດົາໄດ້ຫຼາຍ, ການເພີ່ມປະສິດທິພາບຂອງ OS ຕ່າງໆກໍ່ເຂົ້າມາຫຼິ້ນ ແລະເລັ່ງການປະຕິບັດຢ່າງໃຫຍ່ຫຼວງ.

ຖ້າທ່ານຖາມຜົນໄດ້ຮັບ sysbench ທັງຫມົດ, ທ່ານສາມາດນໍາໃຊ້ 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

ທົດສອບ
Intel® S4500
Samsung 970 EVO+

ການອ່ານໂດຍບໍ່ມີການ fsync, MiB/s
45.5
178

ການບັນທຶກໂດຍບໍ່ມີການ fsync, MiB/s
30.4
119

ການອ່ານດ້ວຍ fsync, MiB/s
32.6
20.9

ການບັນທຶກດ້ວຍ fsync, MiB/s
21.7
13.9

ແນວໂນ້ມສໍາລັບການປະຕິບັດ NVMe ທີ່ຈະຫຼຸດລົງໃນເວລາທີ່ການນໍາໃຊ້ fsync ແມ່ນເຫັນໄດ້ຊັດເຈນ. ເຈົ້າສາມາດໄປຕອບຄຳຖາມທີສອງໄດ້.

ການເພີ່ມປະສິດທິພາບ ຫຼື bluff

ກ່ອນຫນ້ານີ້, ພວກເຮົາບອກວ່າຂໍ້ມູນຖືກເກັບໄວ້ໃນ buffer, ແຕ່ພວກເຮົາບໍ່ໄດ້ລະບຸວ່າອັນໃດ, ເພາະວ່ານີ້ບໍ່ສໍາຄັນ. ເຖິງແມ່ນວ່າໃນປັດຈຸບັນພວກເຮົາຈະບໍ່ delve ເຂົ້າໄປໃນ intricacies ຂອງລະບົບປະຕິບັດການແລະຈະຊີ້ໃຫ້ເຫັນສອງປະເພດຂອງ buffers ທົ່ວໄປ:

• ໂຄງການ;
• ຮາດແວ.

ບັຟເຟີຊອບແວຫມາຍເຖິງ buffers ທີ່ມີຢູ່ໃນລະບົບປະຕິບັດການ, ແລະຮາດແວ buffer ຫມາຍເຖິງຄວາມຈໍາທີ່ບໍ່ປ່ຽນແປງຂອງຕົວຄວບຄຸມແຜ່ນ. ການໂທຫາລະບົບ fsync ສົ່ງຄໍາສັ່ງໄປຫາໄດເພື່ອຂຽນຂໍ້ມູນຈາກ buffer ຂອງມັນໄປຫາບ່ອນເກັບຂໍ້ມູນຕົ້ນຕໍ, ແຕ່ບໍ່ມີວິທີການກວດສອບວ່າຄໍາສັ່ງຖືກປະຕິບັດຢ່າງຖືກຕ້ອງ.

ເນື່ອງຈາກ SSD ສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດ, ສອງສົມມຸດຕິຖານສາມາດເຮັດໄດ້:

• ແຜ່ນໄດ້ຖືກອອກແບບສໍາລັບການໂຫຼດທີ່ຄ້າຍຄືກັນ;
• ແຜ່ນ "bluffs" ແລະບໍ່ສົນໃຈຄໍາສັ່ງ.

ພຶດຕິກໍາທີ່ບໍ່ຊື່ສັດຂອງໄດສາມາດສັງເກດເຫັນໄດ້ຖ້າທ່ານເຮັດການທົດສອບການສູນເສຍພະລັງງານ. ທ່ານສາມາດກວດເບິ່ງນີ້ດ້ວຍສະຄິບ diskchecker.pl, ມັນ​ແມ່ນ ສ້າງຕັ້ງຂຶ້ນ ໃນປີ 2005.

ສະຄຣິບນີ້ຕ້ອງການສອງເຄື່ອງຈັກ - "ເຄື່ອງແມ່ຂ່າຍ" ແລະ "ລູກຄ້າ". ລູກຄ້າຂຽນຂໍ້ມູນຈໍານວນນ້ອຍໆໃສ່ແຜ່ນທີ່ຢູ່ພາຍໃຕ້ການທົດສອບ, ໂທຫາ fsync, ແລະສົ່ງຂໍ້ມູນໄປຫາເຄື່ອງແມ່ຂ່າຍກ່ຽວກັບສິ່ງທີ່ຂຽນ.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

ຫຼັງຈາກແລ່ນສະຄຣິບແລ້ວ, ທ່ານຕ້ອງປິດໄຟໃຫ້ກັບ "ລູກຂ່າຍ" ແລະຢ່າສົ່ງໄຟຄືນເປັນເວລາຫຼາຍນາທີ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຕັດການເຊື່ອມຕໍ່ຜູ້ທີ່ຖືກທົດສອບຈາກໄຟຟ້າ, ແລະບໍ່ພຽງແຕ່ປະຕິບັດການປິດຢ່າງຫນັກແຫນ້ນ. ຫຼັງຈາກເວລາໃດຫນຶ່ງ, ເຄື່ອງແມ່ຂ່າຍສາມາດເຊື່ອມຕໍ່ແລະໂຫລດເຂົ້າໄປໃນ OS. ຫຼັງ​ຈາກ​ການ​ໂຫຼດ OS ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ມັນ​ອີກ​ເທື່ອ​ຫນຶ່ງ​ diskchecker.pl, ແຕ່ມີການໂຕ້ຖຽງ ກວດສອບ.

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

ໃນຕອນທ້າຍຂອງການກວດສອບທ່ານຈະເຫັນຈໍານວນຂໍ້ຜິດພາດ. ຖ້າມີ 0, ຫຼັງຈາກນັ້ນແຜ່ນໄດ້ຜ່ານການທົດສອບ. ເພື່ອຍົກເວັ້ນການບັງເອີນທີ່ໂຊກດີສໍາລັບແຜ່ນ, ການທົດລອງສາມາດເຮັດຊ້ໍາອີກຫຼາຍຄັ້ງ.

S4500 ຂອງພວກເຮົາບໍ່ສະແດງຂໍ້ຜິດພາດໃນເວລາທີ່ສູນເສຍພະລັງງານ, ຊຶ່ງຫມາຍຄວາມວ່າມັນກຽມພ້ອມສໍາລັບວຽກທີ່ມີການໂທ fsync ຫຼາຍ.

ສະຫລຸບ

ເມື່ອເລືອກແຜ່ນຫຼືການຕັ້ງຄ່າທີ່ກຽມພ້ອມທັງຫມົດ, ທ່ານຄວນຈື່ຈໍາສະເພາະຂອງບັນຫາທີ່ຕ້ອງການແກ້ໄຂ. ຢູ່ glance ທໍາອິດ, ມັນເບິ່ງຄືວ່າ NVMe, ນັ້ນແມ່ນ, SSD ທີ່ມີການໂຕ້ຕອບ PCIe, ແມ່ນໄວກວ່າ "ຄລາສສິກ" SATA SSD. ຢ່າງໃດກໍຕາມ, ດັ່ງທີ່ພວກເຮົາໄດ້ຮຽນຮູ້ໃນມື້ນີ້, ໃນເງື່ອນໄຂສະເພາະແລະວຽກງານບາງຢ່າງນີ້ອາດຈະບໍ່ເປັນກໍລະນີ.

ເຈົ້າທົດສອບອົງປະກອບເຊີບເວີແນວໃດເມື່ອເຊົ່າຈາກຜູ້ໃຫ້ບໍລິການ IaaS?
ພວກເຮົາລໍຖ້າທ່ານຢູ່ໃນຄໍາເຫັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com