NVMe dhidi ya SSD kwenye VPS: Ina umuhimu?

Je, NVMe ina umuhimu kwenye VPS?

NVMe ina umuhimu kwenye VPS wakati programu yako inatuma shughuli nyingi ndogo za kusoma na kuandika na kusubiri kila moja ikamilike. Hubadilisha mambo machache sana kwa tovuti inayotoa kurasa zilizohifadhiwa kwenye akiba, au kwa programu inayotumia muda wake kusubiri mtandao. Aina ya hifadhi ni sababu moja tu. Hypervisor iliyo mbele ya diski, pamoja na wageni wengine wanaoshiriki hosti hiyo hiyo, huweka kiwango cha juu cha utendaji unaopata kwa kweli.

Kinachobadilishwa na NVMe, na kisichobadilishwa

NVMe (non-volatile memory express) si aina ya kumbukumbu ya flash. Ni itifaki na muunganisho unaotumika kufikia flash. Kifaa cha NVMe huunganishwa kwenye njia za PCIe (peripheral component interconnect express) na hutumia NVMe. SSD ya SATA (serial ATA) huunganishwa kwenye kiungo cha SATA na hutumia AHCI (advanced host controller interface). Chipu za kumbukumbu zinazohifadhi baiti zako zinaweza kuwa zilezile katika vifaa vyote viwili.

Kuna mambo mawili yanayotofautiana, na yote yanahusu njia ya amri badala ya hifadhi yenyewe.

Foleni. AHCI huipa kernel foleni moja ya amri inayoweza kuhifadhi amri 32. NVMe huruhusu maelfu ya foleni, kwa kawaida foleni moja kwa kila kiini cha CPU, na kila moja ikiwa na kina kikubwa zaidi ya 32. Mchakato mmoja unaosoma bloku moja kwa wakati mmoja hauwezi kutambua tofauti hiyo. Hifadhidata yenye usomaji 64 unaosubiri inaweza kuitambua: kwenye SATA, ombi la 33 husubiri nafasi kwenye foleni kabla kifaa hata hakijaliona, huku kifaa cha NVMe kikiyakubali yote na kuyashughulikia pamoja.

Upana wa kiungo. Kiungo cha SATA III hufanya kazi kwa 6 Gbit/s, ambayo ni takriban 550 MB/s ya data halisi baada ya ziada ya itifaki. Hiki ni kikomo kisichobadilika, bila kujali aina ya flash iliyo nyuma yake. Njia nne za PCIe hubeba gigabaiti kadhaa kwa sekunde, kwa hiyo kiungo huacha kuwa kikomo.

Muda wa kusubiri ndio sehemu ambayo matarajio huwa si sahihi. Katika kina cha foleni 1, yaani ombi moja linalotekelezwa, SSD ya SATA hujibu usomaji wa 4k kwa takriban mikrosekunde 100 hadi 150. NVMe hujibu kwa takriban mikrosekunde 80 hadi 100. Zote ni za haraka, na hakuna kitu unachoendesha kitakachotambua tofauti hiyo kwenye ombi moja. Pengo hujitokeza wakati wa matumizi ya pamoja. Kina cha foleni, yaani idadi ya maombi yanayotekelezwa kwa wakati mmoja, ndicho kinachoamua ikiwa midia hizo mbili zitaonekana kufanana au kutofautiana sana.

Hifadhi ya bloku ya mtandao ni aina ya tatu yenye hali tofauti za kiufundi. Uandishi hupitia mtandao hadi kwenye klasta ya hifadhi, na hukubaliwa tu baada ya klasta kuihifadhi, kwa hiyo muda wake wa kusubiri hupimwa kwa milisekunde badala ya mikrosekunde. Unachopata kwa kubali muda huo wa kusubiri ni uimara: ujazo huo huendelea kuwepo hata baada ya hosti uliyounganishwa nayo kuacha kufanya kazi, na unaweza kutengeneza snapshot yake na kubadilisha ukubwa wake.

Takwimu za kawaida zilizochapishwa: NVMe, SATA SSD na hifadhi ya mtandao

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

Kifaa cha ndani cha NVMe kwa kawaida hutajwa kuwa na 184,000 IOPS za usomaji wa nasibu wa 4k (shughuli za kuingiza/kutoa kwa sekunde) katika kina cha foleni cha 32. Jaribio lilelile kwenye SATA SSD hutajwa kuwa karibu 90,000, kwa sababu ya foleni moja ya AHCI na kiungo cha 6 Gbit/s. Hifadhi ya vizuizi ya mtandao kwa kawaida huwekewa kikomo na mtoa huduma badala ya maunzi, na 12,500 ni kikomo cha juu kinachotajwa mara nyingi kwenye nyaraka.

Muda wa kusubiri unaonyesha jambo lilelile kwa kipimo ambacho watumiaji wako huhisi. Muda wa kusubiri wa usomaji wa p99, yaani asilimia 1 ya maombi yenye muda mrefu zaidi, ni takriban 0.4 ms kwenye NVMe ya ndani na 1.2 ms kwenye SATA. Ukiweka mtandao kwenye njia, huwa 6.5 ms, ambao ni zaidi ya mara kumi ya thamani ya NVMe.

Usomaji mfululizo una tofauti kubwa zaidi na ndiyo kipimo kisichofaa zaidi: 3,400 MB/s dhidi ya 550 MB/s. Karibu hakuna kitu kwenye seva kinachosoma faili moja kubwa kutoka mwanzo hadi mwisho kwa kasi kamili. Safu ya nasibu na safu ya muda wa kusubiri zinaeleza kile ambacho hufanywa hasa na hifadhidata, foleni ya barua au kidhibiti cha vifurushi.

Ni mizigo ipi ya kazi inayotambua diski

Kanuni moja inaeleza yote: mzigo wa kazi hutambua diski pale tu unapoisubiri diski. Linux huhifadhi data ya faili iliyotumiwa hivi karibuni kwenye RAM, katika page cache, kwa hiyo usomaji wa pili wa faili haufikii hifadhi kamwe. Ikiwa seti ya kazi, yaani data inayotumika kwa sasa, inatoshea kwenye RAM, usomaji huwa usomaji wa kumbukumbu baada ya mzunguko wa kwanza. Uandishi ni tofauti. Uandishi wowote ambao programu inasafisha kwa kutumia fsync() lazima uwe kwenye hifadhi thabiti kabla programu kuruhusiwa kuendelea.

Kazi inayofanya commit. PostgreSQL, MySQL na SQLite huita fsync() au fdatasync() wakati wa commit, na kila commit husubiri kifaa kijibu. Kwa hiyo, kiwango cha commit cha muunganisho mmoja huamuliwa na muda wa kusubiri wa uandishi, si bandwidth. Kifaa kinachofanya flush kwa 0.2 ms huruhusu commit nyingi zaidi kwa sekunde kuliko kifaa kinachochukua 5 ms, na hakuna kiwango chochote cha throughput kinachoweza kubadilisha hilo. MySQL huonyesha hilo katika error log wakati flush haiwezi kuendana na kasi ya kazi:

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

PostgreSQL huripoti hilo katika mistari yake ya checkpoint, ambapo thamani kubwa ya sync= inamaanisha kuwa flush yenyewe ilikuwa ya polepole:

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

Kazi inayogusa faili nyingi ndogo. Kila faili huhitaji shughuli za metadata ambazo usomaji mmoja mkubwa wa mfululizo hauhitaji. npm install, git clone ya repository kubwa, kufungua picha za container, hifadhi ya barua ya Maildir na backup inayopitia mti mkubwa yote hutumia muda wake kwenye ufikiaji mdogo wa nasibu. Kazi ya restic ya kufanya backup kwenye VPS husoma na kuhesabu hash ya kila faili ambayo haijawahi kuiona, kwa hiyo muda halisi wa backup ya faili milioni moja hufuata kwa karibu muda wa kusubiri wa usomaji nasibu. Hali hiyo hiyo inatumika kwa du -sh, ambayo husoma metadata pekee.

Hifadhidata zinazozidi uwezo wa RAM pia zimo katika kundi hili. Mara index inapokuwa kubwa kuliko page cache, kila utafutaji huwa usomaji wa nasibu, na diski hurudi kwenye njia muhimu ya utekelezaji.

Ni mzigo gani wa kazi hauathiriwi na diski

Tovuti ya blogu au tovuti ya kampuni ndogo. Kurasa ni ndogo, akiba ya kurasa huzihifadhi zote baada ya ombi la kwanza, na kikomo huwa CPU kwa ajili ya kutoa kurasa au kipimo data kwa ajili ya rasilimali. Mkusanyiko wa LAMP kwenye Ubuntu 24.04 unaotumikia tovuti yenye trafiki ndogo karibu haufanyi IO ya diski baada ya kuhifadhi data kwenye akiba.

Utiririshaji wa midia. Utiririshaji mmoja wa 4K kwa 40 Mbit/s husoma 5 MB/s. Mitiririko kumi husoma 50 MB/s, kiwango ambacho hata hifadhi ya block ya mtandao inaweza kutoa bila shida. Seva ya midia ya Jellyfin kwenye VPS huzuiwa na kiwango chako cha data inayotoka kwenye mtandao, na na CPU inapobadilisha umbizo, si na aina ya hifadhi.

Uendeshaji wa modeli za ndani. Kuendesha Ollama kwenye VPS ili kujihudumia LLM husoma faili ya modeli mara moja, kisha hufanya kazi katika RAM. NVMe hupunguza muda wa kupakia modeli ya 20 GB kutoka dakika hadi sekunde. Haibadilishi idadi ya tokeni kwa sekunde, ambayo huamuliwa na kipimo data cha kumbukumbu na CPU.

Kazi yoyote inayosubiri huduma ya nje. Mfanyakazi anayetumia 800 ms kwa kila kazi kwenye ombi la HTTP hataenda haraka zaidi kwa kutumia diski bora.

Kwa nini hypervisor ni muhimu sawa na aina ya hifadhi

Huwasiliani moja kwa moja na kifaa. Unawasiliana na diski pepe ambayo hypervisor hutoa, kwa kawaida kupitia virtio. Maamuzi kadhaa katika tabaka hilo yana umuhimu mkubwa kuliko tofauti kati ya NVMe na SATA.

Huwezi kuona aina ya hifadhi ukiwa ndani ya guest. lsblk -d -o NAME,ROTA,SIZE,MODEL huonyesha vda ikiwa sehemu ya model ni tupu, kwa sababu virtio haipeleki utambulisho wa drive kupitia mfumo. cat /sys/block/vda/queue/rotational huripoti kile hypervisor inachotangaza. Kwa hiyo, thamani ya 0 hapo si uthibitisho wa flash. nvme list, kutoka kwenye package ya nvme-cli, kwa kawaida haorodheshi chochote kwenye VPS nyingi, hata wakati host ina drive za NVMe nyingi, kwa sababu diski yako ni kifaa cha virtio na si kifaa cha NVMe. Mpango unaosema NVMe kwa kawaida unaeleza vilivyomo kwenye host. Volume yako bado inaweza kuwa imeunganishwa kupitia mtandao.

Hali ya akiba ya host hubadilisha takwimu zaidi kuliko aina ya hifadhi. Akiba ya writeback ikiwa imewashwa kwenye host, guest fsync() inaweza kurudi mara tu host inapokuwa imehifadhi data katika RAM yake. Hilo huzalisha matokeo ya benchmark ambayo hakuna kifaa halisi kingeweza kufikia. Pia linamaanisha kuwa host ikipata hitilafu, maandishi ambayo database yako inaamini kuwa salama yanaweza kupotea. Ukiwa na hali ya akiba none, takwimu huwa za chini na za kweli.

Vikomo na credits za burst. Watoa huduma wengi huweka kikomo cha IOPS kwa kila volume au mpango. Volumes nyingi za mtandao pia hutumia allowance ya burst. Allowance ya burst ni hifadhi ya credits. Volume hufanya kazi kwa kasi wakati credits bado zipo, kisha hushuka hadi baseline ya chini zaidi. Dalili hiyo ni rahisi kutambua. Import au restore huenda kwa kasi kwa dakika kadhaa, kisha hupungua kwa ukali na kuendelea kuwa polepole, bila mabadiliko yoyote katika configuration yako. Umetumia credits.

Majirani. Kwenye host inayoshirikiwa, latency ya diski yako hubadilika kulingana na shughuli za guest wengine. Hii ndiyo sababu ya kufanya vipimo zaidi ya mara moja. Fanya test hiyo hiyo asubuhi na tena jioni, kisha linganisha tofauti. Kwenye host yenye shughuli nyingi, tofauti kati ya runs mbili kwenye volume hiyo hiyo mara nyingi huwa kubwa kuliko tofauti iliyochapishwa kati ya aina mbili za hifadhi.

Jinsi ya kupima diski ambayo VPS yako inayo kwa kweli

Sakinisha fio, zana ya kawaida ya kupima IO, kisha pima. Kwanza zingatia tahadhari tatu. Jaribio linaunda faili, kwa hiyo linatumia nafasi ya diski na linahesabiwa katika kikomo chochote cha IOPS unachotozwa. Fanya majaribio yawe mafupi. Usiendeshe jaribio kwa kina kamili cha foleni dhidi ya volume inayohudumia traffic hai, kwa sababu utashindana na programu yako mwenyewe.

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

Usomaji wa nasibu kwa kina cha foleni 32, ambacho ndicho kina kinachotajwa na vendors:

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

Mstari muhimu huanza na read:

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

--direct=1 hupita cache ya kurasa ya guest, kwa hiyo matokeo yanaelezea kifaa badala ya RAM yako. Ukiiacha, unapima memory, ambayo hutoa thamani ambayo hakuna diski inaweza kufikia. Tumia --size=4G au kubwa zaidi ikiwa una nafasi, kwa sababu faili ya 1G inaweza kubaki kabisa ndani ya cache ya host na kufanya matokeo yaonekane bora kuliko yalivyo.

Kina cha foleni 1 huonyesha latency ghafi, ambayo ndiyo mchakato wa thread moja hupitia:

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

Jaribio la commit hutabiri tabia ya database. Linaandika 4k na kuita fdatasync() baada ya kila uandishi, kwa hiyo kiwango kilichoripotiwa kinajumuisha 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

Takwimu ya IOPS kutoka kwenye jaribio hilo iko karibu na idadi ya juu zaidi ya transactions ndogo kwa sekunde ambayo connection moja ya database inaweza kufanya commit, kwa sababu commit husubiri flush hiyo hiyo.

Kwa sampuli ya haraka bila 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

Thamani ya mdev, yaani mkengeuko wa wastani, ni muhimu sawa na wastani. Mkengeuko mkubwa kwenye box isiyo na mzigo unaonyesha kuwa backend ya storage inashirikiwa na ina shughuli nyingi.

Jinsi ya kusoma matokeo

Kufikia Julai 2026, haya ni makadirio yanayofaa kwa VPS ndogo. IOPS za makumi ya maelfu za usomaji wa nasibu wa 4k kwenye kina cha foleni 32, zikiwa na muda wa kusubiri wa kina cha foleni 1 chini ya takriban 0.3 ms, zinaendana na flash ya ndani. Muda wa kusubiri wa kina cha foleni 1 wa milisekunde kadhaa unaonyesha njia ya mtandao, bila kujali mpango huo unaitwaje. Usomaji mfululizo unaokoma karibu 550 MB/s ni dalili ya kiunganishi cha SATA. Nambari iliyo juu sana kuliko uwezo wa kifaa chochote kimoja inaonyesha kuwa caching iko kwenye njia, karibu kila mara kwenye host.

Ili kuona jinsi mzigo wako wa sasa unavyotumia diski:

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

Kwenye matokeo ya iostat -x, soma r_await na w_await, ambazo ni wastani wa milisekunde ambazo ombi lilisubiri, pamoja na aqu-sz, ambao ni wastani wa urefu wa foleni. Puuza %util kwenye diski pepe. Hupima sehemu ya muda ambao angalau ombi moja lilikuwa bado linasubiri, lakini haionyeshi kiwango cha msongamano kwenye kifaa kinachohudumia maombi mengi kwa wakati mmoja. Kwa hiyo, %util ya 100 pamoja na r_await ya 0.2 ms huonyesha diski yenye shughuli nyingi lakini yenye hali nzuri. Kwenye vmstat, safu wima ya wa ni asilimia ya muda wa CPU uliotumika kusubiri IO. Ikiwa /proc/pressure/io ipo kwenye kernel yako, thamani yake ya some avg10= ni sehemu ya sekunde 10 zilizopita ambapo angalau task moja ilikuwa imesimama ikisubiri IO. Hili ndilo jibu la moja kwa moja zaidi la swali la ikiwa uhifadhi ndio kizuizi cha utendaji wako.

Jinsi VPS inayofungwa na diski inavyoonekana

Wastani wa mzigo wa juu ukiambatana na CPU isiyotumika na wa kubwa katika vmstat humaanisha kuwa michakato imepangwa kwenye foleni ikisubiri diski. Ishara iliyo wazi zaidi kutoka kwenye kernel ni ujumbe huu katika dmesg -T:

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

Mstari huo unaonekana kwa sababu thread ya kernel ilisubiri zaidi ya dakika mbili ili storage ijibu, hivyo hung task watchdog iliurekodi. jbd2 ni thread ya journal ya ext4, ambayo inaonyesha kuwa mfumo mzima wa faili ulikuwa unasubiri, si programu moja yenye hitilafu ya tabia. Kwenye VPS, kwa kawaida hii huonyesha tatizo kwenye backend ya storage au kikomo cha IOPS kilichotumika kabisa.

Dalili za programu zinafuata muundo huohuo. Muda wa wastani wa majibu hubaki unakubalika, huku maombi yanayochukua muda mrefu zaidi yakionyesha mkia mrefu, kwa sababu ni maombi yanayofikia diski pekee yanayochelewa. apt upgrade hukwama kwenye Unpacking kwa dakika kadhaa, kwa sababu dpkg huandika na kulazimisha data ihifadhiwe. git status kwenye hazina kubwa huchukua sekunde kadhaa. Hizi ni gharama za metadata na flush, hivyo bandwidth zaidi haitasaidia.

Nini cha kufanya diski inapokuwa kikwazo

Nunua RAM kabla ya kununua IOPS. Seti ya data inayotumika ikitoshea kwenye akiba ya kurasa, usomaji hauhitaji kufikia diski kabisa. Kuongeza kumbukumbu mara mbili mara nyingi huwa na manufaa zaidi kuliko kuhamia kwenye aina ya hifadhi yenye kasi zaidi, na kwa kawaida hugharimu kidogo.

Punguza idadi ya operesheni za flush pale data inaporuhusu. Katika PostgreSQL, synchronous_commit = off huruhusu commit kurudi kabla ya maandishi kuwekwa kwenye diski. Unaweza kupoteza miamala ya sehemu ya mwisho ya sekunde ikiwa seva itazima. Hifadhidata haitaharibika, kwa sababu write-ahead log bado huandikwa kwa mpangilio. Ubadilishanaji huo unafaa kwa nakala ya uchanganuzi, lakini haufai kwa malipo. innodb_flush_log_at_trx_commit = 2 katika MySQL hutoa ubadilishanaji huo huo.

Panga mafaili madogo katika mafungu. Uhamishaji au hifadhi rudufu ya mafaili madogo milioni moja huathiriwa zaidi na gharama ya kila faili. Kwa hiyo, kuyaweka kwanza kwenye archive na kuhamisha stream moja huwa haraka zaidi kwenye hifadhi yenye latency kubwa kuliko kunakili mti wa mafaili faili moja baada ya nyingine.

Hakikisha discard inafanya kazi kwenye volumes nyembamba. Kwenye hifadhi iliyotengewa kwa mfumo wa thin provisioning, mfumo wa nyuma hautambui kuwa block imekuwa huru hadi filesystem itakapotoa taarifa hiyo. Volume ambayo haifanyi trim hupoteza utendaji wa kuandika polepole. Ubuntu husafirisha timer ya kila wiki kwa kazi hii:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av huchapisha idadi ya bytes zilizofanyiwa trim kwa kila mount point. Ujumbe unaosema kuwa operesheni ya discard haitumiki unamaanisha kuwa virtual disk haipitishi discard kwa host. Kwa hiyo, hakuna unachohitaji kurekebisha.

Ruka usanidi wa IO scheduler. Kwenye diski ya virtio, cat /sys/block/vda/queue/scheduler kwa kawaida huonyesha none tayari, na upangaji halisi wa operesheni hufanyika kwenye host, ambako huna ufikiaji. Pia ruka noatime: Ubuntu hu-mount kwa relatime kwa chaguo-msingi, hali ambayo tayari huepuka karibu kila uandishi wa atime.

Kuchagua mpango

Lipa kwa NVMe wakati hifadhidata, seva ya barua pepe, CI runner au uundaji wenye vifurushi vingi unaendeshwa kwenye seva hiyo. Usilipe gharama ya ziada kwa tovuti iliyohifadhiwa kwenye akiba au programu ambayo muda wake mwingi hutumika kwenye mawasiliano ya nje. Ikiwa huna uhakika, huenda diski si kikomo chako, kwa sababu mzigo mwingi wa kazi wa VPS ndogo huishiwa RAM au kipimo data kwanza.

Pima siku ya kwanza, unapopitia dakika kumi za kwanza kwenye VPS mpya, na uhifadhi matokeo kwenye faili. Msingi wa vipimo hukuwezesha kuthibitisha baadaye kwamba seva imekuwa polepole, badala ya msimbo wako. Wapendelee watoa huduma wanaotaja aina ya hifadhi na kikomo chochote cha IOPS kwa maandishi. Ikiwa mpango unasema NVMe na usomaji wenye queue depth 1 unachukua 4 ms, unatumia hifadhi ya mtandao kwenye seva iliyo na NVMe. Hilo ni jambo linalofaa kuuzwa, lakini ni tofauti na kitu unachonunua.

FAQ

Je, NVMe huwa na kasi kubwa kuliko SSD ya SATA kwenye VPS?

Hapana. Kwa kina cha foleni cha 1, vifaa hivyo viwili huwa karibu, takriban mikrosekunde 80 hadi 150 kwa usomaji wa 4k, na programu ya uzi mmoja haiwezi kutambua tofauti hiyo. NVMe huwa na faida wakati maombi mengi yanashughulikiwa kwa wakati mmoja, kwa sababu AHCI hutoa foleni moja yenye kina cha amri 32, ilhali NVMe hutoa maelfu ya foleni zenye kina kikubwa zaidi. Kwenye mwenyeji unaoshirikiwa, mzigo kutoka kwa wageni wengine unaweza kubadilisha muda wako wa kusubiri zaidi kuliko aina ya hifadhi. Kwa hiyo, pima ujazo wako mwenyewe kwa kutumia fio badala ya kusoma jina la mpango.

Ninawezaje kuangalia ikiwa VPS yangu hutumia NVMe kweli?

Huwezi kuikagua moja kwa moja, kwa sababu virtio huficha kifaa halisi. lsblk huonyesha vda bila mfuatano wa modeli, nvme list hairudishi chochote, na /sys/block/vda/queue/rotational huripoti tu kile kinachotangazwa na hypervisor. Badala yake, pima utendaji. Usomaji wa nasibu wa 4k wenye kina cha foleni cha 1 na muda wa kusubiri ulio chini ya takriban 0.3 ms huashiria flash ya ndani. Muda wa milisekunde kadhaa huashiria kuwa kuna njia ya mtandao kwenye mchakato huo. Usomaji wa mfululizo unaokoma karibu na 550 MB/s huashiria kiunganishi cha SATA.

Je, NVMe hufanya tovuti yangu ipakie kwa kasi zaidi?

Kwa kawaida, hapana. Baada ya ombi la kwanza, Linux huhudumia faili kutoka kwenye page cache iliyo kwenye RAM, hivyo diski huacha kufanya kazi. Kasi ya ukurasa kwenye VPS ndogo kwa kawaida huamuliwa na muda wa CPU wa programu na kipimo data. Diski hurudi kwenye njia muhimu ikiwa tovuti huandika kwenye kila ombi, kwa mfano kikapu kinachotumia hifadhidata na kufanya commit mara kwa mara, kwa sababu kila commit husubiri flush ikamilike.

Ni matokeo gani mazuri ya fio kwa VPS?

Kufikia Julai 2026, VPS ndogo iliyo kwenye flash ya ndani kwa kawaida hurudisha makumi ya maelfu ya IOPS za usomaji wa nasibu wa 4k kwa kina cha foleni cha 32, ikiwa na muda wa kusubiri wa chini ya 0.3 ms kwa kina cha foleni cha 1. Hifadhi ya block ya mtandao kwa kawaida hurudisha IOPS elfu chache, ikiwa na muda wa kusubiri wa milisekunde kadhaa. Endesha jaribio hilo mara 3 katika saa tofauti. Tofauti kubwa kati ya majaribio inakuambia zaidi kuliko wastani, kwa sababu inaonyesha kiwango ambacho wageni wengine kwenye mwenyeji huathiri utendaji wako.

Je, niweke hifadhidata yangu kwenye hifadhi ya block ya mtandao?

Unaweza, na huduma nyingi zinazosimamiwa hufanya hivyo, lakini njia ya commit hulipia gharama hiyo. Kila flush hupitia mtandao, hivyo muunganisho mmoja hufanya commit za miamala midogo kwa sekunde chache kuliko ungefanya kwenye flash ya ndani. Kwa upande mwingine, unapata uimara unaoendelea hata mwenyeji akiharibika. Ukichagua hifadhi ya mtandao kwa hifadhidata yenye uandishi mwingi, kusanya kazi katika miamala mikubwa zaidi ili flush chache zibebe safu nyingi zaidi.