ProHoster > blog > administrasi > Mengapa NVMe saya lebih lambat dari SSD?

Mengapa NVMe saya lebih lambat dari SSD?

Mengapa NVMe saya lebih lambat dari SSD?
Pada artikel ini, kita akan melihat beberapa nuansa subsistem I/O dan pengaruhnya terhadap kinerja.

Beberapa minggu yang lalu saya mendapat pertanyaan mengapa NVMe di satu server lebih lambat dari SATA di server lain. Saya melihat karakteristik server dan menyadari bahwa itu adalah pertanyaan jebakan: NVMe dari segmen pengguna, dan SSD dari segmen server.

Jelas, tidak benar membandingkan produk dari segmen yang berbeda di lingkungan yang berbeda, tetapi ini bukanlah jawaban teknis yang lengkap. Kami akan mempelajari dasar-dasarnya, melakukan percobaan dan memberikan jawaban atas pertanyaan yang diajukan.

Apa itu fsync dan di mana digunakan

Untuk mempercepat pekerjaan dengan drive, data di-buffer, yaitu, disimpan dalam memori yang mudah menguap hingga muncul kesempatan yang nyaman untuk menyimpan konten buffer ke drive. Kriteria peluang ditentukan oleh sistem operasi dan karakteristik penggerak. Jika listrik padam, semua data dalam buffer akan hilang.

Ada sejumlah tugas di mana Anda perlu memastikan bahwa perubahan pada file ditulis ke drive, dan tidak terletak pada buffer perantara. Jaminan ini dapat diperoleh dengan menggunakan panggilan sistem fsync yang sesuai dengan POSIX. Panggilan fsync memaksa penulisan dari buffer ke drive.

Mari kita tunjukkan efek buffer dengan contoh buatan dalam bentuk program C singkat.

#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;
}

Komentar menjelaskan urutan tindakan dalam program dengan baik. Teks "jawaban atas pertanyaan utama kehidupan, alam semesta dan semua itu" akan disangga oleh sistem operasi, dan jika Anda me-restart server dengan menekan tombol Reset selama "perhitungan", file akan kosong. Dalam contoh kami, kehilangan teks tidak menjadi masalah, jadi fsync tidak diperlukan. Database tidak membagikan optimisme ini.

Basis data adalah program kompleks yang bekerja dengan banyak file pada saat yang sama, jadi mereka ingin memastikan bahwa data yang mereka tulis akan disimpan di drive, karena konsistensi data di dalam basis data bergantung pada hal ini. Basis data dirancang untuk mencatat semua transaksi yang telah selesai dan siap menghadapi pemadaman listrik kapan saja. Perilaku ini mengharuskan Anda untuk menggunakan fsync secara konstan dalam jumlah besar.

Apa yang memengaruhi seringnya penggunaan fsync

Dengan I/O normal, sistem operasi mencoba mengoptimalkan komunikasi disk, karena drive eksternal adalah yang paling lambat dalam hierarki memori. Oleh karena itu, sistem operasi mencoba menulis data sebanyak mungkin dalam satu akses ke drive.

Mari kita tunjukkan dampak penggunaan fsync dengan contoh spesifik. Kami memiliki SSD berikut sebagai subjek uji:

  • Intel® DC SSD S4500 480 GB, terhubung melalui SATA 3.2, 6 Gb/s;
  • Samsung 970 EVO Plus 500GB, terhubung melalui PCIe 3.0 x4, ~31 Gbps.

Pengujian dilakukan pada Intel® Xeon® W-2255 yang menjalankan Ubuntu 20.04. Untuk menguji disk, sysbench 1.0.18 digunakan. Disk memiliki satu partisi yang diformat sebagai ext4. Mempersiapkan tes adalah membuat file 100 GB:

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

Menjalankan tes:

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

Hasil pengujian disajikan dalam tabel.

Uji
Intel® S4500
Samsung 970 EVO+

Baca tanpa fsync, MiB/s
5734.89
9028.86

Menulis tanpa fsync, MiB/s
3823.26
6019.24

Membaca dengan fsync, MiB/s
37.76
3.27

Merekam dengan fsync, MiB/s
25.17
2.18

Sangat mudah untuk melihat bahwa NVMe dari segmen klien memimpin dengan percaya diri saat sistem operasi itu sendiri memutuskan cara bekerja dengan disk, dan kalah saat fsync digunakan. Ini menimbulkan dua pertanyaan:

  1. Mengapa kecepatan baca melebihi bandwidth fisik tautan dalam pengujian tanpa fsync?
  2. Mengapa SSD segmen server lebih baik dalam menangani sejumlah besar permintaan fsync?

Jawaban untuk pertanyaan pertama sederhana: sysbench menghasilkan file kosong. Dengan demikian, pengujian dilakukan lebih dari 100 gigabyte nol. Karena datanya sangat seragam dan dapat diprediksi, berbagai pengoptimalan OS ikut berperan, dan mereka mempercepat eksekusi secara signifikan.

Jika Anda mempertanyakan semua hasil sysbench, maka Anda dapat menggunakan 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

Uji
Intel® S4500
Samsung 970 EVO+

Baca tanpa fsync, MiB/s
45.5
178

Menulis tanpa fsync, MiB/s
30.4
119

Membaca dengan fsync, MiB/s
32.6
20.9

Merekam dengan fsync, MiB/s
21.7
13.9

Kecenderungan penurunan kinerja di NVMe saat menggunakan fsync terlihat jelas. Anda dapat melanjutkan ke pertanyaan kedua.

Optimalisasi atau gertakan

Sebelumnya kami mengatakan bahwa data disimpan dalam buffer, tetapi tidak menentukan yang mana, karena itu tidak penting. Bahkan sekarang kami tidak akan mempelajari seluk-beluk sistem operasi dan memilih dua jenis umum buffer:

  • program;
  • perangkat keras.

Buffer perangkat lunak mengacu pada buffer yang ada di sistem operasi, dan buffer perangkat keras mengacu pada memori yang mudah menguap dari pengontrol disk. Panggilan sistem fsync mengirimkan perintah ke drive untuk menulis data dari buffernya ke penyimpanan utama, tetapi tidak memiliki cara untuk mengontrol eksekusi perintah yang benar.

Karena kinerja SSD lebih baik, dua asumsi dapat dibuat:

  • disk dirancang untuk memuat rencana serupa;
  • disk "menggertak" dan mengabaikan perintah.

Perilaku drive yang tidak jujur ​​dapat diketahui jika Anda melakukan pengujian dengan kegagalan daya. Anda dapat memeriksa ini dengan skrip. diskchecker.pl, yang dibuat pada tahun 2005.

Skrip ini membutuhkan dua mesin fisik - "server" dan "klien". Klien menulis sejumlah kecil data ke drive yang diuji, memanggil fsync, dan mengirimkan informasi ke server tentang apa yang telah ditulis.

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

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

Setelah menjalankan skrip, Anda perlu mematikan energi "klien" dan tidak mengembalikan daya selama beberapa menit. Penting untuk memutuskan subjek uji dari listrik, dan tidak hanya melakukan pemadaman paksa. Setelah beberapa waktu, server dapat dihubungkan dan dimuat ke dalam OS. Setelah mem-boot OS, Anda harus memulai lagi diskchecker.pl, tetapi dengan argumen memeriksa.

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

Di akhir pemeriksaan, Anda akan melihat jumlah kesalahan. Jika nilainya 0, maka disk lulus ujian. Untuk mengecualikan kombinasi keadaan yang berhasil untuk disk, percobaan dapat diulangi beberapa kali.

S4500 kami tidak menunjukkan kesalahan kehilangan daya, yang artinya siap untuk memuat dengan banyak panggilan fsync.

Kesimpulan

Saat memilih disk atau seluruh konfigurasi yang sudah jadi, Anda harus mengingat secara spesifik tugas yang perlu diselesaikan. Sekilas, tampak jelas bahwa NVMe, yaitu SSD dengan antarmuka PCIe, lebih cepat daripada SSD SATA "klasik". Namun, seperti yang telah kita pahami hari ini, dalam kondisi tertentu dan dengan tugas tertentu mungkin tidak demikian.

Bagaimana Anda menguji komponen server saat menyewa dari penyedia IaaS?
Kami menunggu Anda di komentar.

Mengapa NVMe saya lebih lambat dari SSD?

Sumber: www.habr.com

Tambah komentar