Pengujian penyimpanan yang berguna mencocokkan ukuran operasi, pola akses, konkurensi, dan persyaratan daya tahan dengan aplikasi. Catat kondisi pengujian dan distribusi latensi, lalu konfirmasi hasilnya dengan pengukuran aplikasi.
Mulailah dengan pertanyaan penyimpanan, bukan skor
Tentukan apa yang perlu Anda ketahui sebelum menjalankan benchmark. Anda mungkin sedang menyelidiki commit database yang lambat, throughput distribusi file, atau proses build yang membuat banyak file kecil. Beban kerja tersebut tidak meminta disk melakukan hal yang sama. Salinan berurutan besar dapat terlihat mengesankan tetapi hanya sedikit menjelaskan tentang penundaan yang dialami oleh layanan yang melakukan pembacaan acak kecil.
NVMe dirancang untuk media non-volatil dan I/O paralel yang efisien, tetapi nama protokolnya tidak menjelaskan setiap bagian dari jalur penyimpanan yang dihosting. Virtualisasi, sistem file, kontensi sumber daya, dan aplikasi tetap penting. Tulis hipotesis pengujian seperti apakah latensi penyimpanan memperlambat operasi tertentu, alih-alih mencoba menghasilkan angka yang membuktikan seluruh server cepat.
Jelaskan beban kerja dalam istilah yang dapat direproduksi
Catat ukuran operasi, pola berurutan atau acak, campuran baca-tulis, jumlah job, dan kedalaman antrean. Sertakan ukuran dataset dan durasi pengujian. Dokumentasi fio menjelaskan kontrol beban kerja ini dan mesin I/O yang tersedia. Kedalaman yang dimaksudkan mungkin tidak tercapai oleh setiap mesin atau pengaturan, jadi baca perilaku yang dilaporkan serta konfigurasi yang Anda minta.
Simpan salinan deskripsi pengujian di samping hasilnya. Catat sistem operasi, sistem file, opsi mount, aktivitas layanan, dan kapasitas yang tersedia. Jika Anda membandingkan konfigurasi, ubah satu kondisi relevan pada satu waktu. Pengujian dengan pola akses atau konkurensi yang berbeda tidak dapat secara adil disajikan seolah-olah hanya media penyimpanan yang berubah.
| Pola aplikasi | Dimensi pengujian yang harus dijelaskan | Hasil yang harus diperiksa |
|---|---|---|
| Pengiriman file besar | Pembacaan berurutan dan klien bersamaan | Throughput berkelanjutan dan penggunaan CPU |
| Pencarian catatan | Pembacaan acak kecil dan konkurensi representatif | Distribusi latensi dan operasi yang selesai |
| Transaksi tahan lama | Persyaratan penulisan dan sinkronisasi | Penundaan terkait commit, bukan hanya kecepatan tulis yang di-buffer |
| Build atau ekstraksi | Operasi file kecil campuran | Durasi job end-to-end dan waktu tunggu I/O |
Kendalikan caching tanpa berpura-pura itu tidak penting
Dataset yang muat di memori mungkin sebagian besar mengukur perilaku cache setelah lintasan pertama. Itu bisa berguna jika aplikasi biasanya mendapat manfaat dari cache yang sama, tetapi tidak boleh dilabeli sebagai performa perangkat mentah. Pilih dengan sengaja apakah pengujian memeriksa jalur aplikasi yang hangat, dataset yang lebih dingin, atau mode I/O yang dimaksudkan untuk mengurangi efek buffering sistem operasi.
Dukungan Direct-I/O dan alignment bergantung pada platform dan mesin. Itu juga tidak secara otomatis menyatakan persyaratan daya tahan aplikasi atau menghilangkan setiap cache di stack. Nyatakan mode yang dipilih dengan jelas, dan hindari membandingkan pengujian yang di-buffer dengan pengujian tanpa buffer seolah-olah keduanya mewakili pekerjaan yang sama. Pisahkan interval pemanasan dan pengukuran jika itu membantu interpretasi.
Baca ekor latensi bersama throughput
Latensi rata-rata dapat menyembunyikan operasi lambat yang memengaruhi permintaan nyata. Periksa persentil yang dilaporkan dan jumlah sampel di belakangnya. Persentil tinggi menggambarkan batas di mana fraksi operasi yang diamati berada di bawahnya selama pengujian tersebut; itu bukan jaminan layanan permanen. Jalankan yang singkat atau tidak representatif memberikan bukti terbatas tentang periode produksi yang sibuk.
Kedalaman antrean yang lebih tinggi dapat meningkatkan throughput yang selesai sekaligus menambah waktu tunggu. Trade-off itu mungkin cocok untuk pemrosesan batch dan merugikan layanan interaktif. Bandingkan hasil pada konkurensi yang menyerupai aplikasi, dan pantau CPU serta tekanan I/O pada saat yang sama. Hentikan sebelum pengujian menciptakan gangguan yang tidak perlu bagi beban kerja lain yang berbagi lingkungan.
Jaga pengujian tetap sah dan tidak merusak
Gunakan direktori pengujian khusus atau volume sekali pakai yang telah disiapkan, dengan ruang kosong yang cukup dan rencana pembersihan yang eksplisit. Jangan pernah mengarahkan benchmark tulis ke perangkat mentah atau dataset produksi yang belum diverifikasi. Periksa target dan perilaku tulis alat sebelum memulai, dan mulailah dengan uji coba terbatas. I/O sintetis dapat menghabiskan kapasitas dan mengganggu layanan bahkan ketika tidak menimpa file yang berguna.
Untuk evaluasi yang menyerupai produksi, sepakati jendela pemeliharaan dan pertahankan pemantauan aplikasi. Gunakan data fabrikasi jika memungkinkan. Jangan menyimpulkan keandalan penyimpanan dari uji kecepatan: pemeriksaan integritas, backup, dan pemulihan adalah tugas terpisah. Perangkat yang menyelesaikan benchmark tetap memerlukan strategi pemulihan untuk penghapusan, kesalahan perangkat lunak, atau kehilangan mesin.
Tutup siklus dengan bukti aplikasi
Misalkan layanan laporan menghabiskan banyak waktunya menunggu pembacaan acak. Tim menguji pola baca yang representatif, lalu mengulangi laporan aktual terhadap data yang sebanding. Jika laporan membaik sementara pekerjaan lainnya tetap stabil, hasilnya mendukung hipotesis penyimpanan. Jika tidak, selidiki desain kueri, memori, atau dependensi lain alih-alih mengulangi pengujian sintetis yang lebih luas.
Pulse NVMe dan konfigurasi khusus terpilih mencantumkan penyimpanan NVMe di katalog SwissOctet. Label mereka adalah spesifikasi, bukan benchmark aplikasi yang dipublikasikan. Gunakan metode terkendali untuk mengevaluasi lingkungan yang dikirimkan dan simpan kondisinya bersama temuan. Keputusan menjadi lebih kuat ketika pengukuran penyimpanan dan hasil yang terlihat pengguna menjawab pertanyaan yang sama.
Daftar periksa praktis Anda.
- Tentukan pertanyaan aplikasi terlebih dahulu.
- Catat pola, ukuran blok, konkurensi, dan durasi.
- Nyatakan asumsi cache dan mode I/O.
- Periksa persentil latensi serta throughput.
- Gunakan target sekali pakai yang terverifikasi dan beban awal yang terbatas.
- Konfirmasi temuan dengan pengujian aplikasi.
Detail yang penting.
Apakah salinan berurutan cukup untuk membandingkan penyimpanan database?+
Biasanya tidak. Akses database dapat melibatkan pembacaan acak kecil, penulisan, dan sinkronisasi. Modelkan pola yang relevan dan verifikasi aplikasi aktual.
Apakah direct I/O membuktikan penulisan yang tahan lama?+
Tidak. Buffering dan daya tahan adalah hal yang terpisah. Cocokkan perilaku sinkronisasi yang dibutuhkan aplikasi.
Bisakah saya mempublikasikan satu pengujian sebagai kecepatan paket yang dijamin?+
Tidak. Publikasikan kondisi dan cakupannya. Hasil terukur dari satu kali pengujian bukan jaminan tingkat layanan atau performa di masa depan.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- fio: Dokumentasi penguji I/O fleksibel fio.readthedocs.io
- NVM Express: Ikhtisar spesifikasi dan FAQ nvmexpress.org
- Kernel Linux: Pressure Stall Information docs.kernel.org
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.