VPS-க்கு NVMe, SATA 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)-ஐப் பயன்படுத்துகிறது. இரண்டிலும் உங்கள் bytes-ஐ வைத்திருக்கும் memory chips ஒரே மாதிரியாக இருக்கலாம்.

மாற்றம் storage-ல் அல்ல, command path-ல் உள்ளது. இதில் இரண்டு முக்கிய வேறுபாடுகள் உள்ளன.

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

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

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

Network block storage என்பது வேறுபட்ட செயல்முறைகளைக் கொண்ட மூன்றாவது வகை. ஒரு write, network வழியாக storage cluster-ஐ அடைகிறது. Cluster அதைப் பெற்றிருப்பதை உறுதிப்படுத்திய பின்னரே அது acknowledged ஆகும். எனவே அதன் 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"
  }
]

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

Latency என்பது பயனர்கள் உணரும் அலகிலேயே இதையே காட்டுகிறது. p99 read latency என்பது requests-இன் மெதுவான 1 சதவீதத்தைக் குறிக்கும். இது 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 column மற்றும் latency column காட்டுகின்றன.

எந்த workloads-கள் disk-ஐ கவனிக்கின்றன

அனைத்திற்கும் ஒரு விதி பொருந்தும்: ஒரு workload, disk-க்காக காத்திருக்கும்போது மட்டுமே disk-ஐ கவனிக்கும். Linux, சமீபத்தில் பயன்படுத்தப்பட்ட file data-வை page cache-இல் RAM-ல் வைத்திருக்கும். எனவே, ஒரு 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= மதிப்பு, 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-ஐ scan செய்யும் 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-இல் இருக்கும்.

எந்த workload-கள் disk வேகத்தை கவனிக்காது

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

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

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

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

hypervisor முக்கியமானது; medium-மும் அதே அளவு முக்கியமானது

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

guest-க்குள் இருந்து medium-ஐ பார்க்க முடியாது. lsblk -d -o NAME,ROTA,SIZE,MODEL, model காலியாக உள்ள vda-ஐக் காட்டுகிறது. ஏனெனில் virtio drive identity-ஐ கடத்தாது. cat /sys/block/vda/queue/rotational, hypervisor அறிவிக்கும் தகவலைப் பதிவுசெய்கிறது. ஆகவே அங்கு 0 இருப்பது flash-க்கான ஆதாரம் அல்ல. 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 எண்களை அதிகமாக மாற்றும். Host-ல் writeback caching இயக்கப்பட்டிருந்தால், guest-இல் செய்யப்படும் fsync(), host தனது RAM-ல் data-ஐ வைத்தவுடன் முடிந்ததாகத் திரும்பலாம். எந்த physical device-மும் வழங்க முடியாத முடிவை benchmark உருவாக்கும். Database பாதுகாப்பாக சேமிக்கப்பட்டதாகக் கருதும் writes-ஐ host crash இழக்கக்கூடும் என்பதும் இதன் பொருள். none cache mode-இல் எண்கள் குறைவாகவும் நம்பகமானதாகவும் இருக்கும்.

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

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

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

நிலையான IO benchmark ஆன fio-ஐ install செய்து அளவிடவும். முதலில் 3 எச்சரிக்கைகள். இந்த test ஒரு file-ஐ உருவாக்கும். எனவே இது disk space-ஐ பயன்படுத்தும். நீங்கள் கட்டணம் செலுத்தும் எந்த IOPS allowance-க்கும் இது கணக்கில் சேரும். Runs-ஐ குறுகியதாக வைத்திருக்கவும். 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-ஐ தவிர்க்கிறது. எனவே result, உங்கள் RAM-ஐ அல்லாமல் device-ஐ விவரிக்கும். இதை விடுத்தால் நீங்கள் memory-ஐ அளவிடுவீர்கள். அப்போது எந்த disk-மும் அடைய முடியாத ஒரு எண்ணைப் பெறுவீர்கள். இடம் இருந்தால் --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-ஐ கணிக்கிறது. இது 4k-ஐ எழுதுகிறது. ஒவ்வொரு write-க்குப் பிறகும் fdatasync()-ஐ அழைக்கிறது. எனவே reported 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 இல்லாமல் விரைவான sample பெற:

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

Mean deviation ஆன mdev value, average அளவுக்கு முக்கியமானது. Idle box-இல் பெரிய deviation இருந்தால், storage backend shared-ஆகவும் busy-ஆகவும் உள்ளது.

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

July 2026 நிலவரப்படி, சிறிய 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-ஐக் குறிக்கிறது. Sequential read வேகம் 550 MB/s அருகே நின்றுவிட்டால், அது SATA link-ன் அடையாளம். எந்த ஒரு தனிப்பட்ட device-மும் வழங்கக்கூடிய வேகத்தைவிட எண்ணிக்கை மிகவும் அதிகமாக இருந்தால், அந்தப் பாதையில் caching உள்ளது; இது பெரும்பாலும் host-ல் நிகழ்கிறது.

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

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

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

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

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

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

Storage பதிலளிக்க இரண்டு நிமிடங்களுக்கு மேல் 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 மட்டும் தாமதமடைவதால், மிகவும் மெதுவான requests-களின் tail நீளமாகிறது. apt upgrade, dpkg எழுதும்போது flush செய்வதால், Unpacking நிலையில் பல minutes இருக்கும். பெரிய repository-யில் git status seconds எடுக்கும். இவை metadata மற்றும் flush costs ஆகும். ஆகவே அதிக bandwidth உதவாது.

disk வரம்பாக இருக்கும் போது செய்ய வேண்டியது

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

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

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

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

systemctl status fstrim.timer
sudo fstrim -av

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

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

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

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

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

FAQ

NVMe ஒரு VPS-இல் 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 விளம்பரப்படுத்தும் தகவலை மட்டுமே தெரிவிக்கும். அதற்குப் பதிலாக செயல்பாட்டை அளவிடுங்கள். queue depth 1 random 4k read சுமார் 0.3 ms-க்குக் குறைவாக இருந்தால், அது local flash-ஐக் குறிக்கிறது. பல milliseconds இருந்தால், 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-இலும் website எழுதினால் 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-ஐ வழங்கும்; latency சில milliseconds ஆக இருக்கும். வெவ்வேறு நேரங்களில், test-ஐ 3 முறை இயக்குங்கள். runs-க்கிடையே பெரிய வேறுபாடு இருந்தால், average-ஐ விட அது அதிக தகவலை வழங்குகிறது. காரணம், host-இல் உள்ள பிற guests உங்களை எவ்வளவு பாதிக்கின்றன என்பதை அது காட்டுகிறது.

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

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