NVMe vs SSD SATA VPS: Adakah Bezanya Penting?

Adakah NVMe penting pada VPS?

NVMe penting pada VPS apabila perisian anda melakukan banyak operasi bacaan dan penulisan kecil serta menunggu setiap operasi selesai. NVMe memberikan sedikit perbezaan untuk laman yang menyediakan halaman cache, atau untuk program yang kebanyakannya menunggu rangkaian. Medium storan ialah salah satu faktor. Hypervisor yang mengawal akses kepada cakera dan tetamu lain yang berkongsi hos yang sama menentukan had prestasi sebenar yang anda peroleh.

Perkara yang berubah dengan NVMe dan perkara yang tidak berubah

NVMe (non-volatile memory express) bukan sejenis memori flash. NVMe ialah protokol dan sambungan yang digunakan untuk mengakses flash. Peranti NVMe menggunakan lorong PCIe (peripheral component interconnect express) dan berkomunikasi menggunakan NVMe. SSD SATA (serial ATA) menggunakan pautan SATA dan berkomunikasi menggunakan AHCI (advanced host controller interface). Cip memori yang menyimpan bait anda boleh sama bagi kedua-duanya.

Terdapat dua perbezaan, dan kedua-duanya berkaitan dengan laluan arahan, bukan storan itu sendiri.

Baris gilir. AHCI menyediakan satu baris gilir arahan kepada kernel yang boleh memuatkan 32 arahan. NVMe membenarkan ribuan baris gilir, lazimnya satu bagi setiap teras CPU, dan setiap satunya jauh lebih dalam daripada 32 arahan. Satu proses yang membaca satu blok pada satu masa tidak akan melihat perbezaan itu. Pangkalan data dengan 64 bacaan yang belum selesai boleh melihatnya: pada SATA, permintaan ke-33 menunggu slot baris gilir sebelum peranti menerimanya, manakala peranti NVMe menerima semua permintaan itu dan memprosesnya secara serentak.

Lebar pautan. Pautan SATA III beroperasi pada 6 Gbit/s, iaitu kira-kira 550 MB/s data sebenar selepas overhed protokol. Ini ialah had tetap, tanpa mengira jenis flash di belakangnya. Empat lorong PCIe boleh membawa beberapa gigabait sesaat, jadi pautan itu tidak lagi menjadi had.

Jangkaan terhadap kependaman biasanya tidak tepat. Pada kedalaman baris gilir 1, iaitu satu permintaan yang sedang diproses, SSD SATA menjawab bacaan 4k dalam kira-kira 100 hingga 150 mikrosaat. NVMe menjawab dalam kira-kira 80 hingga 100 mikrosaat. Kedua-duanya pantas, dan tiada apa-apa yang anda jalankan akan menyedari perbezaan itu bagi satu permintaan. Perbezaan menjadi ketara apabila terdapat keserentakan. Kedalaman baris gilir, iaitu bilangan permintaan yang sedang diproses pada satu-satu masa, ialah tetapan yang menentukan sama ada kedua-dua medium kelihatan serupa atau sangat berbeza.

Storan blok rangkaian ialah kelas ketiga dengan ciri fizikal yang berbeza. Penulisan merentasi rangkaian ke kluster storan dan hanya diakui selepas kluster menyimpannya, jadi kependaman diukur dalam milisaat, bukan mikrosaat. Sebagai balasan untuk kependaman itu, anda memperoleh ketahanan data: volum tersebut kekal walaupun hos yang dilampirkan kepadanya tidak lagi tersedia, dan volum itu boleh diambil syot kilat serta diubah saiz.

Angka yang lazim diterbitkan: NVMe, SSD SATA dan storan rangkaian

[
  {
    "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"
  }
]

Peranti NVMe tempatan biasanya dinyatakan sebagai 184,000 IOPS bacaan rawak 4k (operasi input/output sesaat) pada kedalaman baris gilir 32. Ujian yang sama pada SSD SATA biasanya dinyatakan hampir 90,000, kerana dihadkan oleh baris gilir AHCI tunggal dan pautan 6 Gbit/s. Storan blok rangkaian biasanya dihadkan oleh penyedia, bukan perkakasan, dan 12,500 ialah had atas yang lazim didokumenkan.

Kependaman menunjukkan perkara yang sama dalam unit yang dirasai oleh pengguna. Kependaman bacaan p99, iaitu 1 peratus permintaan yang paling lambat, adalah sekitar 0.4 ms pada NVMe tempatan dan 1.2 ms pada SATA. Jika rangkaian berada dalam laluan, nilainya menjadi 6.5 ms, iaitu lebih daripada sepuluh kali ganda angka NVMe.

Bacaan berjujukan menunjukkan perbezaan terbesar dan paling kurang berguna: 3,400 MB/s berbanding 550 MB/s. Hampir tiada proses pada pelayan membaca satu fail besar dari awal hingga akhir pada kelajuan penuh. Lajur rawak dan lajur kependaman menerangkan operasi sebenar pangkalan data, baris gilir mel atau pengurus pakej.

Beban kerja yang terkesan oleh cakera

Satu peraturan menerangkan semuanya: beban kerja hanya terkesan oleh cakera apabila menunggu cakera. Linux menyimpan data fail yang baru digunakan dalam RAM, dalam cache halaman, jadi bacaan kedua bagi sesuatu fail tidak pernah sampai ke storan. Jika set kerja, iaitu data yang sedang digunakan, muat dalam RAM, bacaan menjadi bacaan memori selepas laluan pertama. Penulisan berbeza. Sebarang penulisan yang dipaksa aplikasi dengan fsync() mesti berada pada storan stabil sebelum aplikasi dibenarkan meneruskan operasi.

Kerja yang melakukan commit. PostgreSQL, MySQL dan SQLite memanggil fsync() atau fdatasync() semasa commit, dan setiap commit menunggu peranti memberikan respons. Oleh itu, kadar commit bagi satu sambungan ditentukan oleh kependaman penulisan, bukan lebar jalur. Peranti yang melakukan flush dalam 0.2 ms membenarkan jauh lebih banyak commit sesaat berbanding peranti yang mengambil masa 5 ms, dan tiada jumlah throughput dapat mengubah keadaan itu. MySQL menyatakannya dalam log ralat apabila flush tidak dapat mengikuti kadar penulisan:

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

PostgreSQL melaporkannya dalam baris checkpoint, apabila nilai sync= yang besar bermakna flush itu sendiri perlahan:

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

Kerja yang mengakses banyak fail kecil. Setiap fail melibatkan operasi metadata yang tidak diperlukan oleh satu bacaan berjujukan yang besar. npm install, git clone repositori besar, pembongkaran imej kontena, stor mel Maildir dan sandaran yang menelusuri pepohon besar semuanya menghabiskan masa pada capaian rawak kecil. Tugas sandaran restic pada VPS membaca dan mengira hash setiap fail yang belum pernah ditemuinya, jadi masa jam dinding bagi sandaran melibatkan sejuta fail berkait rapat dengan kependaman bacaan rawak. Perkara yang sama berlaku pada du -sh, yang hanya membaca metadata.

Pangkalan data yang melebihi kapasiti RAM juga termasuk dalam kategori ini. Setelah indeks tidak lagi muat dalam cache halaman, setiap carian menjadi bacaan rawak dan cakera kembali berada dalam laluan kritikal.

Beban kerja yang tidak terjejas oleh cakera

Blog atau laman syarikat kecil. Halaman ber saiz kecil, cache halaman menyimpan semuanya selepas permintaan pertama, dan hadnya ialah CPU untuk pemaparan atau lebar jalur untuk aset. Tindanan LAMP pada Ubuntu 24.04 yang menyediakan laman dengan trafik rendah hampir tidak melakukan IO cakera selepas cache dipanaskan.

Penstriman media. Satu strim 4K pada 40 Mbit/s membaca 5 MB/s. Sepuluh strim membaca 50 MB/s, yang masih dapat disediakan oleh storan blok rangkaian tanpa masalah. Pelayan media Jellyfin pada VPS dihadkan oleh peruntukan egress rangkaian anda dan oleh CPU semasa melakukan transkod, bukan oleh medium storan.

Inferens model setempat. Menjalankan Ollama pada VPS untuk mengehos sendiri LLM membaca fail model sekali, kemudian beroperasi dalam RAM. NVMe mengurangkan masa pemuatan model 20 GB daripada beberapa minit kepada beberapa saat. Ia tidak mengubah bilangan token sesaat, yang terikat pada lebar jalur memori dan CPU.

Apa-apa sahaja yang menunggu perkhidmatan luaran. Pekerja yang menghabiskan 800 ms bagi setiap tugas untuk permintaan HTTP tidak akan menjadi lebih pantas dengan cakera yang lebih baik.

Mengapa hipervisor sama pentingnya dengan medium

Anda tidak berkomunikasi terus dengan peranti. Anda berkomunikasi dengan cakera maya yang dipersembahkan oleh hipervisor, biasanya melalui virtio. Beberapa keputusan pada lapisan ini lebih penting daripada perbandingan NVMe dengan SATA.

Anda tidak dapat melihat medium itu dari dalam guest. lsblk -d -o NAME,ROTA,SIZE,MODEL menunjukkan vda dengan model yang kosong kerana virtio tidak meneruskan identiti pemacu. cat /sys/block/vda/queue/rotational melaporkan perkara yang diiklankan oleh hipervisor. Oleh itu, nilai 0 bukan bukti bahawa peranti itu menggunakan flash. nvme list daripada pakej nvme-cli biasanya tidak menyenaraikan apa-apa pada kebanyakan VPS, walaupun hosnya menggunakan pemacu NVMe sepenuhnya, kerana cakera anda ialah peranti virtio, bukan peranti NVMe. Pelan yang menyatakan NVMe biasanya menerangkan kandungan hos. Volume anda mungkin masih disambungkan melalui rangkaian.

Mod cache hos mengubah angka lebih banyak daripada medium. Dengan cache writeback pada hos, guest fsync() boleh mengembalikan hasil sebaik sahaja hos menyimpan data dalam RAM sendiri. Ini menghasilkan keputusan penanda aras yang tidak mungkin dicapai oleh mana-mana peranti fizikal. Ini juga bermaksud kerosakan hos boleh menyebabkan kehilangan penulisan yang dianggap selamat oleh pangkalan data anda. Dengan mod cache none, angkanya lebih rendah dan lebih tepat.

Had dan kredit burst. Banyak penyedia mengehadkan IOPS bagi setiap volume atau pelan. Banyak volume rangkaian pula menggunakan peruntukan burst. Peruntukan burst ialah kumpulan kredit. Volume beroperasi dengan pantas selagi kredit masih ada, kemudian menurun kepada baseline yang jauh lebih rendah. Gejalanya mudah dikenal pasti. Import atau pemulihan berjalan pantas selama beberapa minit, kemudian menjadi perlahan dengan ketara dan kekal perlahan, tanpa sebarang perubahan pada konfigurasi anda. Kredit itu telah habis digunakan.

Jiran. Pada hos dikongsi, kependaman cakera anda berubah mengikut aktiviti guest lain. Inilah sebabnya anda perlu membuat pengukuran lebih daripada sekali. Jalankan ujian yang sama pada waktu pagi dan sekali lagi pada waktu petang, kemudian bandingkan variasinya. Pada hos yang sibuk, perbezaan antara dua ujian pada volume yang sama selalunya lebih besar daripada perbezaan yang diterbitkan antara dua medium.

Cara mengukur cakera yang sebenarnya tersedia pada VPS anda

Pasang fio, penanda aras IO standard, kemudian jalankan pengukuran. Ambil perhatian terhadap tiga perkara terlebih dahulu. Ujian ini mencipta fail, jadi ruang cakera akan digunakan dan penggunaan ini dikira dalam sebarang had IOPS yang dikenakan bayaran kepada anda. Pastikan tempoh setiap larian singkat. Jangan jalankannya pada kedalaman baris gilir penuh terhadap volum yang sedang melayani trafik langsung, kerana anda akan bersaing dengan aplikasi sendiri.

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

Bacaan rawak pada kedalaman baris gilir 32, iaitu kedalaman yang dinyatakan 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 bermula dengan read:

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

--direct=1 memintas cache halaman tetamu, jadi hasilnya menerangkan peranti dan bukannya RAM anda. Jika pilihan ini ditinggalkan, anda akan mengukur memori dan mendapat nilai yang tidak boleh dicapai oleh mana-mana cakera. Gunakan --size=4G atau nilai yang lebih besar jika ruang mencukupi, kerana fail 1G boleh berada sepenuhnya dalam cache hos dan menyebabkan hasil kelihatan lebih baik daripada keadaan sebenar.

Kedalaman baris gilir 1 menunjukkan kependaman mentah, iaitu kependaman yang dialami oleh proses satu utas:

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

Ujian commit meramalkan tingkah laku pangkalan data. Ujian ini menulis 4k dan memanggil fdatasync() selepas setiap penulisan, jadi kadar yang dilaporkan merangkumi operasi 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 daripada larian itu hampir dengan bilangan maksimum transaksi kecil sesaat yang boleh dilakukan oleh satu sambungan pangkalan data, kerana commit menunggu flush yang sama.

Untuk mendapatkan sampel pantas 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, iaitu sisihan min, sama pentingnya dengan purata. Sisihan yang besar pada mesin yang tidak sibuk menunjukkan bahawa bahagian belakang storan dikongsi dan sedang sibuk.

Cara membaca hasil

Setakat Julai 2026, tafsiran berikut munasabah untuk VPS kecil. Puluhan ribu IOPS bacaan rawak 4k pada queue depth 32, dengan kependaman queue depth 1 di bawah kira-kira 0.3 ms, selaras dengan flash setempat. Kependaman queue depth 1 selama beberapa milisaat menunjukkan laluan rangkaian, tanpa mengira nama pelan tersebut. Bacaan berjujukan yang terhenti sekitar 550 MB/s ialah ciri pautan SATA. Nilai yang jauh melebihi keupayaan mana-mana peranti tunggal menunjukkan bahawa caching berada dalam laluan tersebut, hampir selalu pada hos.

Untuk melihat kesan beban kerja semasa terhadap cakera:

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

Dalam output iostat -x, baca r_await dan w_await, iaitu purata milisaat sesuatu permintaan menunggu, serta aqu-sz, iaitu panjang baris gilir purata. Abaikan %util pada cakera maya. Nilai ini melaporkan bahagian masa apabila sekurang-kurangnya satu permintaan masih belum selesai. Nilai ini tidak menunjukkan tahap tepu pada peranti yang boleh melayan banyak permintaan serentak. Oleh itu, nilai %util sebanyak 100 bersama nilai r_await sebanyak 0.2 ms menunjukkan cakera sibuk yang berfungsi dengan baik. Dalam vmstat, lajur wa ialah peratusan masa CPU yang digunakan untuk menunggu IO. Jika /proc/pressure/io wujud pada kernel anda, nilai some avg10= ialah bahagian daripada 10 saat terakhir apabila sekurang-kurangnya satu tugas tersekat pada IO. Nilai ini memberikan jawapan paling langsung tentang sama ada storan menjadi kesesakan prestasi anda.

Gambaran VPS yang terhad oleh cakera

Purata beban yang tinggi dengan CPU melahu dan wa yang besar dalam vmstat menunjukkan bahawa proses beratur menunggu cakera. Isyarat kernel yang paling jelas ialah mesej ini dalam dmesg -T:

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

Baris itu muncul kerana thread kernel menunggu lebih daripada dua minit untuk storan memberikan respons, lalu watchdog tugas tergantung merekodkannya. jbd2 ialah thread jurnal ext4. Ini bermakna seluruh sistem fail sedang menunggu, bukan hanya satu program yang bermasalah. Pada VPS, keadaan ini biasanya menunjukkan masalah pada bahagian belakang storan atau had IOPS yang telah habis digunakan.

Gejala aplikasi menunjukkan corak yang sama. Masa respons median kekal boleh diterima, manakala permintaan yang paling lambat membentuk ekor panjang kerana hanya permintaan yang mengakses cakera terjejas. apt upgrade kekal pada Unpacking selama beberapa minit kerana dpkg melakukan flush semasa menulis. git status dalam repositori besar mengambil masa beberapa saat. Ini ialah kos metadata dan flush, jadi lebar jalur yang lebih besar tidak akan membantu.

Perkara yang perlu dilakukan apabila cakera menjadi had

Beli RAM sebelum membeli IOPS. Jika set kerja muat dalam cache halaman, bacaan tidak lagi perlu mencapai cakera. Menggandakan memori sering memberikan manfaat yang lebih besar berbanding berpindah ke kelas storan yang lebih pantas, dan biasanya kosnya lebih rendah.

Kurangkan bilangan flush jika data membenarkannya. Dalam PostgreSQL, synchronous_commit = off membolehkan commit dikembalikan sebelum penulisan disimpan pada cakera. Anda boleh kehilangan transaksi dalam pecahan saat terakhir jika pelayan gagal. Pangkalan data tidak rosak kerana write-ahead log masih ditulis mengikut susunan. Pertukaran ini sesuai untuk salinan analitik tetapi tidak sesuai untuk pembayaran. innodb_flush_log_at_trx_commit = 2 dalam MySQL memberikan pertukaran yang sama.

Himpunkan fail kecil secara kelompok. Pemindahan atau sandaran sejuta fail kecil banyak dipengaruhi oleh kos setiap fail. Oleh itu, mengarkibkan fail terlebih dahulu dan memindahkan satu aliran lebih pantas pada storan berlengah tinggi berbanding menyalin pepohon fail satu demi satu.

Pastikan discard berfungsi pada volum nipis. Pada storan yang diperuntukkan secara nipis, bahagian belakang storan tidak mengetahui bahawa sesuatu blok telah dikosongkan sehingga filesystem memaklumkannya. Volum yang tidak pernah melakukan trim akan kehilangan prestasi penulisan secara beransur-ansur. Ubuntu menyediakan timer mingguan untuk tujuan ini:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av mencetak bilangan bait yang telah ditrim bagi setiap titik lekapan. Mesej yang menyatakan bahawa operasi discard tidak disokong bermaksud cakera maya tidak meneruskan discard kepada hos. Oleh itu, tiada apa-apa yang perlu anda baiki.

Jangan lakukan penalaan penjadual IO. Pada cakera virtio, cat /sys/block/vda/queue/scheduler biasanya sudah memaparkan none, dan penjadualan sebenar berlaku pada hos, yang tidak boleh anda akses. Jangan lakukan noatime juga: Ubuntu melakukan lekapan dengan relatime secara lalai, yang sudah mengelakkan hampir semua penulisan atime.

Memilih pelan

Bayar untuk NVMe apabila pangkalan data, pelayan mel, pelari CI atau binaan yang menggunakan banyak pakej dijalankan pada pelayan tersebut. Jangan bayar premium untuk laman web yang dicache atau aplikasi yang kebanyakan masanya digunakan untuk panggilan luaran. Jika anda tidak pasti, cakera mungkin bukan had anda kerana kebanyakan beban kerja VPS kecil kehabisan RAM atau lebar jalur terlebih dahulu.

Buat pengukuran pada hari pertama, semasa anda mengikuti sepuluh minit pertama pada VPS baharu, dan simpan output dalam fail. Garis dasar membolehkan anda membuktikan kemudian bahawa hos menjadi lebih perlahan, bukannya kod anda yang menyebabkan masalah. Utamakan penyedia yang menyatakan kelas storan dan sebarang had IOPS secara bertulis. Jika pelan menyatakan NVMe tetapi bacaan dengan queue depth 1 mengambil masa 4 ms, anda menggunakan storan rangkaian pada hos yang dilengkapi NVMe. Itu ialah tawaran yang wajar dijual, tetapi perkara yang berbeza untuk dibeli.

FAQ

Adakah NVMe sentiasa lebih pantas daripada SSD SATA pada VPS?

Tidak. Pada kedalaman baris gilir 1, kedua-duanya hampir sama, iaitu kira-kira 80 hingga 150 mikrosaat untuk bacaan 4k, dan program satu bebenang tidak dapat membezakannya. NVMe lebih pantas apabila banyak permintaan sedang diproses, kerana AHCI menyediakan satu baris gilir dengan kedalaman 32 arahan, manakala NVMe menyediakan beribu-ribu baris gilir yang lebih dalam. Pada hos dikongsi, beban daripada tetamu lain boleh mengubah kependaman anda lebih ketara berbanding jenis medium storan. Oleh itu, ukur volum anda sendiri dengan fio dan jangan bergantung pada nama pelan.

Bagaimanakah saya boleh menyemak sama ada VPS saya benar-benar menggunakan NVMe?

Anda tidak boleh menyemaknya secara langsung kerana virtio menyembunyikan peranti fizikal. lsblk menunjukkan vda tanpa rentetan model, nvme list tidak mengembalikan apa-apa, dan /sys/block/vda/queue/rotational hanya melaporkan perkara yang diiklankan oleh hipervisor. Sebaliknya, ukur prestasinya. Bacaan rawak 4k dengan kedalaman baris gilir 1 dan kependaman kurang daripada kira-kira 0.3 ms menunjukkan storan flash setempat. Beberapa milisaat menunjukkan terdapat lompatan rangkaian dalam laluan tersebut. Bacaan berjujukan yang berhenti hampir pada 550 MB/s menunjukkan pautan SATA.

Adakah NVMe menjadikan laman web saya dimuatkan dengan lebih pantas?

Biasanya tidak. Selepas permintaan pertama, Linux menyajikan fail daripada cache halaman dalam RAM, jadi cakera tidak lagi aktif. Kelajuan halaman pada VPS kecil biasanya dihadkan oleh masa CPU aplikasi dan lebar jalur. Cakera kembali menjadi sebahagian daripada laluan kritikal jika laman menulis pada setiap permintaan, contohnya troli yang menggunakan pangkalan data dan kerap melakukan commit, kerana setiap commit perlu menunggu flush selesai.

Apakah hasil fio yang baik untuk VPS?

Setakat July 2026, VPS kecil pada flash setempat biasanya menghasilkan puluhan ribu IOPS bacaan rawak 4k pada kedalaman baris gilir 32, dengan kependaman kedalaman baris gilir 1 di bawah 0.3 ms. Storan blok rangkaian biasanya menghasilkan beberapa ribu IOPS dengan kependaman beberapa milisaat. Jalankan ujian tiga kali pada waktu yang berbeza. Perbezaan besar antara hasil ujian memberikan lebih banyak maklumat berbanding purata, kerana perbezaan itu menunjukkan sejauh mana tetamu lain pada hos mempengaruhi anda.

Patutkah saya meletakkan pangkalan data pada storan blok rangkaian?

Anda boleh berbuat demikian, dan banyak perkhidmatan terurus menggunakannya, tetapi laluan commit perlu menanggung kos tersebut. Setiap flush melalui rangkaian, jadi satu sambungan melakukan lebih sedikit transaksi kecil sesaat berbanding storan flash setempat. Sebagai gantinya, anda mendapat ketahanan data yang kekal walaupun hos mengalami kegagalan. Jika anda memilih storan rangkaian untuk pangkalan data yang banyak melakukan penulisan, kumpulkan kerja dalam transaksi yang lebih besar supaya lebih sedikit flush membawa lebih banyak baris.