VPS-ல் NVMe மற்றும் SSD: வேறுபாடு முக்கியமா?

VPS-ல் NVMe முக்கியமா?

உங்கள் software பல சிறிய read மற்றும் write செயல்பாடுகளை அனுப்பி, ஒவ்வொன்றும் முடியும் வரை காத்திருந்தால், VPS-ல் NVMe முக்கியமானதாகும். Cached pages-ஐ வழங்கும் site-க்கு, அல்லது network-க்காக காத்திருப்பதில் பெரும்பாலான நேரத்தை செலவிடும் program-க்கு, இதனால் ஏற்படும் மாற்றம் மிகக் குறைவு. Storage medium ஒரு காரணியாகும். Disk-க்கு முன்பாக உள்ள hypervisor மற்றும் அதே host-ஐ பகிர்ந்து பயன்படுத்தும் பிற guests ஆகியவை, நடைமுறையில் நீங்கள் பெறக்கூடிய செயல்திறனின் உச்சவரம்பை நிர்ணயிக்கின்றன.

NVMe மாற்றுவது என்ன, அது மாற்றாதது என்ன

NVMe (non-volatile memory express) என்பது ஒரு வகையான flash memory அல்ல. Flash memory-ஐ அணுகப் பயன்படுத்தப்படும் protocol மற்றும் connection ஆகும். NVMe device, PCIe (peripheral component interconnect express) lanes வழியாக இணைந்து NVMe protocol-ல் தொடர்புகொள்கிறது. SATA (serial ATA) SSD, SATA link வழியாக இணைந்து AHCI (advanced host controller interface) protocol-ல் தொடர்புகொள்கிறது. உங்கள் bytes-ஐ வைத்திருக்கும் memory chips இரண்டிலும் ஒரே மாதிரியாக இருக்கலாம்.

மாறுபடும் இரண்டு அம்சங்கள் உள்ளன. இரண்டும் storage-ஐப் பற்றியவை அல்ல; command path-ஐப் பற்றியவை.

Queues. AHCI, kernel-க்கு 32 commands வைத்திருக்கக்கூடிய ஒரே command queue-ஐ வழங்குகிறது. NVMe, ஆயிரக்கணக்கான queues-ஐ அனுமதிக்கிறது. நடைமுறையில், ஒவ்வொரு CPU core-க்கும் ஒரு queue இருக்கலாம். ஒவ்வொரு queue-வும் 32-ஐவிட அதிகமான commands-ஐ வைத்திருக்க முடியும். ஒரு process, ஒரே நேரத்தில் ஒரு block-ஐ மட்டும் படித்தால், இந்த வேறுபாடு தெரியாது. ஒரே நேரத்தில் 64 reads-ஐ இயக்கும் database-ல் இது தெரியும்: SATA-வில் 33வது request, device அதைப் பார்ப்பதற்குமுன் queue slot-க்காகக் காத்திருக்க வேண்டும். NVMe device, எல்லா requests-ஐயும் ஏற்றுக்கொண்டு ஒரே நேரத்தில் செயல்படுத்தும்.

Link width. SATA III link, 6 Gbit/s வேகத்தில் இயங்குகிறது. Protocol overhead-ஐ கழித்த பிறகு இது உண்மையான data-க்கு சுமார் 550 MB/s ஆகும். அதன் பின்னால் எந்த flash இருந்தாலும், இது ஒரு நிலையான அதிகபட்ச வரம்பாகும். நான்கு PCIe lanes, ஒரு வினாடிக்கு பல gigabytes data-ஐ எடுத்துச் செல்லும். எனவே link, performance-ன் வரம்பாக இருக்காது.

Latency தொடர்பாகவே எதிர்பார்ப்புகள் பொதுவாகத் தவறாக இருக்கும். Queue depth 1, அதாவது ஒரே நேரத்தில் ஒரு request மட்டும் இயங்கும் நிலையில், SATA SSD ஒரு 4k read-க்கு சுமார் 100 முதல் 150 microseconds-ல் பதிலளிக்கும். NVMe சுமார் 80 முதல் 100 microseconds-ல் பதிலளிக்கும். இரண்டும் வேகமானவை. ஒரே request-ல் இந்த வேறுபாட்டை நீங்கள் இயக்கும் எந்த application-மும் கவனிக்காது. Concurrent operations அதிகரிக்கும்போது வேறுபாடு தெளிவாகும். Queue depth, அதாவது ஒரே நேரத்தில் இயங்கிக்கொண்டிருக்கும் requests-ன் எண்ணிக்கை, இந்த இரண்டு media-வும் ஒரே மாதிரியாகத் தோன்றுமா அல்லது மிகவும் வேறுபட்டதாகத் தோன்றுமா என்பதை நிர்ணயிக்கும் setting ஆகும்.

Network block storage என்பது வேறுபட்ட செயல்முறைகளைக் கொண்ட மூன்றாவது வகையாகும். ஒரு write, network வழியாக storage cluster-க்கு செல்கிறது. Cluster அதைச் சேமித்த பிறகே acknowledgement வழங்கப்படுகிறது. எனவே அதன் latency, microseconds-க்கு பதிலாக milliseconds-ல் அளக்கப்படுகிறது. அந்த latency-க்குப் பதிலாக நீங்கள் பெறுவது durability ஆகும்: volume, அது இணைக்கப்பட்டுள்ள host-ஐவிட நீண்ட காலம் இருக்கும். அதை snapshot எடுக்கவும் resize செய்யவும் முடியும்.

வழக்கமாக வெளியிடப்படும் அளவீடுகள்: NVMe, SATA SSD மற்றும் network storage

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

ஒரு local NVMe device-க்கு queue depth 32 நிலையில் பொதுவாக 184,000 random 4k read IOPS (input/output operations per second) எனக் குறிப்பிடப்படும். அதே சோதனையில் SATA SSD-க்கு சுமார் 90,000 எனக் குறிப்பிடப்படும். ஒற்றை AHCI queue மற்றும் 6 Gbit/s link காரணமாக இந்த மதிப்பு கட்டுப்படுத்தப்படுகிறது. Network block storage-ன் வரம்பை hardware-ஐவிட provider பெரும்பாலும் நிர்ணயிக்கிறது. 12,500 என்பது பொதுவாக ஆவணப்படுத்தப்படும் உச்சவரம்பாகும்.

Users உணரும் unit-ல் latency இதையே காட்டுகிறது. p99 read latency என்பது requests-ல் மெதுவான 1 சதவீதத்திற்கான latency ஆகும். இது local NVMe-ல் சுமார் 0.4 ms; SATA-ல் 1.2 ms ஆகும். பாதையில் network சேர்த்தால் இது 6.5 ms ஆகிறது. இது NVMe மதிப்பைவிட பத்து மடங்குக்கும் அதிகம்.

Sequential reads-ல் வேறுபாடு மிகப் பெரியதாக இருக்கும். ஆனால் இது பயன்பாட்டில் குறைவாகவே உதவும்: 3,400 MB/s எதிராக 550 MB/s. Server-ல் மிகச் சில செயல்களே ஒரு பெரிய file-ஐ தொடக்கம் முதல் முடிவு வரை முழு வேகத்தில் படிக்கும். Database, mail queue அல்லது package manager உண்மையில் எவ்வாறு செயல்படுகிறது என்பதை random மற்றும் latency columns காட்டுகின்றன.

எந்த workloads disk-ஐ கவனிக்கும்

இவை அனைத்தையும் ஒரு விதி விளக்குகிறது: disk-க்காக காத்திருக்கும்போது மட்டுமே ஒரு workload disk-ஐ கவனிக்கும். Linux சமீபத்தில் பயன்படுத்திய file data-வை RAM-இல் உள்ள page cache-ல் வைத்திருக்கும். எனவே, ஒரு file-ஐ இரண்டாவது முறை படிக்கும்போது storage-ஐ அணுக வேண்டியதில்லை. உண்மையில் பயன்படுத்தப்படும் data-வான working set RAM-ல் பொருந்தினால், முதல் pass-க்கு பிறகு reads memory reads-ஆக மாறும். Writes வேறுபட்டவை. Application fsync() மூலம் flush செய்யும் எந்த write-உம் application தொடர அனுமதிக்கப்படும் முன் stable storage-ல் இருக்க வேண்டும்.

Commit செய்யும் வேலை. PostgreSQL, MySQL மற்றும் SQLite ஆகியவை commit செய்யும்போது fsync() அல்லது fdatasync()-ஐ அழைக்கின்றன. ஒவ்வொரு commit-உம் device-ன் பதிலுக்காக காத்திருக்கும். எனவே, ஒரு connection-ன் commit rate bandwidth-ஆல் அல்ல, write latency-ஆல் நிர்ணயிக்கப்படுகிறது. 0.2 ms-ல் flush செய்யும் device, 5 ms எடுக்கும் device-ஐ விட வினாடிக்கு அதிகமான commits-ஐ அனுமதிக்கும். இதை எந்த அளவு throughput-உம் மாற்ற முடியாது. Flush வேகத்துக்கு ஏற்ப நடைபெற முடியாதபோது MySQL error log-ல் இதைத் தெரிவிக்கும்:

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

PostgreSQL இதை அதன் checkpoint lines-ல் தெரிவிக்கும். அங்கு பெரிய sync= value இருந்தால் flush தானே மெதுவாக இருந்தது என்று பொருள்:

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

பல சிறிய files-ஐ அணுகும் வேலை. ஒரு பெரிய sequential read-ல் இல்லாத metadata operations ஒவ்வொரு file-க்கும் இருக்கும். பெரிய repository-ன் npm install, git clone, container images-ஐ unpack செய்தல், Maildir mail store மற்றும் பெரிய tree-ஐ கடந்து செல்லும் backup ஆகியவை சிறிய random access செயல்களில் அதிக நேரம் செலவிடுகின்றன. VPS-ல் restic backup job முன்பு காணாத ஒவ்வொரு file-ஐயும் படித்து hash செய்கிறது. எனவே, ஒரு million files கொண்ட backup-ன் wall-clock time random read latency-யை நெருக்கமாகப் பின்பற்றும். Metadata-ஐ மட்டும் படிக்கும் du -sh-க்கும் இதே நிலை பொருந்தும்.

RAM-ஐ விட பெரிதாகிவிடும் databases-உம் இந்த வகையைச் சேர்ந்தவை. Index page cache-ல் பொருந்தாமல் போனதும், ஒவ்வொரு lookup-உம் random read-ஆக மாறும். அப்போது disk மீண்டும் critical path-ல் இருக்கும்.

எந்த workloads-க்கு disk வேக வேறுபாடு தெரியாது

ஒரு blog அல்லது சிறிய company site. Pages சிறியதாக இருக்கும். முதல் request-க்குப் பிறகு page cache அவற்றை முழுமையாக வைத்திருக்கும். Rendering செய்வதற்கான CPU அல்லது assets-க்கான bandwidth தான் வரம்பாக இருக்கும். குறைந்த traffic கொண்ட site-ஐ வழங்கும் Ubuntu 24.04-ல் LAMP stack அமைத்தல் warm ஆன பிறகு கிட்டத்தட்ட disk IO செய்யாது.

Media streaming. ஒரு 4K stream, 40 Mbit/s வேகத்தில் இயங்கும்போது 5 MB/s வாசிக்கும். 10 streams சேர்ந்து 50 MB/s வாசிக்கும். இதையும் network block storage சிரமமின்றி வழங்கும். VPS-ல் Jellyfin media server அமைத்தல் storage medium-ஆல் வரையறுக்கப்படாது. உங்கள் network egress allowance மற்றும் transcoding செய்யும்போது ஏற்படும் CPU பயன்பாடுதான் அதன் வரம்புகள்.

Local model inference. VPS-ல் Ollama இயக்கி LLM-ஐ self-host செய்வது model file-ஐ ஒருமுறை வாசித்த பிறகு RAM-ல் இயங்கும். NVMe, 20 GB model-ன் load time-ஐ minutes-லிருந்து seconds-ஆகக் குறைக்கும். ஆனால் tokens per second மாறாது. அது memory bandwidth மற்றும் CPU-ஆல் வரையறுக்கப்படுகிறது.

External service-க்காக காத்திருக்கும் எதுவும். ஒரு job-க்கு HTTP request-ல் 800 ms செலவிடும் worker, வேகமான disk பயன்படுத்தினாலும் வேகமாக இயங்காது.

medium போலவே hypervisor-மும் ஏன் முக்கியம்

நீங்கள் நேரடியாக device-உடன் தொடர்புகொள்வதில்லை. பொதுவாக hypervisor virtio மூலம் வழங்கும் virtual disk-உடன்தான் தொடர்புகொள்கிறீர்கள். அந்த அடுக்கில் எடுக்கப்படும் பல முடிவுகள், NVMe மற்றும் SATA இடையிலான வேறுபாட்டைவிட அதிகம் பாதிக்கின்றன.

guest-க்குள் இருந்து medium-ஐ பார்க்க முடியாது. lsblk -d -o NAME,ROTA,SIZE,MODEL, drive identity-ஐ virtio கடத்தாததால், model காலியாக உள்ள vda-ஐ காட்டும். cat /sys/block/vda/queue/rotational, hypervisor விளம்பரப்படுத்தும் தகவலைக் காட்டுகிறது. எனவே அங்கு 0 இருப்பது flash storage என்பதற்கான ஆதாரம் அல்ல. nvme-cli package-இலுள்ள nvme list, பெரும்பாலான VPS-களில் எதையும் பட்டியலிடாது. Host முழுவதும் NVMe drives இருந்தாலும் இது நிகழலாம். ஏனெனில் உங்கள் disk, NVMe device அல்ல; அது virtio device. NVMe என்று குறிப்பிடும் plan, பொதுவாக host-ல் உள்ள storage-ஐக் குறிக்கிறது. உங்கள் volume network-attached ஆகவும் இருக்கலாம்.

Host cache mode, medium-ஐவிட benchmark numbers-ஐ அதிகமாக மாற்றும். Host-ல் writeback caching இயக்கப்பட்டிருந்தால், host தனது RAM-ல் data-ஐ பெற்றவுடன் guest fsync() வெற்றிகரமாக முடிந்ததாகத் திரும்பலாம். எந்த physical device-மும் வழங்க முடியாத benchmark result இதனால் கிடைக்கலாம். Database பாதுகாப்பாக எழுதப்பட்டுவிட்டதாகக் கருதும் writes-ஐ host crash இழக்கக்கூடும் என்பதும் இதன் பொருள். none cache mode பயன்படுத்தினால் numbers குறைவாகவும் நம்பகமாகவும் இருக்கும்.

Caps மற்றும் burst credits. பல providers ஒவ்வொரு volume அல்லது plan-க்கும் IOPS வரம்பை அமைக்கின்றன. பல network volumes burst allowance-ஐப் பயன்படுத்துகின்றன. Burst allowance என்பது credits-ன் தொகுப்பு. Credits இருக்கும் வரை volume அதிக வேகத்தில் இயங்கும். பின்னர் அது மிகவும் குறைந்த baseline வேகத்துக்குக் குறையும். இதன் அறிகுறியை எளிதாக அறியலாம். Import அல்லது restore சில நிமிடங்கள் வேகமாக இயங்கும். பின்னர் configuration-ல் எந்த மாற்றமும் இல்லாமல் வேகம் திடீரெனக் குறைந்து தொடர்ந்து குறைவாக இருக்கும். Credits பயன்படுத்தி முடித்துவிட்டீர்கள்.

அருகிலுள்ள guests. Shared host-ல், பிற guests செய்யும் பணிகளுக்கு ஏற்ப உங்கள் disk latency மாறும். இதனால்தான் ஒன்றுக்கு மேற்பட்ட முறை அளவிட வேண்டும். அதே test-ஐ காலையில் ஒருமுறையும் மாலையில் மீண்டும் ஒருமுறையும் இயக்கி, முடிவுகளின் பரவலை ஒப்பிடுங்கள். Busy host-ல், அதே volume-ல் எடுக்கப்படும் இரண்டு runs-க்கு இடையிலான வேறுபாடு, வெளியிடப்பட்ட இரண்டு media-களுக்கிடையிலான வேறுபாட்டைவிட பெரிதாக இருப்பது வழக்கமானது.

உங்கள் VPS-ல் உண்மையில் உள்ள disk அளவை எவ்வாறு அளவிடுவது

Standard IO benchmark ஆன fio-ஐ install செய்து அளவிடவும். முதலில் 3 எச்சரிக்கைகள் உள்ளன. இந்த test ஒரு file-ஐ உருவாக்கும். எனவே இது disk space-ஐ பயன்படுத்தும்; மேலும் நீங்கள் கட்டணம் செலுத்தும் IOPS allowance-லும் இது கணக்கிடப்படும். Test run-களைச் சுருக்கமாக வைத்திருக்கவும். Live traffic வழங்கும் volume மீது முழு queue depth-ல் இதை இயக்க வேண்டாம். அப்போது உங்கள் சொந்த application-உடனேயே போட்டியிட வேண்டியிருக்கும்.

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

Vendors குறிப்பிடும் queue depth ஆன 32-ல் random read:

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

முக்கியமான line, read: எனத் தொடங்கும்.

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

--direct=1 guest page cache-ஐ bypass செய்கிறது. எனவே அதன் result உங்கள் RAM-ஐ அல்லாமல் device-ஐ விவரிக்கும். இதை விடுத்தால் memory-ஐ அளவிடுவீர்கள்; எந்த disk-மும் அடைய முடியாத எண்ணை அது காட்டும். Space இருந்தால் --size=4G அல்லது அதற்கு மேல் பயன்படுத்தவும். ஏனெனில் 1G file முழுவதும் host-ன் cache-க்குள் இருக்கக்கூடும்; இதனால் result செயற்கையாக அதிகமாகத் தோன்றும்.

Queue depth 1, raw latency-ஐக் காட்டும். இதையே single-threaded process உணரும்:

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

Commit test, database behaviour-ஐ கணிக்க உதவும். இது ஒவ்வொரு write-க்குப் பிறகும் 4k எழுதிக் கொண்டு fdatasync()-ஐ அழைக்கும். எனவே காட்டப்படும் rate-ல் 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

அந்த run-ல் கிடைக்கும் IOPS figure, ஒரு database connection commit செய்யக்கூடிய சிறிய transactions-ன் அதிகபட்ச எண்ணிக்கைக்கு நெருக்கமாக இருக்கும். காரணம், commit அதே flush நிறைவடையும் வரை காத்திருக்கும்.

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

mdev value-ஆன mean deviation, average-க்கு இணையான முக்கியத்துவம் கொண்டது. Idle box-ல் deviation அதிகமாக இருந்தால், storage backend shared-ஆக இருந்து busy நிலையில் உள்ளது என்று பொருள்.

முடிவை எவ்வாறு படிப்பது

2026 July நிலவரப்படி, சிறிய VPS-க்கு இவை நியாயமான அளவீடுகள். queue depth 32-ல் 4k random read IOPS பல்லாயிரமாகவும், queue depth 1 latency சுமார் 0.3 ms-க்கு குறைவாகவும் இருந்தால், அது local flash-க்கு ஏற்புடையது. queue depth 1 latency பல milliseconds ஆக இருந்தால், plan எவ்வாறு அழைக்கப்பட்டாலும் அது network path-ஐ குறிக்கிறது. சுமார் 550 MB/s-ல் நின்றுவிடும் sequential reads, SATA link-ன் அடையாளமாகும். எந்த ஒரு தனிப்பட்ட device-மும் செய்யக்கூடிய அளவைவிட மிகவும் அதிகமான மதிப்பு இருந்தால், அந்த path-ல் caching உள்ளது; இது பெரும்பாலும் host-ல் நடக்கும்.

உங்கள் live workload disk-ஐ எவ்வாறு பாதிக்கிறது என்பதைப் பார்க்க:

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

iostat -x output-ல், ஒரு request காத்திருந்த சராசரி நேரமான r_await மற்றும் w_await, மேலும் சராசரி queue length-ஆன aqu-sz ஆகியவற்றைப் படிக்கவும். Virtual disk-ல் %util-ஐ புறக்கணிக்கவும். குறைந்தது ஒரு request செயல்பாட்டில் இருந்த நேரத்தின் பங்கை இது காட்டுகிறது. ஒரே நேரத்தில் பல requests-ஐ கையாளும் device-ல் saturation நிலையை இது மட்டும் காட்டாது. எனவே, %util 100-ஆகவும் r_await 0.2 ms-ஆகவும் இருந்தால், அது நன்றாகச் செயல்படும் busy disk-ஐ குறிக்கிறது. vmstat-ல், wa column என்பது IO-க்காக காத்திருப்பதில் செலவான CPU time-ன் சதவீதமாகும். உங்கள் kernel-ல் /proc/pressure/io இருந்தால், அதன் some avg10= value என்பது கடந்த 10 seconds-ல் குறைந்தது ஒரு task IO காரணமாக stalled நிலையில் இருந்த நேரத்தின் பங்காகும். Storage உங்கள் bottleneck-ஆக உள்ளதா என்ற கேள்விக்கு இது மிகவும் நேரடியான பதிலை வழங்குகிறது.

disk-bound VPS எப்படி இருக்கும்

CPU idle நிலையில் இருந்தும் load average அதிகமாகவும், vmstat-ல் பெரிய wa மதிப்பும் இருந்தால், processes disk-ஐ சார்ந்து queue-ல் காத்திருக்கின்றன என்று பொருள். இதற்கான தெளிவான kernel signal, dmesg -T-ல் காணப்படும் இந்த message ஆகும்:

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

storage பதிலளிக்க இரண்டு minutes-க்கும் மேல் kernel thread ஒன்று காத்திருந்ததால் இந்த line தோன்றுகிறது. எனவே hung task watchdog இதை log செய்துள்ளது. jbd2 என்பது ext4 journal thread ஆகும். இதனால், சரியாக செயல்படாத ஒரு program மட்டும் அல்லாமல் முழு filesystem-மும் காத்திருந்தது என்பதை அறியலாம். VPS-ல் இது பொதுவாக storage backend பிரச்சினையையோ, IOPS allowance முழுமையாக பயன்படுத்தப்பட்டதையையோ குறிக்கும்.

Application symptoms-லும் இதே pattern காணப்படும். Median response time ஏற்றுக்கொள்ளத்தக்க நிலையில் இருக்கும். ஆனால் disk-ஐ அணையும் requests மட்டும் அதிக நேரம் எடுத்துக்கொள்வதால், slowest requests-ன் tail நீளமாகும். apt upgrade, Unpacking நிலையில் minutes கணக்கில் இருக்கும்; ஏனெனில் எழுதும்போது dpkg flush செய்கிறது. பெரிய repository-ல் git status seconds கணக்கில் எடுக்கும். இவை metadata மற்றும் flush costs ஆகும். எனவே கூடுதல் bandwidth இதைச் சரிசெய்யாது.

disk-ஐ வரம்பாக எதிர்கொள்ளும்போது செய்ய வேண்டியது

IOPS வாங்குவதற்கு முன் RAM வாங்குங்கள். Working set page cache-க்குள் பொருந்தினால், reads disk-ஐ அடைவதே இல்லை. Memory-ஐ இரட்டிப்பாக்குவது, வேகமான storage class-க்கு மாறுவதைவிட பெரும்பாலும் அதிகப் பயன் தரும்; பொதுவாகச் செலவும் குறைவாக இருக்கும்.

Data அனுமதிக்கும் இடங்களில் flush-களின் எண்ணிக்கையைக் குறைக்கவும். PostgreSQL-ல், synchronous_commit = off பயன்படுத்தினால் write disk-ல் எழுதப்படுவதற்கு முன்பே commit திரும்பலாம். Server செயலிழந்தால், கடைசி fraction of a second-இல் நடந்த transactions இழக்கப்படலாம். Write-ahead log இன்னும் வரிசைப்படி எழுதப்படுவதால் database corrupted ஆகாது. இந்த trade analytics copy-க்கு பொருத்தமானது; payments-க்கு பொருத்தமானதல்ல. MySQL-ல் உள்ள innodb_flush_log_at_trx_commit = 2 இதே trade-ஐ வழங்குகிறது.

சிறிய files-ஐ batch செய்யவும். ஒரு million சிறிய files-ஐ transfer அல்லது backup செய்யும்போது, ஒவ்வொரு file-க்குமான செலவே பெரும்பகுதியை நிர்ணயிக்கும். எனவே முதலில் archive செய்து, ஒரே stream-ஐ நகர்த்துவது, high-latency storage-ல் tree-ஐ file-by-file copy செய்வதைவிட வேகமானது.

Thin volumes-ல் discard செயல்படுவதை உறுதிப்படுத்தவும். Thin provisioned storage-ல், filesystem தெரிவிக்கும் வரை எந்த block free என்பதை backend அறியாது. ஒருபோதும் trim செய்யாத volume-ன் write performance படிப்படியாகக் குறையும். Ubuntu இதற்காக weekly timer-ஐ வழங்குகிறது:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av ஒவ்வொரு mount point-க்கும் trim செய்யப்பட்ட bytes-ன் எண்ணிக்கையை அச்சிடுகிறது. Discard operation supported அல்ல என்ற message வந்தால், virtual disk discard-ஐ host-க்கு pass through செய்யவில்லை என்று பொருள். அதை நீங்கள் சரிசெய்ய வேண்டியதில்லை.

IO scheduler tuning-ஐ தவிர்க்கவும். virtio disk-ல், cat /sys/block/vda/queue/scheduler பொதுவாக ஏற்கனவே none என்பதைக் காட்டும். உண்மையான scheduling host-ல் நடப்பதால், அதற்கான access உங்களிடம் இருக்காது. noatime-ஐயும் தவிர்க்கவும்: Ubuntu இயல்பாக relatime உடன் mount செய்கிறது; இதனால் பெரும்பாலான atime writes ஏற்கனவே தவிர்க்கப்படுகின்றன.

திட்டத்தைத் தேர்ந்தெடுத்தல்

Database, mail server, CI runner அல்லது package-heavy build server-ல் இயங்கினால் NVMe-க்கு பணம் செலுத்துங்கள். Cache செய்யப்பட்ட website-க்கு அல்லது அதன் நேரத்தின் பெரும்பகுதி external calls-ல் செலவாகும் app-க்கு premium செலுத்த வேண்டாம். உறுதியாகத் தெரியவில்லை என்றால், disk உங்கள் வரம்பாக இருக்க வாய்ப்பு குறைவு; பெரும்பாலான சிறிய VPS workloads முதலில் RAM அல்லது bandwidth பற்றாக்குறையை எதிர்கொள்கின்றன.

முதல் நாளிலேயே, புதிய VPS-ல் முதல் பத்து நிமிடங்களை நிறைவேற்றும் போது, அளவீடுகளை எடுத்து, output-ஐ ஒரு file-ல் சேமிக்கவும். Host மெதுவாகிவிட்டதா, அல்லது உங்கள் code-தான் காரணமா என்பதை பின்னர் நிரூபிக்க baseline உதவும். Storage class மற்றும் IOPS cap பற்றிய விவரங்களை எழுத்துப்பூர்வமாகக் குறிப்பிடும் providers-ஐ முன்னுரிமை அளித்து தேர்ந்தெடுக்கவும். ஒரு plan-ல் NVMe என்று குறிப்பிடப்பட்டிருந்தும், queue depth 1 read 4 ms எடுத்தால், NVMe பொருத்தப்பட்ட host-ல் network storage பயன்படுத்தப்படுகிறது. அதை விற்பனை செய்வது நியாயமானது; ஆனால் வாங்குவது வேறுபட்ட தயாரிப்பு.

FAQ

VPS-ல் NVMe எப்போதும் SATA SSD-யைவிட வேகமாக இருக்குமா?

இல்லை. queue depth 1 நிலையில் இரண்டும் நெருக்கமான செயல்திறனை வழங்கும்; 4k read-க்கு பொதுவாக 80 முதல் 150 microseconds வரை இருக்கும். Single-threaded program-ஆல் இரண்டிற்கும் இடையிலான வேறுபாட்டை அறிய முடியாது. பல requests ஒரே நேரத்தில் செயல்பாட்டில் இருக்கும்போது NVMe முன்னிலை பெறும். காரணம், AHCI-ல் 32 commands ஆழமுள்ள ஒரு queue மட்டுமே உள்ளது; NVMe-ல் ஆயிரக்கணக்கான ஆழமான queues உள்ளன. Shared host-ல் பிற guests உருவாக்கும் load, storage medium-ஐவிட உங்கள் latency-யை அதிகமாக மாற்றக்கூடும். எனவே plan name-ஐ மட்டும் பார்க்காமல், fio மூலம் உங்கள் சொந்த volume-ஐ அளவிடவும்.

என் VPS உண்மையில் NVMe-ஐ பயன்படுத்துகிறதா என்பதை எப்படிச் சரிபார்ப்பது?

இதை நேரடியாகச் சரிபார்க்க முடியாது. காரணம், virtio physical device-ஐ மறைக்கிறது. lsblk, model string இல்லாமல் vda-ஐ காட்டும். nvme list எந்த output-உம் வழங்காது. /sys/block/vda/queue/rotational hypervisor விளம்பரப்படுத்தும் தகவலை மட்டுமே தெரிவிக்கும். எனவே, device-ன் செயல்பாட்டை அளவிடவும். queue depth 1 random 4k read, சுமார் 0.3 ms-க்கு குறைவான latency-யை வழங்கினால், அது local flash என்பதைக் குறிக்கும். பல milliseconds latency இருந்தால், path-ல் network hop உள்ளது. Sequential reads சுமார் 550 MB/s அருகே நின்றால், SATA link இருப்பதைக் குறிக்கும்.

NVMe என் website-ஐ வேகமாக load செய்யுமா?

பொதுவாக இல்லை. முதல் request-க்குப் பிறகு Linux files-ஐ RAM-ல் உள்ள page cache-லிருந்து வழங்கும். ஆகவே disk idle நிலையில் இருக்கும். சிறிய VPS-ல் page speed பொதுவாக application CPU time மற்றும் bandwidth-ஆல் வரையறுக்கப்படும். ஒவ்வொரு request-க்கும் site எழுதினால் disk மீண்டும் critical path-க்கு வரும். உதாரணமாக, அடிக்கடி commit செய்யும் database-backed cart-ல், ஒவ்வொரு commit-உம் flush முடியும் வரை காத்திருக்க வேண்டும்.

VPS-க்கு நல்ல fio result என்றால் என்ன?

July 2026 நிலவரப்படி, local flash கொண்ட சிறிய VPS ஒன்று queue depth 32-ல் பொதுவாக பத்தாயிரக்கணக்கான 4k random read IOPS வழங்கும். queue depth 1-ல் latency 0.3 ms-க்கு குறைவாக இருக்கும். Network block storage பொதுவாக சில ஆயிரம் IOPS மற்றும் சில milliseconds latency வழங்கும். வெவ்வேறு நேரங்களில் test-ஐ 3 முறை இயக்கவும். Runs-க்கு இடையில் அதிக வேறுபாடு இருந்தால், average-ஐவிட அது அதிக தகவலை வழங்கும். காரணம், host-ல் உள்ள பிற guests உங்கள் செயல்திறனை எவ்வளவு பாதிக்கின்றன என்பதை அது காட்டுகிறது.

என் database-ஐ network block storage-ல் வைக்கலாமா?

வைக்கலாம். பல managed services இதைப் பயன்படுத்துகின்றன. ஆனால் commit path இதற்கான செலவைச் செலுத்தும். ஒவ்வொரு flush-உம் network வழியாகச் செல்லும். எனவே, local flash-ல் கிடைப்பதைவிட ஒரு connection ஒரு second-க்கு குறைவான சிறிய transactions-ஐ மட்டுமே commit செய்யும். அதற்குப் பதிலாக, host-ஐத் தாண்டியும் நீடிக்கும் durability கிடைக்கும். Write-heavy database-க்கு network storage தேர்வு செய்தால், work-ஐ பெரிய transactions-ஆக group செய்யவும். இதனால் அதிக rows-ஐக் கொண்ட குறைவான flush-கள் போதுமானதாக இருக்கும்.