VPS Ubuntu / Linux VPS

Linux VPS ਦੀ ਅਸਲ ਕੰਮ ਅਤੇ ਪੂਰੇ ਖ਼ਰਚੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

Linux VPS ਦੀ ਚੋਣ ਲਈ ਪਹਿਲਾਂ Ubuntu image, ਆਰਕੀਟੈਕਚਰ, region, recovery ਅਤੇ ਪੂਰਾ ਬਿੱਲ ਜਾਂਚੋ। ਫਿਰ ਇੱਕੋ ਐਪ ਨਾਲ ਉਮੀਦਵਾਰ ਯੋਜਨਾਵਾਂ ਮਾਪੋ। ਇਹ ਤੁਲਨਾ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ, ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ranking ਜਾਂ ਬਣੇ-ਬਣਾਏ benchmark ਨਤੀਜੇ ਨਹੀਂ।

· ਅੱਪਡੇਟ: · ਲਗਭਗ 5 ਮਿੰਟ ਪੜ੍ਹਨ ਲਈ

ਗਾਈਡ ਦੀ ਸਮੱਗਰੀ

ਪਹਿਲਾਂ ਇੱਕ ਕੰਮ ਦੀ ਲੋੜ ਲਿਖੋ

Web server, runtime, database, cache ਅਤੇ workers ਇੱਕੋ ਸਰੋਤ ਵਰਤਦੇ ਹਨ। Imports, image processing ਅਤੇ Backup ਵੀ ਗਿਣੋ। ਸਿੱਖਣ, staging ਜਾਂ ਗਾਹਕਾਂ ਲਈ ਵਰਤੋਂ ਅਤੇ ਮਨਜ਼ੂਰ downtime ਲਿਖੋ। Region ਅਤੇ ਐਪ ਦੀ Ubuntu support ਪਹਿਲਾਂ ਮਿਲਾਓ।

Nginx, ਇੱਕ ਐਪ, PostgreSQL ਅਤੇ scheduled import ਵਾਲੇ ਛੋਟੇ catalogue ਲਈ 2 vCPU ਅਤੇ 4 GB RAM ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਯੋਗ ਹੈ, ਮਾਪੀ ਸਮਰੱਥਾ ਨਹੀਂ। Staging ਵਿੱਚ ਅਸਲ ਵਰਗਾ ਡਾਟਾ ਰੱਖੋ। ਸਰੋਤਾਂ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਵੇਖੋ।

ਤੁਲਨਾ ਲਈ ਇੱਕੋ ਹਾਲਾਤ ਰੱਖੋ

ਹਰ ਯੋਜਨਾ ਉੱਤੇ ਇੱਕੋ app build, database copy, cache ਅਤੇ worker count ਰੱਖੋ। Ubuntu release, architecture ਅਤੇ ਮਿਲਦੇ region ਦਰਜ ਕਰੋ। ਨਿੱਜੀ ਗਾਹਕ ਡਾਟਾ ਬੇਲੋੜੀ test environment ਵਿੱਚ ਨਾ ਲਿਜਾਓ।

ਛੋਟੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਸਾਰੇ ਕਾਲਮ ਵੇਖਣ ਲਈ ਸਾਰਣੀ ਪਾਸੇ ਵੱਲ ਖਿਸਕਾਓ।

ਦਰਜ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ਕਿਉਂ ਲੋੜੀਂਦੀ ਹੈ
CPU ਅਤੇ fair-useShared, dedicated ਅਤੇ burstable ਦੀਆਂ ਵੱਖ ਹੱਦਾਂ
RAM ਅਤੇ swapਸਾਰੀਆਂ services ਲਈ ਸਾਂਝੀ memory
ਡਿਸਕ ਅਤੇ I/O limitsਖਾਲੀ ਥਾਂ ਅਤੇ ਜਵਾਬ ਦੀ ਰਫ਼ਤਾਰ ਵੱਖ ਹਨ
Region ਅਤੇ dependenciesਦੂਰਲਾ database request ਨੂੰ ਹੌਲਾ ਕਰ ਸਕਦਾ ਹੈ
Resize ਅਤੇ restoreਤਬਦੀਲੀ ਜਾਂ recovery ਵਿੱਚ downtime
Billing unit ਅਤੇ ਵਾਧੂ ਸੇਵਾਵਾਂਇੱਕੋ VM ਕੀਮਤ ਨਾਲ ਬਿੱਲ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ

vCPU ਗਿਣਤੀ ਲਗਾਤਾਰ performance ਅਤੇ NVMe ਨਾਮ I/O allowance ਨਹੀਂ ਦੱਸਦਾ। ਲਗਾਤਾਰ workload ਦੀ ਇਜਾਜ਼ਤ ਅਤੇ ਵੱਡੀ ਕੀਤੀ disk ਮੁੜ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਪੁੱਛੋ।

ਸਰਵਰ ਦੀ ਮੁੱਢਲੀ ਹਾਲਤ ਮਾਪੋ

Ubuntu ਉੱਤੇ iostat ਲਈ sysstat ਲਗਾਓ। Workload ਚੱਲਦਿਆਂ sampling commands ਵੱਖਰੇ terminals ਵਿੱਚ ਚਲਾਓ; idle sample ਸਿਰਫ਼ baseline ਹੈ।

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

vmstat ਦੀ ਪਹਿਲੀ CPU/activity report boot ਤੋਂ ਹੁਣ ਤੱਕ ਦੀ ਹੈ; ਅਗਲੇ ਇੱਕ-second samples ਵਰਤੋ। free ਵਿੱਚ available ਵੇਖੋ: cache ਮੁੜ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। iostat ਦਾ -y ਪਹਿਲੀ boot ਤੋਂ ਬਣੀ report ਛੱਡਦਾ ਹੈ।

24 ਸਤੰਬਰ 2026 ਨੂੰ ਇਸ static ਸਾਈਟ ਦੇ origin snapshot ਵਿੱਚ 1 logical CPU, 957 MiB memory, 59 MiB free ਅਤੇ 358 MiB available ਦਰਜ ਹਨ। ਇਸ ਵਿੱਚ control panel ਅਤੇ ਹੋਰ services ਵੀ ਸਨ। ਇਹ free ਅਤੇ available ਦਾ ਫ਼ਰਕ ਦਿਖਾਉਂਦਾ ਹੈ, load test ਨਹੀਂ।

Outputs ਨਾਲ ਸਮਾਂ ਅਤੇ scenario ਸੰਭਾਲੋ। Imports ਅਤੇ Backup ਦੌਰਾਨ disk growth ਵੇਖੋ। df -h / ਸਿਰਫ਼ root filesystem ਦੱਸਦਾ ਹੈ; database ਦੇ ਹੋਰ volume ਨੂੰ ਵੱਖ ਜਾਂਚੋ।

ਉਹ ਕੰਮ ਜਾਂਚੋ ਜੋ users ਕਰਦੇ ਹਨ

ਆਪਣੇ staging ਉੱਤੇ browsing, search, login ਅਤੇ write operation ਜਾਂਚੋ। Cached ਤੇ uncached requests ਅਤੇ jobs ਸ਼ਾਮਲ ਕਰੋ। ਮਨਜ਼ੂਰ response time ਅਤੇ error rate ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ।

ਆਪਣੇ users ਦੇ ਨੇੜਲੇ client ਤੋਂ ਹੇਠਲੀ request ਚਲਾਓ; hostname ਅਤੇ path ਆਪਣੇ staging endpoint ਨਾਲ ਬਦਲੋ। ਸਮਾਂ seconds ਵਿੱਚ ਹੈ।

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 request concurrency ਨਹੀਂ ਮਾਪਦੀ। ਵੱਖਰੇ load client ਨਾਲ ਅਸਲ workflow ਦੁਹਰਾਓ; request rate, concurrency, duration, dataset ਅਤੇ cache state ਦਰਜ ਕਰੋ। Errors ਅਤੇ 95th-percentile response time ਦੀ ਤੁਲਨਾ ਕਰੋ: 95% ਮਾਪੀਆਂ requests ਇਸ ਸਮੇਂ ਤੋਂ ਹੇਠਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਨਾਲ ਸਰਵਰ ਵੀ ਮਾਪੋ।

ਸਰੋਤ ਖ਼ਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਾਵਟ ਸਮਝੋ

ਛੋਟੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਸਾਰੇ ਕਾਲਮ ਵੇਖਣ ਲਈ ਸਾਰਣੀ ਪਾਸੇ ਵੱਲ ਖਿਸਕਾਓ।

ਨਿਰੀਖਣਕੀ ਜਾਂਚਣਾ ਹੈ
ਘੱਟ available RAM ਅਤੇ ਲਗਾਤਾਰ swap I/OWorkers, database memory ਅਤੇ RAM
ਵੱਧ CPU ਅਤੇ runnable queueਮਹਿੰਗੇ code paths, concurrency ਅਤੇ CPU allocation
ਵੱਧ steal timeHost scheduling ਜਾਂ plan limits; ਮੁੜ samples ਲਵੋ
ਵੱਧ disk await ਅਤੇ ਹੌਲੀਆਂ requestsQueries, disk queue ਅਤੇ I/O allowance
Local ਤੇਜ਼ ਪਰ ਬਾਹਰੀ response ਹੌਲਾRegion, DNS/TLS ਅਤੇ network path

ਇਹ ਸੰਕੇਤ ਹਨ, ਆਪਣੇ ਆਪ upgrade ਦਾ ਹੁਕਮ ਨਹੀਂ। Swap ਵਿੱਚ ਪੁਰਾਣੇ inactive pages ਹੋ ਸਕਦੇ ਹਨ। Disk await ਵਿੱਚ queueing ਵੀ ਆਉਂਦੀ ਹੈ; database lock CPU/RAM ਭਰੇ ਬਿਨਾਂ request ਰੋਕ ਸਕਦਾ ਹੈ। Logs ਨਾਲ ਮਿਲਾਓ ਅਤੇ ਇੱਕ ਵੱਡੀ ਤਬਦੀਲੀ ਕਰਕੇ ਮੁੜ ਮਾਪੋ।

ਪੂਰਾ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਗਿਣੋ

ਹੇਠਾਂ USD ਅੰਕ ਸਿਰਫ਼ ਗਣਿਤ ਦੀਆਂ ਬਣਾਈਆਂ ਉਦਾਹਰਨਾਂ ਹਨ; ਅਸਲ offers ਨਹੀਂ। ਦੋਵੇਂ ਵਿੱਚ ਇੱਕ VM, ਲੋੜੀਂਦਾ IPv4, ਇੱਕੋ Backup ਲੋੜ ਅਤੇ traffic ਮੰਨਿਆ ਹੈ। Tax ਅਤੇ management ਸ਼ਾਮਲ ਨਹੀਂ।

ਛੋਟੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਸਾਰੇ ਕਾਲਮ ਵੇਖਣ ਲਈ ਸਾਰਣੀ ਪਾਸੇ ਵੱਲ ਖਿਸਕਾਓ।

ਮਹੀਨਾਵਾਰ ਹਿੱਸਾਉਦਾਹਰਨ Aਉਦਾਹਰਨ B
VM ਅਤੇ ਲੋੜੀਂਦੀ disk$6$8
ਲੋੜੀਂਦਾ IPv4$2$0 ਸ਼ਾਮਲ
Backup storage$3$2
ਮੰਨਿਆ transfer$0 ਸ਼ਾਮਲ$3
Tax ਤੋਂ ਪਹਿਲਾਂ ਉਦਾਹਰਨ ਦਾ ਜੋੜ$11$13

$6 ਵਾਲੀ VM ਇੱਥੇ $11 ਬਣਦੀ ਹੈ। ਆਪਣੇ ਅਸਲ billing units, overage rates, currency ਅਤੇ tax ਨਾਲ ਹਿਸਾਬ ਕਰੋ। Promotion ਦੇ renewal ਉੱਤੇ ਕੀਮਤ ਮੁੜ ਗਿਣੋ। Stopped VM ਨਾਲ disk ਅਤੇ address ਦੇ ਖ਼ਰਚੇ ਰਹਿ ਸਕਦੇ ਹਨ; stop, delete ਅਤੇ release ਵੱਖ ਕਦਮ ਹਨ।

ਨੈੱਟਵਰਕ ਅਤੇ recovery ਦੀ ਸ਼ਰਤ ਜਾਂਚੋ

Inbound/outbound rules, SMTP restrictions ਅਤੇ relay allowance ਜਾਂਚੋ। UFW ਵਿੱਚ port ਖੋਲ੍ਹਣ ਨਾਲ ਪ੍ਰਦਾਤਾ ਦਾ block ਨਹੀਂ ਹਟਦਾ। ਐਪ ਅਤੇ database ਦਰਮਿਆਨ ਦੂਰੀ ਵੀ response time ਨੂੰ ਬਦਲਦੀ ਹੈ।

Recovery console ਲੱਭੋ ਅਤੇ Backup ਬਾਹਰ ਕੱਢ ਕੇ ਵੱਖਰੀ ਥਾਂ restore ਕਰੋ। Snapshot ਦੀ retention ਅਤੇ host failure ਤੋਂ ਬਾਅਦ availability ਪੁੱਛੋ। Unmanaged hosting ਵਿੱਚ updates ਅਤੇ incidents ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਤੈਅ ਕਰੋ।

Static site ਲਈ ਫ਼ਾਈਲ recovery ਦੀ ਕਸਰਤ ਕਰੋ; database ਲਈ consistent Backup ਵੱਖ ਲੋੜੀਂਦੀ ਹੈ। ਉਹ ਸਭ ਤੋਂ ਘੱਟ ਖ਼ਰਚ ਵਾਲਾ ਉਮੀਦਵਾਰ ਚੁਣੋ ਜੋ workload, growth ਅਤੇ recovery ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰੇ। ਫਿਰ ਪਹਿਲਾ deployment ਕਰੋ।

ਸਵਾਲ ਜਵਾਬ

2 vCPU ਨਾਲ ਕਿੰਨੇ visitors ਸੰਭਲਦੇ ਹਨ?

ਐਪ ਅਤੇ workload ਤੋਂ ਬਿਨਾਂ ਭਰੋਸੇਯੋਗ ਗਿਣਤੀ ਨਹੀਂ ਨਿਕਲਦੀ। Cached static responses ਅਤੇ database writes ਦੀ ਲੋੜ ਵੱਖ ਹੈ। ਅਸਲ stack ਅਤੇ concurrency ਮਾਪੋ।

Managed hosting ਕਦੋਂ ਚੁਣੀਏ?

ਸ਼ਾਮਲ ਕੰਮਾਂ ਨੂੰ ਆਪਣੀ ਟੀਮ ਦੀ ਸਮਰੱਥਾ ਨਾਲ ਮਿਲਾਓ। Security updates, ਐਪ ਦੀ ਜਾਂਚ, Backup ਅਤੇ restore ਮਦਦ ਦਾ scope ਅਤੇ ਪੂਰਾ ਖ਼ਰਚਾ ਪੁੱਛੋ।

ਦਸਤਾਵੇਜ਼ ਅਤੇ ਹਵਾਲੇ

Configurations ਅਤੇ ਖ਼ਰਚੇ ਤਰੀਕਾ ਸਮਝਾਉਣ ਲਈ ਹਨ, provider quotations ਨਹੀਂ। Origin ਦਾ memory snapshot ਇੱਕ ਨਿਰੀਖਣ ਹੈ; visitor capacity ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਗਾਈਡਾਂ