Dedicated vCPU VPS पर PostgreSQL को कितना CPU और RAM चाहिए?

PostgreSQL कितने vCPU इस्तेमाल करता है?

PostgreSQL चल रही हर क्वेरी के लिए एक CPU थ्रेड इस्तेमाल करता है, क्योंकि हर कनेक्शन को अपना अलग backend process मिलता है। डॉक्युमेंटेशन इसे "process per user" मॉडल कहता है: postmaster हर कनेक्शन के लिए एक नया backend बनाता है। इसलिए डेटाबेस को जितना CPU चाहिए वह उस समय एक साथ चल रही क्वेरीज़ की संख्या तय करती है, खुले कनेक्शनों की नहीं। एक idle कनेक्शन मेमोरी लेता है और CPU नहीं।

आपकी क्वेरीज़ के ऊपर तीन चीज़ें थ्रेड जोड़ती हैं:

• Parallel query। एक बड़ा scan मददगार जुटाता है: max_parallel_workers_per_gather डिफ़ॉल्ट 2 और max_parallel_workers डिफ़ॉल्ट 8, जो max_worker_processes (डिफ़ॉल्ट 8) से लिए जाते हैं।
• Autovacuum। autovacuum_max_workers प्रक्रियाएँ (डिफ़ॉल्ट 3) तक बैकग्राउंड में टेबल साफ़ करती हैं।
• ऐप, जब वह उसी VPS पर चलता हो।

2-vCPU VPS पर, एक रिपोर्ट जो parallel हो जाती है, हर थ्रेड घेर सकती है जबकि ऐप की छोटी क्वेरीज़ उसके पीछे इंतज़ार करती हैं। reporting role के लिए max_parallel_workers_per_gather घटाने से, या बड़े प्लान पर जाने से, यह ठीक हो जाता है। इन गिनतियों के पीछे का थ्रेड-बनाम-कोर नियम क्या dedicated vCPU एक कोर है या एक थ्रेड में समझाया गया है।

VPS पर PostgreSQL को कितनी RAM चाहिए?

shared_buffers को VPS की RAM का 25% से शुरू करें और बाकी का ज़्यादातर हिस्सा ऑपरेटिंग सिस्टम के page cache के लिए छोड़ दें। PostgreSQL 18 डॉक्युमेंटेशन यह शुरुआती मान 1 GB या ज़्यादा RAM वाले dedicated डेटाबेस सर्वर के लिए देता है, और जोड़ता है कि 40% से ज़्यादा बेहतर काम करेगा ऐसा होने की संभावना कम है, क्योंकि PostgreSQL kernel के cache पर भी निर्भर करता है। जो डिफ़ॉल्ट भेजा जाता है वह 128 MB है।

RAM से दो और सेटिंग्स निकलती हैं:

• effective_cache_size सिर्फ़ planner के लिए एक अनुमान है (डिफ़ॉल्ट 4 GB)। इसे उस मात्रा पर सेट करें जो shared_buffers और page cache मिलकर रखते हैं, ताकि index scans की लागत सही लगे।
• work_mem (डिफ़ॉल्ट 4 MB) हर session में हर sort या hash चरण पर लागू होती है। एक जटिल क्वेरी इसे कई बार इस्तेमाल करती है, और कई sessions एक साथ ऐसा करते हैं, इसलिए इसे सोच-समझकर बढ़ाएँ।

Cobaltfell के 2 नवंबर 2026 के सर्वे के अनुसार, बिना ID जाँच के crypto लेने वाले hosts पर दर्ज 202 dedicated-CPU प्लानों में से 106 ने प्रति vCPU 4 GB RAM या ज़्यादा दी। डेटाबेस के लिए, प्रति vCPU RAM उतनी ही मायने रखती है जितना vCPU की संख्या।

उस गिनती के पीछे के प्लान नवंबर 2026 में प्रति कोर dedicated CPU VPS की कितनी लागत आती है में सूचीबद्ध हैं।

CPU steal PostgreSQL p99 latency को कैसे प्रभावित करता है?

CPU steal सबसे धीमी 1% क्वेरीज़ को औसत हिलने से बहुत पहले खींच लेता है। Linux kernel steal को अनैच्छिक प्रतीक्षा बताता है: वह समय जब किसी vCPU के पास काम था जबकि hypervisor किसी और को चला रहा था। क्वेरी के बीच में रुका backend बस रुक जाता है, और उस क्वेरी पर इंतज़ार करता हर client, या उसके पकड़े lock पर इंतज़ार करता कोई भी, उसके साथ रुक जाता है।

रुकावटें छोटी और अनियमित होती हैं, इसलिए वे सिर्फ़ उन्हीं क्वेरीज़ पर लगती हैं जो उस पल CPU पर होती हैं। एक उदाहरण के तौर पर, किसी माप के रूप में नहीं: जब कोई vCPU कभी-कभार किसी पड़ोसी को कुछ दर्जन मिलीसेकंड खो देता है, तो उन खिड़कियों में पड़ने वाली 2 ms की क्वेरी दस गुना ज़्यादा समय लेती है, जबकि उसके आसपास की हज़ारों क्वेरीज़ सामान्य गति से चलती हैं। औसत मुश्किल से बदलता है; 99वाँ percentile पूरी लागत उठाता है।

इसलिए shared vCPU पर डेटाबेस औसत में स्वस्थ दिखता है और फिर भी timeouts देता है। तीन रीडिंग इसे उजागर करती हैं:

• Steal: सबसे व्यस्त घंटे में mpstat का %steal कॉलम, जो CPU steal time क्या है और VPS पर इसे कैसे जाँचें में समझाया गया है।
• सबसे बुरे मामले: pg_stat_statements प्रति statement max_exec_time और stddev_exec_time बताता है, और कोई percentile नहीं।
• Percentiles: log_min_duration_statement (उदाहरण के लिए 250ms) धीमे statements लॉग करता है; ऐप में एक latency histogram खुद p99 देता है।

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

डेटाबेस के लिए dedicated vCPU क्या बदलता है?

dedicated vCPU tail latency का वह एक स्रोत हटा देता है जिसे VPS के अंदर से ठीक नहीं किया जा सकता। धीमे plans, गायब indexes और lock contention ठीक करना operator का काम है; shared कोर पर किसी पड़ोसी का batch job नहीं। सामान्य मामला shared और dedicated vCPU में क्या अंतर है में बताया गया है। Cobaltfell VPS पर:

• CPU: एक vCPU होस्ट प्रोसेसर का एक हार्डवेयर थ्रेड है। आपके थ्रेड आपके VPS से एक-से-एक पिन किए जाते हैं और कभी किसी दूसरे ग्राहक को नहीं दिए जाते, और एक फ़िज़िकल कोर के दोनों थ्रेड साथ ही रहते हैं, इसलिए हर 2 vCPU एक पूरा कोर बनाते हैं जिसे कोई पड़ोसी साझा नहीं करता।
• Steal: एक dedicated vCPU पर steal time शून्य पर या उसके करीब होना चाहिए। हम अपनी ही मशीनों पर जो आँकड़ा मापते हैं, उसे उसकी तारीख के साथ प्रकाशित करेंगे, कभी कोई अनुमान नहीं।
• मेमोरी: आपके प्लान की RAM आपके VPS के लिए अलग रखी जाती है और overcommit नहीं की जाती।
• डिस्क: हर प्लान पर NVMe storage।
• लोड: जब तक आपके काम को ज़रूरत हो, पूरा load चलाने की अनुमति है: कोई CPU credit नहीं, कोई burst window नहीं और 100% पर कुछ मिनट बाद कोई throttling नहीं। एक लंबा VACUUM या index build पूरी रफ़्तार से चलता है।

प्रोसेसर फ़ैमिली AMD EPYC 9004/9005 (Zen 4 / Zen 5) है।

PostgreSQL के लिए VPS कब गलत जगह है?

VPS तब गलत जगह है जब हर मिनट क्वेरी किया जाने वाला डेटा सबसे बड़े प्लान की RAM से कहीं ज़्यादा हो, या जब replicas और backups आपके लिए प्रबंधित किए जाने चाहिए। Fell 16 में 32 GB है। ऐसा working set जो मेमोरी में नहीं समाता, हर क्वेरी को डिस्क पढ़ने में बदल देता है, और तब गति storage throughput तय करती है, vCPU नहीं।

बैकअप operator के पास ही रहते हैं: Backup किसी भी प्लान का हिस्सा नहीं हैं: अपने data की एक कॉपी कहीं और रखें। रात का pg_dump या किसी और जगह के storage पर भेजा गया WAL archive ज़्यादातर छोटे डेटाबेस के लिए काफ़ी है; restore टेस्ट ज़रूरत पड़ने से पहले कैलेंडर पर होना चाहिए।

दो या तीन VPS पर streaming replication के साथ failover काम करता है, लेकिन वह self-managed है। Cobaltfell सर्वर बेचता है, managed डेटाबेस नहीं। हर साइज़ की कीमतें dedicated-core VPS की कितनी लागत आती है के अंतर्गत सूचीबद्ध हैं।