VPS హోస్టింగ్ కోసం NVMe SSD అవసరమా? పూర్తి వివరాలు

VPSలో NVMe ముఖ్యమా?

మీ సాఫ్ట్‌వేర్ అనేక చిన్న రీడ్ (read) మరియు రైట్ (write) ఆపరేషన్లను పంపి, ప్రతి ఒక్కటి పూర్తయ్యే వరకు వేచి ఉన్నప్పుడు VPSలో NVMe ముఖ్యమైనదిగా మారుతుంది. క్యాష్ చేసిన పేజీలను అందించే సైట్‌లకు లేదా నెట్‌వర్క్ కోసం వేచి ఉండే ప్రోగ్రామ్‌లకు దీని వల్ల పెద్దగా మార్పు ఉండదు. నిల్వ మాధ్యమం అనేది ఒక అంశం మాత్రమే. డిస్క్ ముందు ఉండే హైపర్‌వైజర్ (hypervisor) మరియు అదే హోస్ట్‌ను పంచుకునే ఇతర గెస్ట్ మెషీన్లు, మీరు వాస్తవానికి పొందే పనితీరుపై పరిమితిని విధిస్తాయి.

NVMeలో ఏమి మారుతుంది, ఏమి మారదు

NVMe (non-volatile memory express) అనేది ఒక రకమైన ఫ్లాష్ మెమరీ కాదు. ఇది ఫ్లాష్‌ను చేరుకోవడానికి ఉపయోగించే ప్రోటోకాల్ మరియు కనెక్షన్. ఒక NVMe పరికరం PCIe (peripheral component interconnect express) లేన్‌లపై ఉంటుంది మరియు NVMe భాషలో మాట్లాడుతుంది. ఒక SATA (serial ATA) SSD అనేది SATA లింక్‌పై ఉంటుంది మరియు AHCI (advanced host controller interface) భాషలో మాట్లాడుతుంది. మీ డేటాను నిల్వ చేసే మెమరీ చిప్‌లు రెండింటిలోనూ ఒకేలా ఉండవచ్చు.

రెండు విషయాలు భిన్నంగా ఉంటాయి, మరియు ఇవి రెండూ నిల్వ సామర్థ్యం కంటే కమాండ్ పాత్‌కు సంబంధించినవి.

క్యూలు (Queues). AHCI కెర్నల్‌కు 32 కమాండ్‌లను కలిగి ఉండే ఒక కమాండ్ క్యూను ఇస్తుంది. NVMe వేలకొద్దీ క్యూలను అనుమతిస్తుంది, ఆచరణలో ప్రతి CPU కోర్‌కు ఒకటి చొప్పున, ప్రతి క్యూ 32 కంటే చాలా లోతుగా ఉంటుంది. ఒక సమయంలో ఒక బ్లాక్‌ను చదివే ప్రాసెస్ ఈ వ్యత్యాసాన్ని గుర్తించలేదు. 64 రీడ్ రిక్వెస్ట్‌లు పెండింగ్‌లో ఉన్న డేటాబేస్ దీనిని గుర్తించగలదు: SATAలో 33వ రిక్వెస్ట్ క్యూ స్లాట్ కోసం వేచి ఉండాలి, కానీ NVMe పరికరం వాటన్నింటినీ స్వీకరించి వాటిపై ఒకేసారి పనిచేస్తుంది.

లింక్ వెడల్పు (Link width). ఒక SATA III లింక్ 6 Gbit/s వేగంతో పనిచేస్తుంది, ఇది ప్రోటోకాల్ ఓవర్‌హెడ్ తర్వాత సుమారు 550 MB/s నిజమైన డేటాను అందిస్తుంది. దీని వెనుక ఏ ఫ్లాష్ ఉన్నా, ఇది ఒక స్థిరమైన పరిమితి. నాలుగు PCIe లేన్‌లు సెకనుకు అనేక గిగాబైట్ల డేటాను తీసుకువెళతాయి, కాబట్టి లింక్ ఇకపై పరిమితిగా ఉండదు.

లేటెన్సీ (Latency) విషయంలోనే సాధారణంగా అంచనాలు తప్పుగా ఉంటాయి. క్యూ డెప్త్ 1 వద్ద, అంటే ఒకే రిక్వెస్ట్ ప్రాసెస్‌లో ఉన్నప్పుడు, ఒక SATA SSD 4k రీడ్‌కు సుమారు 100 నుండి 150 మైక్రోసెకన్లలో సమాధానం ఇస్తుంది. NVMe సుమారు 80 నుండి 100 మైక్రోసెకన్లలో సమాధానం ఇస్తుంది. రెండూ వేగవంతమైనవే, మరియు ఒకే రిక్వెస్ట్ విషయంలో మీరు రన్ చేసే ఏ అప్లికేషన్ కూడా ఈ వ్యత్యాసాన్ని గమనించదు. కాన్కరెన్సీ (concurrency) పెరిగినప్పుడు ఈ వ్యత్యాసం కనిపిస్తుంది. క్యూ డెప్త్, అంటే ఒకే సమయంలో ప్రాసెస్‌లో ఉన్న రిక్వెస్ట్‌ల సంఖ్య, ఈ రెండు మాధ్యమాలు ఒకేలా ఉన్నాయా లేదా చాలా భిన్నంగా ఉన్నాయా అని నిర్ణయించే సెట్టింగ్.

నెట్‌వర్క్ బ్లాక్ స్టోరేజ్ అనేది భౌతిక ధర్మాలలో భిన్నమైన మూడవ తరగతి. ఒక రైట్ ఆపరేషన్ నెట్‌వర్క్ ద్వారా స్టోరేజ్ క్లస్టర్‌కు చేరుతుంది మరియు క్లస్టర్ దానిని స్వీకరించిన తర్వాత మాత్రమే అక్నాలెడ్జ్‌మెంట్ వస్తుంది, కాబట్టి దీని లేటెన్సీ మైక్రోసెకన్లకు బదులుగా మిల్లీసెకన్లలో కొలుస్తారు. ఈ లేటెన్సీ కోసం మీరు చెల్లించేది మన్నిక (durability) కోసం: వాల్యూమ్ అది అనుసంధానించబడిన హోస్ట్ కంటే ఎక్కువ కాలం ఉంటుంది, మరియు దానిని స్నాప్‌షాట్ తీయవచ్చు మరియు రీసైజ్ చేయవచ్చు.

సాధారణంగా ప్రచురించబడిన గణాంకాలు: NVMe, SATA SSD మరియు నెట్‌వర్క్ స్టోరేజ్

[
  {
    "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 పరికరం సాధారణంగా క్యూ డెప్త్ 32 వద్ద 184,000 రాండమ్ 4k రీడ్ IOPS (సెకనుకు ఇన్‌పుట్/అవుట్‌పుట్ ఆపరేషన్లు) సామర్థ్యాన్ని కలిగి ఉంటుందని పేర్కొనబడింది. SATA SSDపై ఇదే పరీక్షను నిర్వహించినప్పుడు, సింగిల్ AHCI క్యూ మరియు 6 Gbit/s లింక్ పరిమితుల కారణంగా ఇది 90,000 వద్ద ఉంటుంది. నెట్‌వర్క్ బ్లాక్ స్టోరేజ్ సామర్థ్యం సాధారణంగా హార్డ్‌వేర్ కంటే ప్రొవైడర్ విధించే పరిమితులపై ఆధారపడి ఉంటుంది, మరియు 12,500 అనేది సాధారణంగా డాక్యుమెంట్ చేయబడిన గరిష్ట పరిమితి.

మీ వినియోగదారులు అనుభవించే యూనిట్లలో లేటెన్సీ (Latency) ఇదే విషయాన్ని తెలియజేస్తుంది. p99 రీడ్ లేటెన్సీ, అంటే అత్యంత నెమ్మదిగా ఉండే 1 శాతం అభ్యర్థనలు, లోకల్ NVMeపై సుమారు 0.4 ms మరియు SATAపై 1.2 ms ఉంటుంది. నెట్‌వర్క్‌ను మధ్యలో చేర్చినప్పుడు ఇది 6.5 ms అవుతుంది, ఇది NVMe గణాంకం కంటే పది రెట్లు ఎక్కువ.

సీక్వెన్షియల్ రీడ్స్ విషయంలో వ్యత్యాసం ఎక్కువగా ఉంటుంది, కానీ ఇది తక్కువ ఉపయోగకరమైనది: 3,400 MB/s మరియు 550 MB/s. సర్వర్‌లో ఏదీ ఒక పెద్ద ఫైల్‌ను మొదటి నుండి చివరి వరకు పూర్తి వేగంతో చదవదు. రాండమ్ కాలమ్ మరియు లేటెన్సీ కాలమ్ ఒక డేటాబేస్, మెయిల్ క్యూ లేదా ప్యాకేజీ మేనేజర్ వాస్తవానికి ఏమి చేస్తాయో వివరిస్తాయి.

ఏ వర్క్‌లోడ్‌లు డిస్క్‌ను గమనిస్తాయి

వాటన్నింటికీ ఒకే నియమం వర్తిస్తుంది: ఒక వర్క్‌లోడ్ డిస్క్ కోసం వేచి ఉన్నప్పుడు మాత్రమే అది డిస్క్‌ను గమనిస్తుంది. Linux ఇటీవల ఉపయోగించిన ఫైల్ డేటాను RAMలో, పేజీ కాష్‌లో ఉంచుతుంది, కాబట్టి ఒక ఫైల్‌ను రెండోసారి చదివినప్పుడు అది స్టోరేజ్‌కు వెళ్లదు. వర్కింగ్ సెట్, అంటే వాస్తవానికి ఉపయోగంలో ఉన్న డేటా, RAMలో సరిపోతే, మొదటిసారి చదివిన తర్వాత రీడ్ ఆపరేషన్లు మెమరీ రీడ్స్‌గా మారుతాయి. రైట్ ఆపరేషన్లు భిన్నంగా ఉంటాయి. అప్లికేషన్ fsync() ద్వారా ఫ్లష్ చేసే ఏదైనా రైట్ ఆపరేషన్, అప్లికేషన్ కొనసాగడానికి అనుమతించబడటానికి ముందే స్థిరమైన స్టోరేజ్‌లో ఉండాలి.

కమిట్ చేసే పని. PostgreSQL, MySQL మరియు SQLite కమిట్ సమయంలో fsync() లేదా fdatasync()ని పిలుస్తాయి, మరియు ప్రతి కమిట్ డివైజ్ నుండి సమాధానం కోసం వేచి ఉంటుంది. కాబట్టి ఒక కనెక్షన్ యొక్క కమిట్ రేటు బ్యాండ్‌విడ్త్ ద్వారా కాకుండా, రైట్ లేటెన్సీ ద్వారా నిర్ణయించబడుతుంది. 0.2 msలో ఫ్లష్ చేసే డివైజ్, 5 ms తీసుకునే డివైజ్ కంటే సెకనుకు ఎక్కువ కమిట్‌లను అనుమతిస్తుంది, మరియు ఎంత త్రూపుట్ ఉన్నా అది మారదు. ఫ్లష్ వేగం సరిపోనప్పుడు MySQL ఎర్రర్ లాగ్‌లో ఇలా చెబుతుంది:

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

PostgreSQL దీనిని తన చెక్‌పాయింట్ లైన్లలో నివేదిస్తుంది, అక్కడ పెద్ద sync= విలువ అంటే ఫ్లష్ ప్రక్రియ నెమ్మదిగా ఉందని అర్థం:

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

అనేక చిన్న ఫైళ్లను తాకే పని. ప్రతి ఫైల్ మెటాడేటా ఆపరేషన్లను కలిగి ఉంటుంది, ఇవి పెద్ద సీక్వెన్షియల్ రీడ్‌లో ఉండవు. npm install, పెద్ద రిపోజిటరీ యొక్క git clone, కంటైనర్ ఇమేజ్‌లను అన్‌ప్యాక్ చేయడం, Maildir మెయిల్ స్టోర్ మరియు పెద్ద ట్రీని వాక్ చేసే బ్యాకప్ అన్నీ తమ సమయాన్ని చిన్న రాండమ్ యాక్సెస్ కోసం వెచ్చిస్తాయి. ఒక VPSపై restic బ్యాకప్ జాబ్ తాను ఇంతకు ముందు చూడని ప్రతి ఫైల్‌ను చదివి హ్యాష్ చేస్తుంది, కాబట్టి మిలియన్ ఫైళ్లపై బ్యాకప్ తీసుకునే సమయం రాండమ్ రీడ్ లేటెన్సీని దగ్గరగా అనుసరిస్తుంది. du -sh విషయంలో కూడా ఇదే నిజం, ఇది మెటాడేటాను మాత్రమే చదువుతుంది.

RAM పరిమితిని మించే డేటాబేస్‌లు కూడా ఈ వర్గంలోకే వస్తాయి. ఇండెక్స్ ఇకపై పేజీ కాష్‌లో సరిపోనప్పుడు, ప్రతి లుకప్ ఒక రాండమ్ రీడ్‌గా మారుతుంది మరియు డిస్క్ మళ్లీ క్రిటికల్ పాత్‌లోకి వస్తుంది.

ఏ వర్క్‌లోడ్‌లు డిస్క్ పనితీరును గమనించవు

బ్లాగ్ లేదా చిన్న కంపెనీ సైట్. పేజీలు చిన్నవిగా ఉంటాయి. మొదటి అభ్యర్థన తర్వాత పేజీ కాష్ (page cache) వాటన్నింటినీ నిల్వ చేస్తుంది. రెండరింగ్ కోసం CPU లేదా అసెట్స్ కోసం బ్యాండ్‌విడ్త్ పరిమితిగా ఉంటాయి. తక్కువ ట్రాఫిక్ ఉన్న సైట్‌ను అందించే Ubuntu 24.04 పై LAMP stack వేడెక్కిన తర్వాత దాదాపు ఎటువంటి డిస్క్ IOని ఉపయోగించదు.

మీడియా స్ట్రీమింగ్. 40 Mbit/s వేగంతో ఒక 4K స్ట్రీమ్ 5 MB/s డేటాను చదువుతుంది. పది స్ట్రీమ్‌లు 50 MB/s డేటాను చదువుతాయి, దీనిని నెట్‌వర్క్ బ్లాక్ స్టోరేజ్ కూడా సులభంగా అందించగలదు. VPS పై Jellyfin మీడియా సర్వర్ మీ నెట్‌వర్క్ ఈగ్రెస్ (egress) పరిమితి ద్వారా మరియు ట్రాన్స్‌కోడింగ్ చేసేటప్పుడు CPU ద్వారా పరిమితం చేయబడుతుంది, స్టోరేజ్ మాధ్యమం ద్వారా కాదు.

లోకల్ మోడల్ ఇన్ఫరెన్స్. LLMని సెల్ఫ్-హోస్ట్ చేయడానికి VPSలో Ollamaని రన్ చేయడం మోడల్ ఫైల్‌ను ఒకసారి చదివి, ఆపై RAMలో పనిచేస్తుంది. NVMe 20 GB మోడల్ లోడ్ అయ్యే సమయాన్ని నిమిషాల నుండి సెకన్లకు తగ్గిస్తుంది. ఇది టోకెన్ల వేగాన్ని మార్చదు, ఎందుకంటే అది మెమరీ బ్యాండ్‌విడ్త్ మరియు CPUపై ఆధారపడి ఉంటుంది.

బాహ్య సేవ కోసం వేచి ఉండే ఏదైనా. ప్రతి జాబ్‌కు HTTP అభ్యర్థన కోసం 800 ms సమయం తీసుకునే వర్కర్, మెరుగైన డిస్క్ ఉన్నంత మాత్రాన వేగంగా పనిచేయదు.

హైపర్‌వైజర్ మాధ్యమంతో సమానంగా ఎందుకు ముఖ్యమైనది

మీరు నేరుగా పరికరంతో సంభాషించరు. హైపర్‌వైజర్ అందించే వర్చువల్ డిస్క్‌తో మీరు సంభాషిస్తారు, ఇది సాధారణంగా virtio ద్వారా జరుగుతుంది. ఆ పొరలో తీసుకునే అనేక నిర్ణయాలు SATA కంటే NVMeని ఎంచుకోవడం కంటే ఎక్కువ ప్రాముఖ్యతను కలిగి ఉంటాయి.

గెస్ట్ లోపలి నుండి మీరు మాధ్యమాన్ని చూడలేరు. lsblk -d -o NAME,ROTA,SIZE,MODEL ఖాళీ మోడల్‌తో vdaని చూపుతుంది, ఎందుకంటే virtio డ్రైవ్ గుర్తింపును పాస్ చేయదు. cat /sys/block/vda/queue/rotational హైపర్‌వైజర్ దేనిని ప్రకటిస్తుందో దానిని మాత్రమే నివేదిస్తుంది, కాబట్టి అక్కడ 0 ఉండటం అనేది ఫ్లాష్‌కి నిదర్శనం కాదు. nvme-cli ప్యాకేజీలోని nvme list, హోస్ట్ నిండా NVMe డ్రైవ్‌లు ఉన్నప్పటికీ చాలా VPSలలో దేనినీ చూపదు, ఎందుకంటే మీ డిస్క్ ఒక virtio పరికరం, NVMe పరికరం కాదు. NVMe అని పేర్కొనే ప్లాన్ సాధారణంగా హోస్ట్‌లో ఏముందో మాత్రమే వివరిస్తుంది. మీ వాల్యూమ్ ఇప్పటికీ నెట్‌వర్క్ ద్వారా అనుసంధానించబడి ఉండవచ్చు.

హోస్ట్ కాష్ మోడ్ మాధ్యమం కంటే ఎక్కువ ప్రభావం చూపుతుంది. హోస్ట్‌లో రైట్‌బ్యాక్ కాషింగ్ ఉన్నప్పుడు, హోస్ట్ తన సొంత RAMలో డేటాను కలిగి ఉన్న వెంటనే గెస్ట్ fsync() తిరిగి రాగలదు. ఇది ఏ భౌతిక పరికరం అందించలేని బెంచ్‌మార్క్ ఫలితాన్ని ఇస్తుంది. దీని అర్థం హోస్ట్ క్రాష్ అయినప్పుడు మీ డేటాబేస్ సురక్షితమని భావించిన రైట్‌లు పోవచ్చు. కాష్ మోడ్ noneతో, సంఖ్యలు తక్కువగా మరియు వాస్తవంగా ఉంటాయి.

క్యాప్‌లు మరియు బర్స్ట్ క్రెడిట్‌లు. చాలా మంది ప్రొవైడర్లు ప్రతి వాల్యూమ్‌కు లేదా ప్రతి ప్లాన్‌కు IOPSని పరిమితం చేస్తారు, మరియు అనేక నెట్‌వర్క్ వాల్యూమ్‌లు బర్స్ట్ అలవెన్స్‌ను ఉపయోగిస్తాయి. బర్స్ట్ అలవెన్స్ అనేది క్రెడిట్‌ల పూల్: క్రెడిట్‌లు ఉన్నంత వరకు వాల్యూమ్ వేగంగా పనిచేస్తుంది, ఆ తర్వాత చాలా తక్కువ బేస్‌లైన్‌కు పడిపోతుంది. దీని లక్షణాన్ని గుర్తించడం సులభం. ఒక ఇంపోర్ట్ లేదా రీస్టోర్ కొన్ని నిమిషాల పాటు వేగంగా నడుస్తుంది, ఆపై అకస్మాత్తుగా నెమ్మదిస్తుంది మరియు మీ కాన్ఫిగరేషన్‌లో ఏమీ మారకపోయినా అలాగే నెమ్మదిగా ఉంటుంది. మీరు క్రెడిట్‌లను ఖర్చు చేశారు.

పొరుగున ఉన్నవి (Neighbours). షేర్డ్ హోస్ట్‌లో, ఇతర గెస్ట్‌లు ఏమి చేస్తున్నాయనే దానిపై మీ డిస్క్ లేటెన్సీ మారుతూ ఉంటుంది. ఒకటికి మించి సార్లు కొలవడానికి ఇదే కారణం. ఒకే పరీక్షను ఉదయం మరియు సాయంత్రం నిర్వహించి, వ్యత్యాసాన్ని సరిపోల్చండి. బిజీగా ఉన్న హోస్ట్‌లో, ఒకే వాల్యూమ్‌పై రెండు రన్‌ల మధ్య వ్యత్యాసం, రెండు మాధ్యమాల మధ్య ప్రచురించబడిన వ్యత్యాసం కంటే ఎక్కువగా ఉంటుంది.

మీ VPSలో ఉన్న డిస్క్ సామర్థ్యాన్ని కొలవడం ఎలా

fioను ఇన్‌స్టాల్ చేయండి. ఇది ప్రామాణిక IO బెంచ్‌మార్క్ సాధనం. దీనిని ఉపయోగించి కొలవండి. ముందుగా మూడు జాగ్రత్తలు. ఈ పరీక్ష ఒక ఫైల్‌ను సృష్టిస్తుంది, కాబట్టి ఇది డిస్క్ స్థలాన్ని వినియోగిస్తుంది మరియు మీ బిల్లింగ్‌లో ఉన్న IOPS పరిమితికి ఇది లెక్కించబడుతుంది. పరీక్షలను తక్కువ సమయం పాటు నిర్వహించండి. లైవ్ ట్రాఫిక్‌ను అందిస్తున్న వాల్యూమ్‌పై పూర్తి క్యూ డెప్త్‌తో దీనిని రన్ చేయవద్దు, ఎందుకంటే ఇది మీ అప్లికేషన్‌తో పోటీ పడుతుంది.

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

వెండర్లు పేర్కొనే క్యూ డెప్త్ 32 వద్ద రాండమ్ రీడ్:

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

ముఖ్యమైన లైన్ read: తో మొదలవుతుంది:

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

--direct=1 గెస్ట్ పేజీ కాష్‌ను దాటవేస్తుంది, కాబట్టి ఫలితం మీ RAMను కాకుండా డిస్క్ పరికరాన్ని సూచిస్తుంది. దీనిని తీసివేస్తే మీరు మెమరీని కొలుస్తారు, ఇది ఏ డిస్క్ సాధించలేని వేగవంతమైన ఫలితాన్ని ఇస్తుంది. మీకు తగినంత స్థలం ఉంటే --size=4G లేదా అంతకంటే ఎక్కువ ఉపయోగించండి, ఎందుకంటే 1G ఫైల్ పూర్తిగా హోస్ట్ కాష్‌లోనే ఉండి, ఫలితాన్ని తప్పుగా చూపే అవకాశం ఉంది.

క్యూ డెప్త్ 1 అనేది రా లేటెన్సీని చూపిస్తుంది, ఇది సింగిల్-థ్రెడెడ్ ప్రాసెస్ అనుభవించే వేగం:

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

కమిట్ టెస్ట్ డేటాబేస్ పనితీరును అంచనా వేస్తుంది. ఇది 4k డేటాను రాసి, ప్రతి రైట్ తర్వాత fdatasync() ని కాల్ చేస్తుంది, కాబట్టి నివేదించబడిన రేటులో ఫ్లష్ సమయం కూడా కలిసి ఉంటుంది:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

ఆ రన్ నుండి వచ్చిన IOPS సంఖ్య, ఒక డేటాబేస్ కనెక్షన్ సెకనుకు చేయగల గరిష్ట చిన్న లావాదేవీల సంఖ్యకు దగ్గరగా ఉంటుంది, ఎందుకంటే కమిట్ కూడా అదే ఫ్లష్ కోసం వేచి ఉంటుంది.

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 విలువ, అంటే సగటు విచలనం (mean deviation), సగటు విలువతో సమానమైన ప్రాముఖ్యతను కలిగి ఉంటుంది. ఖాళీగా ఉన్న సర్వర్‌లో పెద్ద విచలనం ఉందంటే, స్టోరేజ్ బ్యాకెండ్ షేర్ చేయబడిందని మరియు బిజీగా ఉందని అర్థం.

ఫలితాలను ఎలా అర్థం చేసుకోవాలి

జూలై 2026 నాటికి, చిన్న VPS కోసం ఇవి సహేతుకమైన రీడింగ్‌లు. క్యూ డెప్త్ 32 వద్ద పదివేల 4k రాండమ్ రీడ్ IOPS మరియు 0.3 ms కంటే తక్కువ క్యూ డెప్త్ 1 లేటెన్సీ, లోకల్ ఫ్లాష్ స్టోరేజ్‌కు అనుగుణంగా ఉంటాయి. క్యూ డెప్త్ 1 లేటెన్సీ కొన్ని మిల్లీసెకన్ల వరకు ఉంటే, అది నెట్‌వర్క్ పాత్‌ను సూచిస్తుంది, ప్లాన్ పేరు ఏదైనప్పటికీ. సీక్వెన్షియల్ రీడ్స్ 550 MB/s వద్ద ఆగిపోతే, అది SATA లింక్ యొక్క లక్షణం. ఏదైనా ఒక పరికరం చేయగలిగే దానికంటే చాలా ఎక్కువ సంఖ్య కనిపిస్తే, అది పాత్‌లో క్యాషింగ్ జరుగుతోందని అర్థం, ఇది దాదాపు ఎల్లప్పుడూ హోస్ట్ స్థాయిలో ఉంటుంది.

మీ లైవ్ వర్క్‌లోడ్ డిస్క్‌పై ఎలాంటి ప్రభావం చూపుతుందో చూడటానికి:

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

iostat -x అవుట్‌పుట్‌లో, r_await మరియు w_await (ఒక అభ్యర్థన వేచి ఉన్న సగటు మిల్లీసెకన్లు) మరియు aqu-sz (సగటు క్యూ పొడవు) చూడండి. వర్చువల్ డిస్క్‌పై %utilని విస్మరించండి. ఇది కనీసం ఒక అభ్యర్థన పెండింగ్‌లో ఉన్న సమయాన్ని తెలియజేస్తుంది, ఇది ఒకేసారి అనేక అభ్యర్థనలను అందించే పరికరంలో సంతృప్తత (saturation) గురించి ఏమీ చెప్పదు. కాబట్టి, r_await 0.2 ms ఉన్నప్పుడు %util 100 ఉండటం అనేది డిస్క్ ఆరోగ్యంగా ఉందని అర్థం. vmstatలో, wa కాలమ్ IO కోసం వేచి ఉన్న CPU సమయ శాతాన్ని సూచిస్తుంది. మీ కెర్నల్‌లో /proc/pressure/io ఉంటే, దాని some avg10= విలువ గత 10 సెకన్లలో కనీసం ఒక టాస్క్ IO కోసం ఆగిపోయిన సమయాన్ని తెలియజేస్తుంది. స్టోరేజ్ మీ బాటిల్‌నెక్ (bottleneck) అవునా కాదా అనే ప్రశ్నకు ఇది అత్యంత ప్రత్యక్ష సమాధానం.

డిస్క్-బౌండ్ VPS ఎలా ఉంటుందో తెలుసుకోవడం

తక్కువ CPU వినియోగం ఉన్నప్పటికీ అధిక లోడ్ యావరేజ్ (load average) ఉండటం మరియు vmstatలో wa ఎక్కువగా ఉండటం అంటే, ప్రాసెస్‌లు డిస్క్ కోసం క్యూలో వేచి ఉన్నాయని అర్థం. dmesg -Tలో కనిపించే ఈ క్రింది సందేశం దీనికి స్పష్టమైన కెర్నల్ సంకేతం:

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

ఒక కెర్నల్ థ్రెడ్ స్టోరేజ్ నుండి స్పందన కోసం రెండు నిమిషాల కంటే ఎక్కువ సమయం వేచి ఉన్నప్పుడు, హంగ్ టాస్క్ వాచ్‌డాగ్ (hung task watchdog) ఈ లైన్‌ను లాగ్ చేస్తుంది. jbd2 అనేది ext4 జర్నల్ థ్రెడ్, అంటే ఏదో ఒక ప్రోగ్రామ్ వల్ల కాకుండా మొత్తం ఫైల్‌సిస్టమ్ వేచి ఉందని దీని అర్థం. VPSలో ఇది సాధారణంగా స్టోరేజ్ బ్యాకెండ్ సమస్యను లేదా IOPS పరిమితి ముగిసిపోయిందని సూచిస్తుంది.

అప్లికేషన్ లక్షణాలు కూడా ఇదే పద్ధతిలో ఉంటాయి. డిస్క్ కార్యకలాపాలు అవసరమైన అభ్యర్థనలు మాత్రమే ఆలస్యం అవుతాయి కాబట్టి, సగటు స్పందన సమయం (median response time) సాధారణంగానే ఉన్నా, నెమ్మదిగా ఉండే అభ్యర్థనల సమయం గణనీయంగా పెరుగుతుంది. apt upgrade అన్‌ప్యాకింగ్ సమయంలో నిమిషాల తరబడి ఆగిపోతుంది, ఎందుకంటే dpkg డేటాను రాసేటప్పుడు ఫ్లష్ చేస్తుంది. పెద్ద రిపోజిటరీలో git status పూర్తి కావడానికి సెకన్ల సమయం పడుతుంది. ఇవి మెటాడేటా మరియు ఫ్లష్ ఖర్చులు, కాబట్టి బ్యాండ్‌విడ్త్‌ను పెంచినా వీటి వల్ల ప్రయోజనం ఉండదు.

డిస్క్ పరిమితికి చేరుకున్నప్పుడు ఏమి చేయాలి

IOPS కొనే ముందు RAM కొనండి. వర్కింగ్ సెట్ పేజీ క్యాచీలో సరిపోతే, రీడ్ ఆపరేషన్లు డిస్క్ వరకు వెళ్లవు. మెమరీని రెట్టింపు చేయడం అనేది వేగవంతమైన స్టోరేజ్ క్లాస్‌కు మారడం కంటే మెరుగైన ఫలితాలను ఇస్తుంది, మరియు ఇది సాధారణంగా తక్కువ ఖర్చుతో కూడుకున్నది.

డేటా అనుమతించిన చోట, ఫ్లష్‌ల సంఖ్యను తగ్గించండి. PostgreSQLలో, synchronous_commit = off సెట్టింగ్ ద్వారా రైట్ ఆపరేషన్ డిస్క్‌పై జరగకముందే కమిట్ పూర్తయినట్లు చూపిస్తుంది. సర్వర్ ఆగిపోతే, చివరి సెకనులో జరిగిన లావాదేవీలు కోల్పోయే అవకాశం ఉంది. రైట్-అహెడ్ లాగ్ క్రమ పద్ధతిలో రాయబడుతుంది కాబట్టి డేటాబేస్ పాడవదు. ఈ మార్పు అనలిటిక్స్ కాపీలకు సరైనది, కానీ చెల్లింపుల (payments) డేటాకు ఇది తప్పు. MySQLలో innodb_flush_log_at_trx_commit = 2 కూడా ఇదే రకమైన మార్పును సూచిస్తుంది.

చిన్న ఫైళ్లను బ్యాచ్ చేయండి. మిలియన్ల కొద్దీ చిన్న ఫైళ్లను బదిలీ చేయడం లేదా బ్యాకప్ చేయడం అనేది ప్రతి ఫైల్‌కు అయ్యే ఖర్చుపై ఆధారపడి ఉంటుంది. కాబట్టి, హై-లేటెన్సీ స్టోరేజ్‌లో ఫైళ్లను ఒక్కొక్కటిగా కాపీ చేయడం కంటే, ముందుగా ఆర్కైవ్ చేసి ఒకే స్ట్రీమ్‌గా పంపడం వేగంగా జరుగుతుంది.

థిన్ వాల్యూమ్‌లపై డిస్కార్డ్ (discard) పనితీరును కొనసాగించండి. థిన్ ప్రొవిజన్డ్ స్టోరేజ్‌లో, ఫైల్‌సిస్టమ్ చెప్పే వరకు బ్లాక్ ఖాళీగా ఉందని బ్యాకెండ్‌కు తెలియదు. ట్రిమ్ (trim) చేయని వాల్యూమ్ క్రమంగా రైట్ పనితీరును కోల్పోతుంది. Ubuntu దీని కోసం వారానికోసారి నడిచే టైమర్‌ను అందిస్తుంది:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av కమాండ్ మౌంట్ పాయింట్ వారీగా ట్రిమ్ చేయబడిన బైట్‌లను చూపుతుంది. డిస్కార్డ్ ఆపరేషన్ సపోర్ట్ చేయబడలేదని సందేశం వస్తే, వర్చువల్ డిస్క్ హోస్ట్‌కు డిస్కార్డ్ కమాండ్‌ను పంపడం లేదని అర్థం. దీనిని మీరు సరిచేయలేరు.

IO షెడ్యూలర్ ట్యూనింగ్‌ను వదిలేయండి. virtio డిస్క్‌పై, cat /sys/block/vda/queue/scheduler సాధారణంగా ఇప్పటికే none అని చూపిస్తుంది. అసలైన షెడ్యూలింగ్ హోస్ట్ స్థాయిలో జరుగుతుంది, అక్కడ మీకు యాక్సెస్ ఉండదు. noatime ను కూడా వదిలేయండి: Ubuntu డిఫాల్ట్‌గా relatime తో మౌంట్ అవుతుంది, ఇది దాదాపు అన్ని atime రైట్ ఆపరేషన్లను నివారిస్తుంది.

ప్లాన్‌ను ఎంచుకోవడం

డేటాబేస్, మెయిల్ సర్వర్, CI రన్నర్ లేదా ప్యాకేజీలు ఎక్కువగా ఉండే బిల్డ్ ప్రాసెస్ సర్వర్‌లో ఉన్నప్పుడు NVMe కోసం చెల్లించండి. క్యాష్ చేయబడిన వెబ్‌సైట్ కోసం లేదా బాహ్య కాల్‌లకు ఎక్కువ సమయం కేటాయించే యాప్ కోసం అదనపు రుసుము చెల్లించవద్దు. మీకు సందేహం ఉంటే, డిస్క్ మీ పరిమితి కాకపోవచ్చు, ఎందుకంటే చాలా చిన్న VPS వర్క్‌లోడ్‌లు ముందుగా RAM లేదా బ్యాండ్‌విడ్త్ పరిమితులను చేరుకుంటాయి.

కొత్త VPSలో మొదటి పది నిమిషాలు పూర్తి చేస్తున్నప్పుడు, మొదటి రోజే కొలవండి మరియు ఆ అవుట్‌పుట్‌ను ఒక ఫైల్‌లో భద్రపరచండి. మీ కోడ్ వల్ల కాకుండా హోస్ట్ వేగం తగ్గిందని నిరూపించుకోవడానికి ఈ బేస్‌లైన్ ఉపయోగపడుతుంది. స్టోరేజ్ క్లాస్ మరియు ఏదైనా IOPS పరిమితిని వ్రాతపూర్వకంగా పేర్కొనే ప్రొవైడర్లను ఎంచుకోండి. ఒక ప్లాన్ NVMe అని చెప్పి, క్యూ డెప్త్ 1 రీడ్ 4 ms సమయం తీసుకుంటే, మీరు NVMe ఉన్న హోస్ట్‌లో నెట్‌వర్క్ స్టోరేజ్‌ను ఉపయోగిస్తున్నారని అర్థం. ఇది విక్రయించడానికి సరైనదే, కానీ కొనుగోలు చేసేటప్పుడు ఇది భిన్నమైన విషయం.

FAQ

VPSలో NVMe ఎల్లప్పుడూ SATA SSD కంటే వేగంగా ఉంటుందా?

ఉండదు. క్యూ డెప్త్ 1 వద్ద రెండూ దాదాపు సమానంగా ఉంటాయి, 4k రీడ్ కోసం సుమారు 80 నుండి 150 మైక్రోసెకన్లు పడుతుంది. సింగిల్-థ్రెడ్ ప్రోగ్రామ్ వీటి మధ్య వ్యత్యాసాన్ని గుర్తించలేదు. అనేక అభ్యర్థనలు ఒకేసారి జరుగుతున్నప్పుడు NVMe వేగంగా పనిచేస్తుంది. ఎందుకంటే AHCI 32 కమాండ్ల లోతు గల ఒకే క్యూను అందిస్తుంది, కానీ NVMe వేలకొద్దీ లోతైన క్యూలను అందిస్తుంది. షేర్డ్ హోస్ట్‌లో, ఇతర గెస్ట్‌ల లోడ్ మీ లాటెన్సీని ప్రభావితం చేస్తుంది. కాబట్టి ప్లాన్ పేరును చూసే బదులు, fio ఉపయోగించి మీ వాల్యూమ్ పనితీరును స్వయంగా కొలవండి.

నా VPS నిజంగా NVMeని ఉపయోగిస్తుందో లేదో ఎలా తనిఖీ చేయాలి?

దీనిని నేరుగా తనిఖీ చేయడం సాధ్యం కాదు, ఎందుకంటే virtio భౌతిక పరికరాన్ని దాచి ఉంచుతుంది. lsblk కమాండ్ vdaని మోడల్ స్ట్రింగ్ లేకుండా చూపిస్తుంది, nvme list ఏమీ చూపదు, మరియు /sys/block/vda/queue/rotational హైపర్‌వైజర్ అందించిన సమాచారాన్ని మాత్రమే నివేదిస్తుంది. దానికి బదులుగా పనితీరును కొలవండి. క్యూ డెప్త్ 1 వద్ద 4k రాండమ్ రీడ్ సుమారు 0.3 ms లోపు ఉంటే, అది లోకల్ ఫ్లాష్ అని అర్థం. కొన్ని మిల్లీసెకన్లు ఉంటే, నెట్‌వర్క్ హాప్ మధ్యలో ఉందని అర్థం. సీక్వెన్షియల్ రీడ్స్ 550 MB/s వద్ద ఆగిపోతే, అది SATA లింక్ అని అర్థం.

NVMe వల్ల నా వెబ్‌సైట్ వేగంగా లోడ్ అవుతుందా?

సాధారణంగా అవ్వదు. మొదటి అభ్యర్థన తర్వాత, Linux ఫైళ్లను RAMలోని పేజీ కాష్ నుండి అందిస్తుంది, కాబట్టి డిస్క్ ఖాళీగా ఉంటుంది. చిన్న VPSలో పేజీ వేగం సాధారణంగా అప్లికేషన్ CPU సమయం మరియు బ్యాండ్‌విడ్త్‌పై ఆధారపడి ఉంటుంది. వెబ్‌సైట్ ప్రతి అభ్యర్థనపై డేటాను రాస్తుంటే (ఉదాహరణకు, డేటాబేస్ ఆధారిత కార్ట్), అప్పుడు డిస్క్ కీలక పాత్ర పోషిస్తుంది. ఎందుకంటే ప్రతి కమిట్ ఫ్లష్ పూర్తయ్యే వరకు వేచి ఉండాలి.

VPS కోసం మంచి fio ఫలితం అంటే ఏమిటి?

జూలై 2026 నాటికి, లోకల్ ఫ్లాష్‌పై ఉన్న ఒక చిన్న VPS సాధారణంగా క్యూ డెప్త్ 32 వద్ద పదివేల 4k రాండమ్ రీడ్ IOPSని, మరియు క్యూ డెప్త్ 1 వద్ద 0.3 ms కంటే తక్కువ లాటెన్సీని అందిస్తుంది. నెట్‌వర్క్ బ్లాక్ స్టోరేజ్ సాధారణంగా కొన్ని మిల్లీసెకన్ల లాటెన్సీతో కొన్ని వేల IOPSని అందిస్తుంది. ఈ పరీక్షను వేర్వేరు సమయాల్లో మూడుసార్లు నిర్వహించండి. ఫలితాల మధ్య వ్యత్యాసం ఎక్కువగా ఉంటే, హోస్ట్‌లోని ఇతర గెస్ట్‌లు మిమ్మల్ని ఎంతవరకు ప్రభావితం చేస్తున్నాయో అర్థమవుతుంది.

నేను నా డేటాబేస్‌ను నెట్‌వర్క్ బ్లాక్ స్టోరేజ్‌లో ఉంచాలా?

మీరు ఉంచవచ్చు, చాలా మేనేజ్డ్ సర్వీసులు అలాగే చేస్తాయి, కానీ కమిట్ పాత్ దీనికి మూల్యం చెల్లించుకుంటుంది. ప్రతి ఫ్లష్ నెట్‌వర్క్ ద్వారా వెళుతుంది, కాబట్టి లోకల్ ఫ్లాష్‌తో పోలిస్తే ఒకే కనెక్షన్ ద్వారా సెకనుకు తక్కువ చిన్న లావాదేవీలు (transactions) మాత్రమే పూర్తవుతాయి. దీనికి బదులుగా, హోస్ట్ విఫలమైనా డేటా సురక్షితంగా ఉండే మన్నికను మీరు పొందుతారు. మీరు రైట్-హెవీ డేటాబేస్ కోసం నెట్‌వర్క్ స్టోరేజ్‌ని ఎంచుకుంటే, పనులను పెద్ద లావాదేవీలుగా సమూహపరచండి, తద్వారా తక్కువ ఫ్లష్‌లతో ఎక్కువ వరుసలను ప్రాసెస్ చేయవచ్చు.