NVMe vs SSD SATA untuk VPS, Apakah Berpengaruh?

Apakah NVMe berpengaruh pada VPS?

NVMe berpengaruh pada VPS jika perangkat lunak Anda melakukan banyak operasi baca dan tulis kecil serta menunggu setiap operasi selesai. Dampaknya sangat kecil untuk situs yang menyajikan halaman dari cache atau program yang sebagian besar waktunya menunggu jaringan. Media penyimpanan hanya salah satu faktor. Hypervisor yang berada di antara Anda dan disk, serta guest lain yang berbagi host yang sama, menentukan batas performa yang sebenarnya Anda peroleh.

Perubahan yang Dibawa NVMe dan Hal yang Tidak Berubah

NVMe (non-volatile memory express) bukan jenis memori flash. NVMe adalah protokol dan koneksi yang digunakan untuk mengakses flash. Perangkat NVMe terhubung melalui jalur PCIe (peripheral component interconnect express) dan menggunakan NVMe. SSD SATA (serial ATA) terhubung melalui koneksi SATA dan menggunakan AHCI (advanced host controller interface). Chip memori yang menyimpan byte Anda dapat sama pada keduanya.

Ada dua hal yang berbeda. Keduanya berkaitan dengan jalur perintah, bukan dengan media penyimpanannya.

Antrean. AHCI memberi kernel satu antrean perintah yang menampung 32 perintah. NVMe memungkinkan ribuan antrean. Dalam praktiknya, biasanya tersedia satu antrean per inti CPU, dan setiap antrean jauh lebih dalam daripada 32. Satu proses yang membaca satu blok setiap kali tidak akan melihat perbedaan tersebut. Basis data dengan 64 operasi baca yang tertunda dapat melihatnya: pada SATA, permintaan ke-33 menunggu slot antrean sebelum perangkat menerimanya, sedangkan perangkat NVMe menerima semuanya dan memprosesnya secara bersamaan.

Lebar koneksi. Koneksi SATA III berjalan pada 6 Gbit/s, atau sekitar 550 MB/s untuk data aktual setelah overhead protokol. Ini adalah batas tetap, apa pun flash yang berada di belakangnya. Empat jalur PCIe membawa beberapa gigabyte per detik, sehingga koneksi tidak lagi menjadi batasnya.

Latensi biasanya tidak sesuai dengan ekspektasi. Pada kedalaman antrean 1, yang berarti satu permintaan sedang diproses, SSD SATA menjawab pembacaan 4k dalam sekitar 100 hingga 150 mikrodetik. NVMe menjawabnya dalam sekitar 80 hingga 100 mikrodetik. Keduanya cepat, dan tidak ada aplikasi yang Anda jalankan akan merasakan perbedaan tersebut untuk satu permintaan. Perbedaannya muncul saat konkurensi meningkat. Kedalaman antrean, yaitu jumlah permintaan yang sedang diproses secara bersamaan, menentukan apakah kedua media tersebut tampak serupa atau sangat berbeda.

Penyimpanan blok melalui jaringan adalah kelas ketiga dengan karakteristik yang berbeda. Operasi tulis melewati jaringan menuju klaster penyimpanan dan hanya dikonfirmasi setelah klaster menyimpan data tersebut. Karena itu, latansinya diukur dalam milidetik, bukan mikrodetik. Imbalannya adalah durabilitas: volume tetap ada meskipun host yang terhubung dengannya tidak lagi tersedia, dan volume tersebut dapat dibuat snapshot serta diubah ukurannya.

Angka yang umum dipublikasikan: NVMe, SATA SSD, dan penyimpanan jaringan

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Perangkat NVMe lokal umumnya dinyatakan memiliki 184,000 IOPS baca acak 4k (operasi input/output per detik) pada kedalaman antrean 32. Pengujian yang sama pada SATA SSD biasanya menghasilkan sekitar 90,000, karena dibatasi oleh satu antrean AHCI dan koneksi 6 Gbit/s. Penyimpanan blok jaringan biasanya dibatasi oleh penyedia, bukan oleh perangkat kerasnya, dan 12,500 merupakan batas atas yang umum didokumentasikan.

Latensi menunjukkan hal yang sama dalam satuan yang dirasakan pengguna. Latensi baca p99, yaitu 1 persen permintaan yang paling lambat, sekitar 0.4 ms pada NVMe lokal dan 1.2 ms pada SATA. Jika jaringan berada dalam jalur akses, nilainya menjadi 6.5 ms, lebih dari sepuluh kali angka NVMe.

Baca berurutan menunjukkan kesenjangan terbesar dan paling tidak berguna: 3,400 MB/s dibandingkan dengan 550 MB/s. Hampir tidak ada proses pada server yang membaca satu file besar dari awal hingga akhir dengan kecepatan penuh. Kolom acak dan kolom latensi lebih menggambarkan operasi database, antrean email, atau pengelola paket.

Beban kerja yang merasakan dampak disk

Satu aturan menjelaskan semuanya: beban kerja hanya merasakan dampak disk ketika menunggu disk. Linux menyimpan data file yang baru digunakan di RAM, dalam cache halaman, sehingga pembacaan kedua suatu file tidak pernah mencapai media penyimpanan. Jika working set, yaitu data yang benar-benar digunakan, muat di RAM, pembacaan berubah menjadi pembacaan memori setelah lintasan pertama. Penulisan berbeda. Setiap penulisan yang di-flush oleh aplikasi dengan fsync() harus berada di media penyimpanan stabil sebelum aplikasi dapat melanjutkan.

Pekerjaan yang melakukan commit. PostgreSQL, MySQL, dan SQLite memanggil fsync() atau fdatasync() saat commit, dan setiap commit menunggu respons perangkat. Oleh karena itu, laju commit satu koneksi ditentukan oleh latensi penulisan, bukan bandwidth. Perangkat yang melakukan flush dalam 0.2 ms memungkinkan jauh lebih banyak commit per detik daripada perangkat yang memerlukan 5 ms, dan throughput sebesar apa pun tidak mengubah hal itu. MySQL mencatatnya dalam error log ketika flush tidak dapat mengimbangi laju penulisan:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL melaporkannya dalam baris checkpoint. Nilai sync= yang besar menunjukkan bahwa flush itu sendiri berjalan lambat:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Pekerjaan yang mengakses banyak file kecil. Setiap file melibatkan operasi metadata yang tidak diperlukan oleh satu pembacaan sekuensial berukuran besar. npm install, git clone dari repositori besar, membongkar image container, penyimpanan email Maildir, dan pencadangan yang menelusuri tree besar semuanya menghabiskan waktu untuk akses acak berukuran kecil. Tugas pencadangan restic di VPS membaca dan melakukan hashing pada setiap file yang belum pernah dilihat sebelumnya, sehingga waktu pencadangan yang berlalu untuk satu juta file sangat berkaitan dengan latensi pembacaan acak. Hal yang sama berlaku untuk du -sh, yang hanya membaca metadata.

Database yang ukurannya melebihi kapasitas RAM juga termasuk dalam kategori ini. Setelah indeks tidak lagi muat di cache halaman, setiap pencarian menjadi pembacaan acak, dan disk kembali berada dalam jalur kritis.

Beban kerja yang tidak terpengaruh oleh disk

Blog atau situs perusahaan kecil. Halamannya kecil, cache halaman menyimpan semuanya setelah permintaan pertama, dan batasnya adalah CPU untuk rendering atau bandwidth untuk aset. Stack LAMP di Ubuntu 24.04 yang melayani situs dengan lalu lintas rendah hampir tidak melakukan IO disk setelah cache terisi.

Streaming media. Satu streaming 4K pada 40 Mbit/s membaca 5 MB/s. Sepuluh streaming membaca 50 MB/s, yang dapat dilayani oleh penyimpanan blok jaringan tanpa kendala. Server media Jellyfin di VPS dibatasi oleh alokasi egress jaringan Anda dan oleh CPU saat melakukan transcoding, bukan oleh media penyimpanan.

Inferensi model lokal. Menjalankan Ollama di VPS untuk meng-host LLM sendiri membaca file model satu kali, lalu bekerja di RAM. NVMe mengurangi waktu pemuatan model berukuran 20 GB dari beberapa menit menjadi beberapa detik. NVMe tidak mengubah jumlah token per detik karena hal itu dibatasi oleh bandwidth memori dan CPU.

Apa pun yang menunggu layanan eksternal. Worker yang menghabiskan 800 ms per pekerjaan untuk permintaan HTTP tidak akan bekerja lebih cepat dengan disk yang lebih baik.

Mengapa hypervisor sama pentingnya dengan media penyimpanan

Anda tidak berkomunikasi langsung dengan perangkat tersebut. Anda berkomunikasi dengan disk virtual yang disediakan oleh hypervisor, biasanya melalui virtio. Beberapa keputusan pada lapisan ini lebih berpengaruh daripada perbedaan antara NVMe dan SATA.

Anda tidak dapat melihat media penyimpanan dari dalam guest. lsblk -d -o NAME,ROTA,SIZE,MODEL menampilkan vda dengan model kosong karena virtio tidak meneruskan identitas drive. cat /sys/block/vda/queue/rotational melaporkan hal yang diiklankan oleh hypervisor. Jadi, nilai 0 di sana bukan bukti bahwa media tersebut menggunakan flash. nvme list, dari paket nvme-cli, biasanya tidak menampilkan apa pun di sebagian besar VPS, meskipun host menggunakan banyak drive NVMe. Disk Anda adalah perangkat virtio, bukan perangkat NVMe. Paket layanan yang menyebut NVMe biasanya menjelaskan isi host. Volume Anda tetap dapat terhubung melalui jaringan.

Mode cache host lebih memengaruhi angka daripada jenis medianya. Dengan caching writeback pada host, fsync() dari guest dapat selesai segera setelah host menyimpan data di RAM-nya sendiri. Hasil benchmark tersebut dapat melampaui kemampuan perangkat fisik mana pun. Hal ini juga berarti kerusakan host dapat menyebabkan hilangnya penulisan yang dianggap aman oleh database Anda. Dengan mode cache none, hasilnya lebih rendah dan mencerminkan kondisi sebenarnya.

Batas dan kredit burst. Banyak penyedia membatasi IOPS per volume atau per paket. Banyak volume jaringan juga menggunakan jatah burst. Jatah burst adalah kumpulan kredit. Volume berjalan cepat selama kredit masih tersedia, lalu turun ke tingkat dasar yang jauh lebih rendah. Gejalanya mudah dikenali. Impor atau pemulihan berjalan cepat selama beberapa menit, kemudian melambat secara drastis dan tetap lambat. Tidak ada konfigurasi yang berubah. Kreditnya telah habis.

Guest lain. Pada host bersama, latensi disk Anda berubah sesuai aktivitas guest lain. Karena itu, lakukan pengukuran lebih dari sekali. Jalankan pengujian yang sama pada pagi hari, lalu ulangi pada malam hari dan bandingkan variasinya. Pada host yang sibuk, perbedaan antara dua pengujian pada volume yang sama sering kali lebih besar daripada perbedaan yang dipublikasikan antara dua jenis media.

Cara mengukur disk yang sebenarnya tersedia di VPS Anda

Instal fio, tolok ukur IO standar, lalu lakukan pengukuran. Perhatikan tiga hal berikut terlebih dahulu. Pengujian ini membuat file, sehingga menggunakan ruang disk dan diperhitungkan dalam batas IOPS yang ditagihkan kepada Anda. Jalankan pengujian dalam waktu singkat. Jangan menjalankannya dengan queue depth penuh pada volume yang melayani traffic aktif, karena pengujian akan bersaing dengan aplikasi Anda sendiri.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Pembacaan acak pada queue depth 32, yaitu kedalaman yang biasanya dicantumkan vendor:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

Baris yang penting dimulai dengan read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 melewati page cache guest, sehingga hasilnya menggambarkan perangkat, bukan RAM Anda. Jika opsi ini dihilangkan, yang diukur adalah memori, sehingga hasilnya menjadi angka yang tidak mungkin dicapai disk mana pun. Gunakan --size=4G atau ukuran yang lebih besar jika ruang tersedia, karena file berukuran 1G dapat seluruhnya berada di cache host dan membuat hasil terlihat lebih baik daripada kondisi sebenarnya.

Queue depth 1 menunjukkan latensi mentah, yaitu latensi yang dirasakan proses single-threaded:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

Pengujian commit memprediksi perilaku database. Pengujian ini menulis 4k dan memanggil fdatasync() setelah setiap penulisan, sehingga laju yang dilaporkan mencakup proses flush:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

Angka IOPS dari pengujian tersebut mendekati jumlah maksimum transaksi kecil per detik yang dapat di-commit oleh satu koneksi database, karena commit menunggu flush yang sama.

Untuk pengambilan sampel cepat tanpa fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

Nilai mdev, yaitu deviasi rata-rata, sama pentingnya dengan nilai rata-rata. Deviasi besar pada mesin yang tidak sibuk menunjukkan bahwa backend penyimpanan digunakan bersama dan sedang sibuk.

Cara membaca hasil

Per Juli 2026, berikut interpretasi yang wajar untuk VPS kecil. Puluhan ribu IOPS pembacaan acak 4k pada queue depth 32, dengan latensi queue depth 1 di bawah sekitar 0.3 ms, konsisten dengan flash lokal. Latensi queue depth 1 selama beberapa milidetik menunjukkan jalur jaringan, apa pun nama paketnya. Pembacaan berurutan yang berhenti di sekitar 550 MB/s merupakan ciri koneksi SATA. Angka yang jauh lebih tinggi daripada kemampuan satu perangkat menunjukkan bahwa caching berada dalam jalur, hampir selalu pada host.

Untuk melihat pengaruh beban kerja aktif terhadap disk:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

Dalam output iostat -x, periksa r_await dan w_await, yaitu rata-rata milidetik sebuah permintaan menunggu, serta aqu-sz, yaitu panjang antrean rata-rata. Abaikan %util pada disk virtual. Nilai ini melaporkan persentase waktu ketika setidaknya satu permintaan masih diproses. Nilai ini tidak menunjukkan tingkat kejenuhan pada perangkat yang dapat melayani banyak permintaan sekaligus. Karena itu, %util sebesar 100 bersama r_await sebesar 0.2 ms menunjukkan disk sibuk yang berfungsi normal. Dalam vmstat, kolom wa adalah persentase waktu CPU yang digunakan untuk menunggu IO. Jika /proc/pressure/io tersedia pada kernel Anda, nilai some avg10= menunjukkan persentase dari 10 detik terakhir ketika setidaknya satu task tertahan pada IO. Ini merupakan jawaban paling langsung untuk menentukan apakah storage menjadi bottleneck Anda.

Tampilan VPS yang Terbatas oleh Disk

Load average yang tinggi dengan CPU idle dan wa yang besar di vmstat berarti proses mengantre di belakang disk. Sinyal kernel yang paling jelas adalah pesan berikut di dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

Baris tersebut muncul karena thread kernel menunggu lebih dari dua menit hingga storage memberikan respons, sehingga watchdog untuk tugas yang macet mencatatnya. jbd2 adalah thread jurnal ext4. Ini berarti seluruh filesystem sedang menunggu, bukan hanya satu program yang bermasalah. Pada VPS, kondisi ini biasanya mengarah pada backend storage atau batas IOPS yang telah habis.

Gejala pada aplikasi mengikuti pola yang sama. Waktu respons median tetap dapat diterima, sementara permintaan paling lambat membentuk ekor panjang karena hanya permintaan yang mengakses disk yang terkena dampaknya. apt upgrade tetap berada pada tahap Unpacking selama beberapa menit karena dpkg melakukan flush saat menulis. git status di repository besar memerlukan waktu beberapa detik. Ini adalah biaya metadata dan flush, sehingga bandwidth yang lebih besar tidak akan membantu.

Yang harus dilakukan saat disk menjadi batas

Beli RAM sebelum membeli IOPS. Jika working set sesuai dengan page cache, pembacaan tidak lagi mengakses disk. Menggandakan memori sering kali memberikan hasil yang lebih baik daripada berpindah ke kelas penyimpanan yang lebih cepat, dan biasanya biayanya lebih rendah.

Kurangi jumlah flush jika data memungkinkan. Di PostgreSQL, synchronous_commit = off memungkinkan commit selesai sebelum penulisan masuk ke disk. Jika server mati, transaksi pada sebagian kecil detik terakhir dapat hilang. Database tidak rusak karena write-ahead log tetap ditulis secara berurutan. Pengaturan ini tepat untuk salinan analitik, tetapi tidak tepat untuk pembayaran. innodb_flush_log_at_trx_commit = 2 di MySQL menerapkan kompromi yang sama.

Kelompokkan file kecil. Transfer atau pencadangan satu juta file kecil didominasi oleh biaya per file. Karena itu, mengarsipkan file terlebih dahulu lalu memindahkan satu stream lebih cepat pada penyimpanan dengan latensi tinggi daripada menyalin direktori file demi file.

Pastikan discard tetap berfungsi pada volume thin. Pada penyimpanan yang thin provisioned, backend tidak mengetahui bahwa suatu blok sudah bebas sampai filesystem memberitahukannya. Volume yang tidak pernah menjalankan trim akan kehilangan performa penulisan secara bertahap. Ubuntu menyediakan timer mingguan untuk ini:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av menampilkan jumlah byte yang di-trim pada setiap mount point. Pesan bahwa operasi discard tidak didukung berarti virtual disk tidak meneruskan discard ke host. Tidak ada yang perlu Anda perbaiki.

Jangan lakukan tuning IO scheduler. Pada disk virtio, cat /sys/block/vda/queue/scheduler biasanya sudah menampilkan none, dan penjadwalan sebenarnya berlangsung pada host yang tidak dapat Anda akses. Jangan lakukan noatime juga. Ubuntu menggunakan relatime saat melakukan mount secara default, yang sudah menghindari hampir semua penulisan atime.

Memilih paket

Bayar NVMe jika database, mail server, CI runner, atau proses build yang menggunakan banyak package dijalankan di server tersebut. Jangan membayar harga premium untuk website yang di-cache atau aplikasi yang sebagian besar waktunya digunakan untuk melakukan panggilan eksternal. Jika Anda tidak yakin, disk kemungkinan bukan batas kinerja Anda, karena sebagian besar beban kerja VPS kecil lebih dahulu kehabisan RAM atau bandwidth.

Lakukan pengukuran sejak hari pertama, saat Anda mengikuti sepuluh menit pertama pada VPS baru, lalu simpan hasilnya dalam file. Baseline membantu Anda membuktikan bahwa host menjadi lebih lambat, bukan kode Anda, pada kemudian hari. Utamakan provider yang mencantumkan kelas storage dan batas IOPS, jika ada, secara tertulis. Jika suatu paket menyebut NVMe, tetapi pembacaan dengan queue depth 1 memerlukan 4 ms, berarti Anda menggunakan storage jaringan pada host yang dilengkapi NVMe. Itu merupakan layanan yang wajar untuk dijual, tetapi berbeda dari produk yang Anda beli.

FAQ

Apakah NVMe selalu lebih cepat daripada SSD SATA pada VPS?

Tidak. Pada queue depth 1, keduanya hampir sama, sekitar 80 hingga 150 mikrodetik untuk pembacaan 4k, dan program single-threaded tidak dapat membedakan keduanya. NVMe lebih unggul ketika banyak permintaan sedang diproses, karena AHCI menyediakan satu queue dengan kedalaman 32 perintah, sedangkan NVMe menyediakan ribuan queue yang lebih dalam. Pada host bersama, beban dari guest lain dapat mengubah latensi Anda lebih besar daripada jenis medianya. Karena itu, ukur volume Anda sendiri dengan fio, bukan berdasarkan nama paket.

Bagaimana cara memeriksa apakah VPS saya benar-benar menggunakan NVMe?

Anda tidak dapat memeriksanya secara langsung karena virtio menyembunyikan perangkat fisik. lsblk menampilkan vda tanpa string model, nvme list tidak mengembalikan apa pun, dan /sys/block/vda/queue/rotational hanya melaporkan informasi yang diiklankan hypervisor. Sebagai gantinya, ukur perilakunya. Pembacaan acak 4k dengan queue depth 1 di bawah sekitar 0.3 ms berarti flash lokal. Beberapa milidetik berarti terdapat lompatan jaringan dalam jalur tersebut. Pembacaan berurutan yang berhenti di sekitar 550 MB/s menunjukkan adanya koneksi SATA.

Apakah NVMe membuat situs web saya dimuat lebih cepat?

Biasanya tidak. Setelah permintaan pertama, Linux menyajikan file dari page cache di RAM sehingga disk tidak aktif. Kecepatan halaman pada VPS kecil biasanya dibatasi oleh waktu CPU aplikasi dan bandwidth. Disk kembali menjadi bagian penting dalam jalur pemrosesan jika situs menulis pada setiap permintaan, misalnya keranjang belanja berbasis database yang sering melakukan commit, karena setiap commit harus menunggu flush selesai.

Apa hasil fio yang baik untuk VPS?

Per Juli 2026, VPS kecil dengan flash lokal biasanya menghasilkan puluhan ribu IOPS pembacaan acak 4k pada queue depth 32, dengan latensi queue depth 1 di bawah 0.3 ms. Penyimpanan blok jaringan biasanya menghasilkan beberapa ribu IOPS dengan latensi beberapa milidetik. Jalankan pengujian tiga kali pada jam yang berbeda. Perbedaan besar antarpengujian memberi informasi lebih penting daripada nilai rata-ratanya karena menunjukkan seberapa besar guest lain pada host memengaruhi Anda.

Haruskah saya menempatkan database pada penyimpanan blok jaringan?

Anda dapat melakukannya, dan banyak layanan terkelola menggunakannya, tetapi jalur commit harus menanggung dampaknya. Setiap flush melewati jaringan sehingga satu koneksi melakukan commit lebih sedikit transaksi kecil per detik dibandingkan jika menggunakan flash lokal. Sebagai gantinya, Anda memperoleh durabilitas yang tetap bertahan meskipun host mengalami masalah. Jika memilih penyimpanan jaringan untuk database dengan beban penulisan tinggi, kelompokkan pekerjaan ke dalam transaksi yang lebih besar agar lebih sedikit flush dapat membawa lebih banyak baris.