Mengapa NVMe saya lebih lambat dari SSD saya?

Pada artikel ini, kita akan melihat beberapa perbedaan dari 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 ini adalah pertanyaan jebakan: NVMe berasal dari segmen pengguna, dan SSD berasal dari segmen server.



Jelas, membandingkan produk dari segmen yang berbeda di lingkungan yang berbeda tidak benar, tetapi ini bukanlah jawaban teknis yang lengkap. Mari pelajari dasar-dasarnya, bereksperimen, dan jawab pertanyaannya.

Apa itu fsync dan di mana digunakan

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



Ada sejumlah tugas di mana Anda perlu memastikan bahwa perubahan dalam file ditulis ke drive, dan bukan di buffer perantara. Keyakinan ini dapat diperoleh dengan menggunakan panggilan sistem fsync yang sesuai dengan POSIX. Panggilan fsync memulai penulisan paksa dari buffer ke drive.



Mari kita tunjukkan efek buffer dengan contoh buatan dalam bentuk program 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, "42\n", 3); 

    return 0;
}

Komentar tersebut menjelaskan dengan baik urutan tindakan dalam program. Teks "jawaban atas pertanyaan utama kehidupan, Semesta dan semua itu" akan di-buffer oleh sistem operasi, dan jika Anda me-restart server dengan menekan tombol Reset selama "perhitungan", file akan kosong. Dalam contoh kami, kehilangan teks bukanlah masalah, jadi fsync tidak diperlukan. Basis data tidak berbagi optimisme ini.



Database adalah program kompleks yang bekerja secara bersamaan dengan banyak file, jadi mereka ingin memastikan bahwa data yang mereka tulis akan disimpan di drive, karena konsistensi data di dalam database bergantung padanya. Basis data dirancang untuk mencatat semua transaksi yang telah diselesaikan dan siap untuk pemadaman listrik kapan saja. Perilaku ini mengharuskan kita untuk menggunakan fsync dalam jumlah besar sepanjang waktu.

Apa yang Sering Dipengaruhi oleh Penggunaan fsync

Dengan I / O normal, sistem operasi mencoba mengoptimalkan komunikasinya dengan disk, karena drive eksternal paling lambat dalam hierarki memori. Oleh karena itu, sistem operasi mencoba untuk menulis data sebanyak mungkin dalam satu panggilan 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, PCIe 3.0 x4, ~ 31 Gbps.

Pengujian dilakukan pada Intel® Xeon® W-2255 yang menjalankan Ubuntu 20.04. Sysbench 1.0.18 digunakan untuk menguji disk. Satu partisi dibuat di drive, dengan format ext4. Persiapan ujian terdiri dari pembuatan 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 tes disajikan dalam tabel.

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

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

Jawaban untuk pertanyaan pertama sederhana: sysbench menghasilkan file yang diisi dengan angka nol. Dengan demikian, pengujian dilakukan lebih dari 100 gigabyte dari nol. Karena datanya sangat monoton dan dapat diprediksi, berbagai pengoptimalan OS ikut bermain, dan mereka secara signifikan mempercepat eksekusi.



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

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

Optimasi atau tebing

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

• program;
• perangkat keras.

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



Karena kinerja SSD lebih baik, dua asumsi dapat dibuat:

• disk dirancang untuk beban seperti itu;
• disk menggertak dan mengabaikan perintah.

Anda dapat melihat perilaku drive yang tidak jujur ​​jika Anda menjalankan uji kegagalan daya. Anda dapat memeriksanya menggunakan skrip diskchecker.pl , yang dibuat pada tahun 2005.



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

#   
./diskchecker.pl -l [port]

#   
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Setelah menjalankan skrip, perlu untuk menonaktifkan "klien" dan tidak mengembalikan daya selama beberapa menit. Sangatlah penting untuk memutuskan orang yang sedang diuji dari listrik, dan tidak hanya mematikan secara paksa. Setelah beberapa waktu, server dapat dihubungkan dan dimuat ke OS. Setelah OS melakukan boot, Anda perlu menjalankan diskchecker.pl lagi , tetapi dengan argumen verifikasi .

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

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



S4500 kami tidak menunjukkan kesalahan kehilangan daya, sehingga dapat dikatakan bahwa S4500 siap untuk memuat dengan banyak panggilan fsync.

Kesimpulan

Saat memilih disk atau menyelesaikan konfigurasi yang sudah jadi, ingat spesifik tugas yang perlu diselesaikan. Sekilas terlihat jelas bahwa NVMe, yaitu SSD dengan antarmuka PCIe, lebih cepat daripada SSD SATA "klasik". Namun, seperti yang kita pahami saat 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.