Linux VPS․ ընտրություն ըստ իրական բեռնվածության

Նախ նկարագրեք մեկ իրական բեռնվածություն

Գրեք այն պահանջները, որոնցից կախված է պլանի պիտանիությունը՝ աջակցվող Ubuntu իմիջ և ճարտարապետություն, հարմար տարածաշրջան, անհրաժեշտ ծառայություններ, վերականգնման ուղի և պարբերական բյուջե։ Թվարկեք նույն VM-ի վեբսերվերը, runtime-ը, տվյալների բազան, cache-ը և ֆոնային workers-ը։ Ներառեք ներմուծումները, պատկերների մշակումը և backup-ը․ սովորական դիտումը կարող է լավ աշխատել, իսկ միաժամանակյա աշխատանքները՝ խնդիր առաջացնել։ Նշեք՝ միջավայրը ուսուցման, staging-ի՞, թե՞ հաճախորդների համար է, և որքան ընդհատում է ընդունելի։

Օրինակ՝ փոքր դինամիկ կատալոգ Nginx-ով, մեկ հավելվածի ծառայությամբ, PostgreSQL-ով և պլանավորված ներմուծմամբ։ 2 vCPU և 4 GB RAM-ը մեկնարկային փորձ է, ոչ թե հաստատված թողունակություն։ Staging-ում օգտագործեք ներկայացուցչական գրառումներ ու վերբեռնված ֆայլեր։ Այլ աշխատանքների համար տեսեք ռեսուրսների օրինակները։

Համեմատեք համարժեք կոնֆիգուրացիաներ

Յուրաքանչյուր թեկնածուի վրա պահեք հավելվածի նույն build-ը, բազայի պատճենը, cache-ի կարգավորումներն ու workers-ի թիվը։ Ընտրեք համեմատելի տարածաշրջաններ և գրանցեք Ubuntu-ի թողարկումն ու ճարտարապետությունը։ Հակառակ դեպքում մոտ տվյալների կենտրոնը կամ ծրագրային փոփոխությունը կարող է սարքավորման առավելություն թվալ։ Անհարկի փորձնական միջավայր մի տեղափոխեք հաճախորդների գաղտնի տվյալները։

Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։

Ճշտեք՝ թույլատրվա՞ծ է ձեր երկարատև բեռնվածությունը։ vCPU-ի թիվը կայուն արտադրողականություն չի ապացուցում, իսկ NVMe պիտակը I/O քվոտա չի սահմանում։ Ժամանակավորապես մեծացնելուց առաջ ճշտեք՝ սկավառակը հետագայում հնարավո՞ր է փոքրացնել։

Սերվերի վրա գրանցեք սկզբնական վիճակը

Գրանցեք հասանելի հիշողությունն ու սկավառակի ազատ տարածքը։ Ubuntu-ում iostat-ի համար տեղադրեք sysstat։ Հավելվածի բեռնվածության ընթացքում նմուշառման հրամանները գործարկեք առանձին տերմինալներում․ պարապ վիճակի կարճ չափումը միայն ելակետ է։

free -h
df -h /
sudo apt update
sudo apt install sysstat
vmstat 1 11
iostat -xz -y 1 10

vmstat-ի առաջին CPU/activity հաշվետվությունն ամփոփում է boot-ից անցած ժամանակը․ այս չափման համար օգտագործեք հաջորդ մեկվայրկյանանոց տողերը։ free-ում դիտեք available-ը․ Linux-ը կարող է cache-ի մի մասը ազատել, ուստի փոքր free թիվն ինքնին հիշողության պակաս չէ։ iostat-ի -y-ն բաց է թողնում boot-ից կուտակված առաջին հաշվետվությունը։

Այս ստատիկ կայքի սկզբնաղբյուր սերվերը 2026 թ. սեպտեմբերի 24-ին ուներ մեկ տեսանելի տրամաբանական CPU և 957 MiB հիշողություն։ Նույն դիտարկումը ցույց էր տալիս 59 MiB free և 358 MiB available՝ ներառյալ կառավարման վահանակն ու այլ ծառայությունները։ Սա free/available տարբերության օրինակ է, ոչ բեռնվածության թեստ կամ առաջարկվող հզորություն։

Պահեք արդյունքները՝ ժամով և սցենարով։ Ներմուծման ու backup-ի ընթացքում հետևեք սկավառակի աճին։ Եթե բազան այլ volume-ում է, ստուգեք նաև այդ ֆայլային համակարգը․ df -h /-ը նկարագրում է միայն root filesystem-ը։

Փորձարկեք այցելուների իրական գործողությունները

Ձեր վերահսկողության տակ գտնվող staging-ում փորձարկեք դիտումը, որոնումը, մուտքը և բնորոշ գրանցման գործողություն։ Ներառեք ֆոնային աշխատանքներն ու cached/uncached հարցումները։ Նախապես սահմանեք ընդունելի արձագանքման ժամանակն ու սխալների բաժինը։

Օգտատերերին մոտ արտաքին կետից ստուգեք HTTP status-ը, առաջին բայթի և ամբողջ հարցման ժամանակը։ Hostname-ն ու ուղին փոխարինեք staging endpoint-ով․ ժամանակը վայրկյաններով է։

curl -sS -o /dev/null --max-time 30 -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.com/catalogue

Մեկ curl հարցումը միաժամանակյա բեռնվածություն չի չափում։ Load test-ի համար օգտագործեք առանձին կլիենտ և իրական գործողությունները կրկնող սցենար։ Գրանցեք հարցումների արագությունը, միաժամանակյա կապերը, տևողությունը, տվյալների հավաքածուն և cache-ի վիճակը։ Համեմատեք սխալներն ու 95-րդ պերսենտիլը՝ այն սահմանը, որից ցածր է չափված հարցումների 95%-ի ժամանակը։ Միաժամանակ հետևեք VM-ին և նույն փորձը կրկնեք բոլոր թեկնածուների վրա։

Նախ գտեք սահմանափակող գործոնը

Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։

Սրանք հետաքննության նշաններ են, ոչ ավտոմատ upgrade-ի կանոններ։ Swap-ում կարող են մնալ հին ոչ ակտիվ էջեր․ կարևոր է ընթացիկ ակտիվությունը։ Disk await-ը ներառում է հերթն ու սպասարկումը։ Բազայի lock-ը կարող է հարցումը ուշացնել՝ առանց CPU-ն կամ RAM-ը սպառելու։ Դիտարկումները համադրեք հավելվածի logs-ի հետ։

Եթե կատալոգի ներմուծումը դանդաղեցնում է դիտումը, իսկ CPU-ն ծանրաբեռնված չէ, ստուգեք հարցումներն ու պահեստը։ Եթե workers-ը սպառում են հիշողությունը, նույն բեռնվածությամբ փորձարկեք դրանց փոքր թիվը կամ ավելի շատ RAM-ը։ Միաժամանակ փոխեք մեկ հիմնական գործոն։

Հաշվեք ամբողջ ամսական ծախսը

Ստորև USD թվերը հորինված հաշվարկային օրինակներ են, ոչ առաջարկներ, հետազոտված գներ կամ benchmark։ Երկու դեպքում էլ ենթադրվում է մեկ VM, անհրաժեշտ մեկ IPv4, նույն backup պահանջն ու ամսական տրաֆիկը։ Հարկերն ու կառավարումը ներառված չեն։

Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։

A-ի 6 USD VM-ը այս ենթադրություններով դառնում է 11 USD։ Հաշվեք իրական billing units-ով, քվոտաներով և գերազանցման դրույքներով։ Ավելի ցածր գինը օգտակար է, եթե պլանը բավարարում է բեռնվածության և վերականգնման պահանջները։ Գրանցեք արժույթը, հարկերը և առաջարկի ամսաթիվը․ սա դրամով գնառաջարկ չէ։

Ճշտեք՝ ինչն է վճարովի մնում shutdown-ից հետո։ Կանգնեցված VM-ը կարող է վճարովի սկավառակ կամ հասցե պահել․ stop, delete և release-ը տարբեր գործողություններ են։ Երկու տարբերակում էլ ներառեք վճարովի restore-ը, կառավարումն ու լրացուցիչ volumes-ը։ Ակցիոն գինը վերահաշվեք երկարաձգման պահին։

Ստուգեք ցանցային սահմաններն ու վերականգնումը

Ճշտեք inbound/outbound կանոնները։ Էլփոստի համար ստուգեք նաև ելքային SMTP սահմանափակումները․ UFW-ի պորտը բացելը մատակարարի արգելքը չի վերացնում։ Mail relay-ի դեպքում ճշտեք կապի մեթոդն ու քվոտան։ Հավելվածն ու բազան տեղադրեք բավական մոտ, որպեսզի միջտարածաշրջանային ուշացումը չխեղաթյուրի VM-ի փորձարկումը։

Գտեք recovery console-ը, արտահանեք backup և վերականգնեք այլ միջավայրում։ Ճշտեք՝ snapshots-ը պահպանվո՞ւմ են host failure-ի դեպքում և ինչ retention ունեն։ Unmanaged հոսթինգում նշանակեք updates-ի ու միջադեպերի պատասխանատու․ ենթակառուցվածքի աջակցությունը պարտադիր չէ, որ ձեր հավելվածը ախտորոշի։

Փոքր ստատիկ կայքի համար սկսեք ֆայլերի վերականգնման փորձից։ Բազային անհրաժեշտ է առանձին consistent backup/restore մեթոդ։ Ընտրեք ամենամատչելի թեկնածուն, որը բավարարում է բեռնվածության, աճի և վերականգնման գրանցված պահանջները՝ սպասարկման պաշարով։ Պահեք չափումների թերթիկը և անցեք առաջին տեղակայմանը։

Հաճախ տրվող հարցեր

Պաշտոնական աղբյուրներ

1. Փաստաթուղթ 1․ manpages.ubuntu.com
2. Փաստաթուղթ 2․ manpages.ubuntu.com
3. Փաստաթուղթ 3․ manpages.ubuntu.com
4. Փաստաթուղթ 4․ curl.se
5. Փաստաթուղթ 5․ docs.aws.amazon.com