Berapa banyak CPU dan RAM yang dibutuhkan PostgreSQL di VPS dengan vCPU khusus?

Berapa vCPU yang dipakai PostgreSQL?

PostgreSQL memakai satu thread CPU per kueri yang berjalan, karena setiap koneksi mendapat proses backend sendiri. Dokumentasinya menyebutnya model "process per user": postmaster membuat backend baru untuk setiap koneksi. Jadi CPU yang dibutuhkan database ditentukan oleh jumlah kueri yang dieksekusi pada saat bersamaan, bukan oleh jumlah koneksi terbuka. Koneksi yang menganggur memakan memori dan tidak memakan CPU.

Tiga hal menambah thread di atas kueri Anda:

• Parallel query. Scan besar merekrut pembantu: max_parallel_workers_per_gather default 2 dan max_parallel_workers default 8, diambil dari max_worker_processes (default 8).
• Autovacuum. Hingga autovacuum_max_workers proses (default 3) membersihkan tabel di latar belakang.
• Aplikasi, jika berjalan di VPS yang sama.

Di VPS 2 vCPU, satu laporan yang berjalan paralel bisa menduduki semua thread sementara kueri pendek aplikasi menunggu di belakangnya. Menurunkan max_parallel_workers_per_gather untuk role pelaporan, atau naik ke paket yang lebih besar, menyelesaikannya. Aturan thread versus core di balik hitungan ini dijelaskan di apakah vCPU khusus itu sebuah core atau thread.

Berapa RAM yang dibutuhkan PostgreSQL di VPS?

Mulai shared_buffers di 25% RAM VPS dan sisakan sebagian besar sisanya untuk page cache sistem operasi. Dokumentasi PostgreSQL 18 menetapkan nilai awal itu untuk server database khusus dengan RAM 1 GB atau lebih, dan menambahkan bahwa lebih dari 40% kecil kemungkinan bekerja lebih baik, karena PostgreSQL juga mengandalkan cache kernel. Default yang dikirimkan adalah 128 MB.

Dua pengaturan lain mengikuti dari RAM:

• effective_cache_size hanya perkiraan untuk perencana kueri (default 4 GB). Setel ke jumlah yang ditampung shared_buffers dan page cache bersama-sama, agar index scan dihitung biayanya dengan benar.
• work_mem (default 4 MB) berlaku untuk setiap langkah sort atau hash di setiap sesi. Satu kueri kompleks memakainya beberapa kali, dan banyak sesi melakukannya sekaligus, jadi naikkan dengan hati-hati.

Menurut survei Cobaltfell pada 2 November 2026, 106 dari 202 paket dedicated-CPU yang tercatat di host yang menerima kripto tanpa pemeriksaan identitas memberi RAM 4 GB atau lebih per vCPU. Untuk database, RAM per vCPU sama pentingnya dengan jumlah vCPU.

Paket di balik hitungan itu tercantum di berapa biaya VPS dedicated CPU per core pada November 2026.

Bagaimana CPU steal memengaruhi latensi p99 PostgreSQL?

CPU steal memperpanjang 1% kueri paling lambat jauh sebelum memengaruhi rata-rata. Kernel Linux mendefinisikan steal sebagai penantian tak sukarela: waktu ketika sebuah vCPU punya pekerjaan sementara hypervisor menjalankan pihak lain. Sebuah backend yang terhenti di tengah kueri berhenti begitu saja, dan setiap klien yang menunggu kueri itu, atau menunggu lock yang dipegangnya, ikut berhenti.

Jeda itu singkat dan tidak teratur, jadi hanya mengenai kueri yang kebetulan berada di CPU saat itu. Sebagai ilustrasi, bukan pengukuran: ketika sebuah vCPU kehilangan beberapa puluh milidetik ke tetangga sesekali, kueri 2 ms yang jatuh di salah satu jendela itu memakan waktu sepuluh kali lebih lama, sementara ribuan kueri di sekitarnya berjalan dengan kecepatan normal. Rata-rata hampir tidak berubah; persentil ke-99 menanggung seluruh biayanya.

Database di vCPU shared karena itu tampak sehat dalam rata-rata dan tetap menghasilkan timeout. Tiga pembacaan mengungkapnya:

• Steal: kolom %steal dari mpstat selama jam tersibuk, dijelaskan di apa itu CPU steal time dan cara memeriksanya di VPS.
• Kasus terburuk: pg_stat_statements melaporkan max_exec_time dan stddev_exec_time per statement, dan tanpa persentil.
• Persentil: log_min_duration_statement (misalnya 250ms) mencatat statement lambat; histogram latensi di aplikasi memberi p99 itu sendiri.

# 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

Apa yang diubah vCPU khusus untuk database?

vCPU khusus menghilangkan satu sumber tail latency yang tidak bisa diatasi dari dalam VPS. Rencana kueri lambat, indeks yang hilang, dan lock contention adalah urusan operator; batch job tetangga di core shared bukan. Kasus umumnya diuraikan di apa perbedaan antara vCPU shared dan dedicated. Di VPS Cobaltfell:

• CPU: Satu vCPU adalah satu thread perangkat keras dari prosesor host. Thread milik Anda dipatok satu per satu ke VPS Anda dan tidak pernah dipinjamkan ke pelanggan lain, dan dua thread dari satu core fisik tetap bersama, jadi setiap 2 vCPU membentuk satu core utuh yang tidak dipakai bersama oleh tetangga.
• Steal: Pada vCPU khusus, steal time seharusnya berada pada atau mendekati nol. Kami akan menerbitkan angka yang kami ukur di mesin kami sendiri, beserta tanggalnya, dan tidak pernah berupa perkiraan.
• Memori: RAM pada paket Anda disisihkan untuk VPS Anda dan tidak di-overcommit.
• Disk: Penyimpanan NVMe di setiap paket.
• Beban: Beban penuh diperbolehkan selama pekerjaan Anda membutuhkannya: tanpa CPU credit, tanpa jendela burst, dan tanpa throttling setelah beberapa menit pada 100%. VACUUM yang panjang atau pembuatan indeks berjalan full.

Keluarga prosesornya adalah AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Kapan VPS menjadi tempat yang salah untuk PostgreSQL?

VPS adalah tempat yang salah ketika data yang dikueri setiap menit jauh lebih besar dari RAM paket terbesar, atau ketika replika dan backup harus dikelola untuk Anda. Fell 16 punya 32 GB. Working set yang tidak muat di memori mengubah setiap kueri menjadi pembacaan disk, dan throughput penyimpanan, bukan vCPU, yang kemudian menentukan laju.

Backup tetap di tangan operator: Backup bukan bagian dari paket mana pun: simpan salinan data Anda di tempat lain. pg_dump setiap malam atau arsip WAL yang dikirim ke penyimpanan di tempat lain mencakup sebagian besar database kecil; uji restore harus ada di kalender sebelum dibutuhkan.

Failover di dua atau tiga VPS dengan streaming replication bisa dilakukan, tetapi dikelola sendiri. Cobaltfell menjual servernya, bukan database terkelola. Harga untuk setiap ukuran tercantum di berapa biaya VPS dedicated-core.