NVMe vs SSD SATA VPS: Apakah Berpengaruh?

Apakah NVMe berpengaruh pada VPS?

NVMe berpengaruh pada VPS ketika perangkat lunak Anda melakukan banyak operasi baca dan tulis kecil, lalu menunggu setiap operasi selesai. NVMe hampir tidak memberikan perubahan pada situs yang menyajikan halaman dari cache atau pada program yang sebagian besar waktunya menunggu jaringan. Media penyimpanan hanya salah satu faktor. Hypervisor yang berada di antara sistem dan disk, serta guest lain yang berbagi host yang sama, menentukan batas performa yang benar-benar Anda dapatkan.

Perubahan yang ditimbulkan NVMe dan yang tidak

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

Ada dua perbedaan, dan keduanya berkaitan dengan jalur perintah, bukan media penyimpanannya.

Antrean. AHCI menyediakan satu antrean perintah untuk kernel yang menampung 32 perintah. NVMe mendukung ribuan antrean. Dalam praktiknya, 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 ini. Database dengan 64 pembacaan yang sedang diproses dapat melihatnya: pada SATA, permintaan ke-33 harus menunggu slot antrean sebelum perangkat melihatnya, sedangkan perangkat NVMe menerima semuanya dan memprosesnya secara bersamaan.

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

Latensi biasanya tidak sesuai dengan ekspektasi. Pada queue depth 1, yang berarti hanya satu permintaan yang 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 proses yang Anda jalankan akan menyadari perbedaannya pada satu permintaan. Perbedaannya terlihat saat konkurensi meningkat. Queue depth, yaitu jumlah permintaan yang sedang diproses secara bersamaan, menentukan apakah kedua media tersebut terlihat serupa atau sangat berbeda.

Penyimpanan blok jaringan adalah kelas ketiga dengan karakteristik teknis yang berbeda. Penulisan melewati jaringan menuju cluster penyimpanan dan baru mendapatkan acknowledgment setelah cluster menyimpan data tersebut. Karena itu, latensinya diukur dalam milidetik, bukan mikrodetik. Imbalannya adalah durabilitas: volume tetap tersedia setelah 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 memiliki 184,000 IOPS baca acak 4k (operasi input/output per detik) pada queue depth 32. Pengujian yang sama pada SATA SSD biasanya menghasilkan sekitar 90,000, karena dibatasi oleh satu queue AHCI dan koneksi 6 Gbit/s. Penyimpanan blok jaringan biasanya dibatasi oleh penyedia, bukan oleh perangkat kerasnya, dan 12,500 merupakan batas maksimum yang umum didokumentasikan.

Latensi menunjukkan hal yang sama dalam satuan yang dirasakan pengguna. Latensi baca p99, yaitu latensi 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 sekuensial memiliki perbedaan terbesar dan paling tidak berguna: 3,400 MB/s dibandingkan dengan 550 MB/s. Hampir tidak ada proses di server yang membaca satu file besar dari awal hingga akhir dengan kecepatan penuh. Kolom acak dan kolom latensi lebih menggambarkan aktivitas nyata database, antrean email, atau pengelola paket.

Beban kerja apa yang dipengaruhi oleh disk

Satu aturan menjelaskan semuanya: beban kerja hanya dipengaruhi oleh disk ketika harus menunggu disk. Linux menyimpan data file yang baru digunakan di RAM, dalam page cache, sehingga pembacaan kedua file tidak pernah mencapai storage. Jika working set, yaitu data yang sedang digunakan, muat di RAM, pembacaan berubah menjadi pembacaan memori setelah akses pertama. Penulisan berbeda. Setiap penulisan yang di-flush oleh aplikasi dengan fsync() harus berada pada storage stabil sebelum aplikasi boleh melanjutkan.

Beban kerja yang melakukan commit. PostgreSQL, MySQL, dan SQLite memanggil fsync() atau fdatasync() saat commit, dan setiap commit menunggu respons dari perangkat. 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 tersebut. MySQL mencatatnya dalam error log ketika flush tidak mampu mengimbangi laju penulisan:

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

PostgreSQL melaporkannya pada baris checkpoint. Nilai sync= yang besar berarti proses 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

Beban kerja yang mengakses banyak file kecil. Setiap file melibatkan operasi metadata yang tidak diperlukan oleh satu pembacaan berurutan berukuran besar. npm install, git clone dari repositori besar, pembongkaran image container, penyimpanan email Maildir, dan pencadangan yang menelusuri tree besar semuanya menghabiskan waktu untuk akses acak berukuran kecil. Job pencadangan restic pada VPS membaca dan melakukan hashing pada setiap file yang belum pernah dilihat sebelumnya. Karena itu, durasi pencadangan jutaan file berkorelasi erat dengan latensi pembacaan acak. Hal yang sama berlaku untuk du -sh, yang hanya membaca metadata.

Database yang ukurannya melampaui RAM juga termasuk dalam kategori ini. Setelah indeks tidak lagi muat dalam page cache, setiap pencarian menjadi pembacaan acak, sehingga disk kembali berada dalam jalur kritis.

Beban kerja apa yang tidak terpengaruh oleh disk

Blog atau situs perusahaan kecil. Halaman berukuran kecil, page cache menampung semuanya setelah permintaan pertama, dan batasnya adalah CPU untuk rendering atau bandwidth untuk aset. LAMP stack pada Ubuntu 24.04 yang melayani situs dengan trafik rendah hampir tidak melakukan IO disk setelah cache terisi.

Streaming media. Satu stream 4K pada 40 Mbit/s membaca 5 MB/s. Sepuluh stream membaca 50 MB/s, yang dapat dilayani oleh network block storage tanpa masalah. Server media Jellyfin pada VPS dibatasi oleh alokasi egress jaringan dan CPU saat melakukan transcoding, bukan oleh media penyimpanan.

Inferensi model lokal. Menjalankan Ollama pada VPS untuk melakukan self-hosting LLM 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, yang dibatasi oleh bandwidth memori dan CPU.

Apa pun yang menunggu layanan eksternal. Worker yang menghabiskan 800 ms per job untuk permintaan HTTP tidak akan bekerja lebih cepat hanya karena menggunakan disk yang lebih baik.

Mengapa hypervisor sama pentingnya dengan media penyimpanan

Anda tidak berinteraksi langsung dengan perangkat tersebut. Anda berinteraksi dengan disk virtual yang disediakan hypervisor, biasanya melalui virtio, dan beberapa keputusan pada lapisan ini lebih berpengaruh daripada perbandingan NVMe dengan 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 hypervisor, sehingga nilai 0 bukan bukti bahwa perangkat tersebut menggunakan flash. nvme list, dari paket nvme-cli, biasanya tidak menampilkan apa pun pada sebagian besar VPS, meskipun host menggunakan banyak drive NVMe, karena disk Anda adalah perangkat virtio, bukan perangkat NVMe. Keterangan NVMe pada suatu paket biasanya menjelaskan perangkat yang digunakan host. Volume Anda tetap dapat terhubung melalui jaringan.

Mode cache host lebih memengaruhi angka daripada jenis media. Dengan caching writeback pada host, guest fsync() dapat mengembalikan hasil segera setelah host menyimpan data di RAM-nya sendiri. Hasil benchmark tersebut dapat melampaui kemampuan perangkat fisik mana pun. Kondisi ini juga berarti crash pada host dapat menyebabkan hilangnya write yang diyakini database sudah aman. Dengan mode cache none, hasilnya lebih rendah dan lebih mencerminkan kondisi sebenarnya.

Batas dan kredit burst. Banyak provider membatasi IOPS per volume atau per paket, dan banyak volume jaringan menggunakan kuota burst. Kuota burst adalah kumpulan kredit: volume berjalan cepat selama kredit masih tersedia, lalu turun ke baseline yang jauh lebih rendah. Gejalanya mudah dikenali. Proses import atau restore berjalan cepat selama beberapa menit, kemudian melambat drastis dan tetap lambat, tanpa perubahan pada konfigurasi. Kredit burst Anda telah habis.

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

Cara mengukur kapasitas disk yang sebenarnya tersedia pada VPS

Instal fio, benchmark IO standar, lalu lakukan pengukuran. Perhatikan tiga hal berikut terlebih dahulu. Pengujian ini membuat sebuah 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 trafik aktif, karena pengujian akan bersaing dengan aplikasi Anda sendiri.

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

Pembacaan acak dengan queue depth 32, yaitu kedalaman yang biasanya dicantumkan oleh 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, dan hasilnya dapat mencapai angka yang tidak mungkin dicapai oleh disk. Gunakan --size=4G atau ukuran yang lebih besar jika ruang tersedia, karena file berukuran 1G dapat sepenuhnya berada di cache host dan membuat hasil tampak lebih tinggi.

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 pengukuran 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 server yang sedang tidak sibuk menunjukkan bahwa backend penyimpanan digunakan bersama dan sedang sibuk.

Cara membaca hasil

Per Juli 2026, berikut adalah hasil yang wajar untuk VPS kecil. Puluhan ribu IOPS baca 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 sebesar beberapa milidetik menunjukkan jalur jaringan, apa pun nama paketnya. Baca berurutan yang berhenti di sekitar 550 MB/s merupakan ciri koneksi SATA. Nilai yang jauh lebih tinggi daripada kemampuan satu perangkat mana pun menunjukkan bahwa caching berada di jalur, hampir selalu pada host.

Untuk melihat dampak workload aktif Anda terhadap disk:

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

Dalam output iostat -x, baca 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 saturasi pada perangkat yang dapat melayani banyak permintaan sekaligus. Karena itu, %util sebesar 100 bersama r_await sebesar 0.2 ms menunjukkan disk yang sibuk tetapi sehat. Dalam vmstat, kolom wa menunjukkan 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. Nilai ini merupakan indikator paling langsung untuk menentukan apakah storage menjadi bottleneck Anda.

Tanda VPS yang terbatas oleh disk

Load average yang tinggi dengan CPU idle dan wa yang besar di vmstat menunjukkan bahwa proses mengantre karena menunggu disk. Sinyal kernel yang paling jelas adalah pesan berikut dalam 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 merespons. Karena itu, hung task watchdog mencatatnya. jbd2 adalah thread jurnal ext4. Artinya, seluruh filesystem sedang menunggu, bukan hanya satu program yang bermasalah. Pada VPS, hal ini biasanya menunjukkan masalah pada backend storage atau batas IOPS yang telah habis.

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

Yang harus dilakukan ketika disk menjadi batas

Beli RAM sebelum membeli IOPS. Jika working set muat di page cache, operasi baca tidak lagi mengakses disk. Menggandakan memori sering kali lebih efektif daripada beralih ke kelas penyimpanan yang lebih cepat, dan biasanya biayanya lebih rendah.

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

Kelompokkan file kecil. Transfer atau pencadangan satu juta file kecil didominasi biaya per file. Karena itu, membuat arsip terlebih dahulu lalu memindahkan satu stream lebih cepat pada storage dengan latensi tinggi daripada menyalin tree file satu per satu.

Pastikan discard tetap berjalan pada volume thin. Pada storage yang menggunakan thin provisioning, backend tidak mengetahui bahwa sebuah 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 mencetak 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 scheduler IO. 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 mount secara default, sehingga hampir semua penulisan atime sudah dihindari.

Memilih paket

Bayar NVMe jika database, mail server, CI runner, atau proses build yang menggunakan banyak paket dijalankan pada server tersebut. Jangan membayar harga premium untuk situs web yang dilayani dari cache atau aplikasi yang sebagian besar waktunya digunakan untuk melakukan panggilan eksternal. Jika Anda tidak yakin, kemungkinan besar disk bukan batas utama Anda, karena sebagian besar workload VPS kecil lebih dahulu kehabisan RAM atau bandwidth.

Lakukan pengukuran sejak hari pertama, saat Anda menjalankan sepuluh menit pertama pada VPS baru, lalu simpan hasilnya dalam file. Baseline membantu Anda membuktikan kemudian bahwa host menjadi lebih lambat, bukan kode Anda yang bermasalah. Pilih provider yang mencantumkan kelas storage dan batas IOPS, jika ada, secara tertulis. Jika sebuah paket menyebut NVMe, tetapi pembacaan dengan queue depth 1 memerlukan 4 ms, berarti Anda menggunakan network storage pada host yang dilengkapi NVMe. Itu adalah layanan yang wajar untuk dijual, tetapi berbeda dari 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 microseconds untuk pembacaan 4k, dan program single-threaded tidak dapat membedakan keduanya. NVMe lebih unggul saat banyak request sedang diproses, karena AHCI menyediakan satu queue dengan kedalaman 32 command, 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 menunjukkan flash lokal. Latensi beberapa milidetik menunjukkan adanya network hop dalam jalur tersebut. Pembacaan sequential yang berhenti di sekitar 550 MB/s menunjukkan koneksi SATA.

Apakah NVMe membuat website saya lebih cepat dimuat?

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

Berapa hasil fio yang baik untuk VPS?

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

Apakah database sebaiknya ditempatkan pada network block storage?

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