PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS ที่มี dedicated vCPU?

PostgreSQL ใช้กี่ vCPU?

PostgreSQL ใช้หนึ่ง thread ของ CPU ต่อหนึ่งคำสั่งที่กำลังรัน เพราะแต่ละการเชื่อมต่อมี backend process ของตัวเอง เอกสารเรียกโมเดลนี้ว่า "process per user": postmaster จะสร้าง backend ใหม่สำหรับแต่ละการเชื่อมต่อ ดังนั้นจำนวน CPU ที่ฐานข้อมูลต้องการจึงถูกกำหนดโดยจำนวนคำสั่งที่รันพร้อมกันในขณะเดียวกัน ไม่ใช่จำนวนการเชื่อมต่อที่เปิดอยู่ การเชื่อมต่อที่ไม่ได้ใช้งานกินหน่วยความจำแต่ไม่กิน CPU

มีสามอย่างที่เพิ่ม thread ขึ้นเหนือคำสั่งของคุณ:

• Parallel query การสแกนขนาดใหญ่จะดึงตัวช่วยมา: max_parallel_workers_per_gather มีค่าเริ่มต้นเป็น 2 และ max_parallel_workers เป็น 8 โดยดึงมาจาก max_worker_processes (ค่าเริ่มต้น 8)
• Autovacuum กระบวนการสูงสุด autovacuum_max_workers ตัว (ค่าเริ่มต้น 3) ทำความสะอาดตารางอยู่เบื้องหลัง
• แอปพลิเคชัน เมื่อรันอยู่บน VPS เดียวกัน

บน VPS 2 vCPU รายงานหนึ่งชิ้นที่เข้าสู่โหมด parallel อาจกินทุก thread ขณะที่คำสั่งสั้น ๆ ของแอปต้องรออยู่ข้างหลัง การลด max_parallel_workers_per_gather สำหรับ role ที่ใช้รายงาน หรืออัปเกรดแพ็กเกจจะแก้ปัญหานี้ได้ กฎเรื่อง thread กับ core ที่อยู่เบื้องหลังการนับเหล่านี้ อธิบายไว้ใน is a dedicated vCPU a core or a thread

PostgreSQL ต้องใช้ RAM เท่าไรบน VPS?

เริ่ม shared_buffers ที่ 25% ของ RAM ของ VPS และปล่อยส่วนที่เหลือให้ page cache ของระบบปฏิบัติการเป็นหลัก เอกสาร PostgreSQL 18 ระบุค่าเริ่มต้นนี้สำหรับเซิร์ฟเวอร์ฐานข้อมูลเฉพาะที่มี RAM 1 GB ขึ้นไป และเสริมว่าเกิน 40% ไม่น่าจะทำงานได้ดีขึ้น เพราะ PostgreSQL พึ่งพาแคชของ kernel ด้วย ค่าเริ่มต้นที่มากับระบบคือ 128 MB

มีอีกสองค่าที่กำหนดตาม RAM:

• effective_cache_size เป็นการประมาณสำหรับ planner เท่านั้น (ค่าเริ่มต้น 4 GB) ตั้งให้เท่ากับสิ่งที่ shared_buffers และ page cache เก็บไว้รวมกัน เพื่อให้คิดต้นทุน index scan ได้ถูกต้อง
• work_mem (ค่าเริ่มต้น 4 MB) ใช้กับแต่ละขั้น sort หรือ hash ในแต่ละ session คำสั่งที่ซับซ้อนหนึ่งคำสั่งใช้ค่านี้หลายรอบ และหลาย session ก็ใช้พร้อมกัน จึงควรเพิ่มอย่างระมัดระวัง

ตามการสำรวจของ Cobaltfell เมื่อวันที่ 2 พฤศจิกายน 2026 แพ็กเกจ dedicated-CPU จำนวน 106 จาก 202 แพ็กเกจที่บันทึกไว้ที่โฮสต์ซึ่งรับคริปโตโดยไม่ต้องตรวจ ID ให้ RAM 4 GB ขึ้นไปต่อ vCPU สำหรับฐานข้อมูล RAM ต่อ vCPU สำคัญพอ ๆ กับจำนวน vCPU

แพ็กเกจที่อยู่เบื้องหลังการนับนั้นแสดงไว้ใน what a dedicated CPU VPS costs per core in November 2026

CPU steal ส่งผลต่อ p99 latency ของ PostgreSQL อย่างไร?

CPU steal ยืดเวลาของ 1% ของคำสั่งที่ช้าที่สุดออกไปนานก่อนที่ค่าฉลี่ยจะเปลี่ยน kernel ของ Linux อธิบาย steal ว่าเป็นการรอโดยไม่สมัครใจ: เวลาที่ vCPU มีงานทำอยู่ขณะที่ hypervisor ไปรันอย่างอื่น backend ที่ถูกหยุดกลางคำสั่งก็หยุดไปเลย และทุกไคลเอนต์ที่รอคำสั่งนั้นหรือรอล็อกที่มันถืออยู่ก็หยุดตามไปด้วย

การหยุดนั้นสั้นและไม่สม่ำเสมอ จึงกระทบเฉพาะคำสั่งที่บังเอิญอยู่บน CPU ในจังหวะนั้น ยกตัวอย่างประกอบ ไม่ใช่การวัด: เมื่อ vCPU สูญเสียเวลาสองสามสิบมิลลิวินาทีให้เพื่อนบ้านเป็นครั้งคราว คำสั่งที่ใช้เวลา 2 ms ซึ่งไปตกในช่วงนั้นจะใช้เวลานานขึ้นสิบเท่า ขณะที่คำสั่งหลายพันรายการรอบ ๆ รันด้วยความเร็วปกติ ค่าเฉลี่ยแทบไม่เปลี่ยน แต่ percentile ที่ 99 แบกต้นทุนทั้งหมดไว้

ฐานข้อมูลบน vCPU แบบ shared จึงดูสุขภาพดีในค่าเฉลี่ยแต่ยังสร้าง timeout อยู่ดี มีสามวิธีอ่านค่าที่เผยให้เห็น:

• Steal: คอลัมน์ %steal ของ mpstat ในช่วงชั่วโมงที่ยุ่งที่สุด อธิบายไว้ใน what CPU steal time is and how to check it on a VPS
• กรณีที่แย่ที่สุด: pg_stat_statements รายงาน max_exec_time และ stddev_exec_time ต่อคำสั่ง แต่ไม่มี percentile
• Percentile: log_min_duration_statement (เช่น 250ms) บันทึกคำสั่งที่ช้า ส่วน 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

vCPU แบบ dedicated เปลี่ยนอะไรสำหรับฐานข้อมูล?

vCPU แบบ dedicated ขจัดต้นตอหนึ่งเดียวของ tail latency ที่ปรับจากภายใน VPS ไม่ได้ plan ที่ช้า index ที่ขาดหาย และ lock contention เป็นเรื่องที่ผู้ดูแลต้องแก้ แต่ batch job ของเพื่อนบ้านบน core แบบ shared ไม่ใช่ กรณีทั่วไปอธิบายไว้ใน what is the difference between a shared and a dedicated vCPU บน VPS ของ Cobaltfell:

• CPU: vCPU หนึ่งตัวคือหนึ่ง hardware thread ของโปรเซสเซอร์โฮสต์ vCPU ของคุณถูก pin แบบหนึ่งต่อหนึ่งเข้ากับ VPS ของคุณและไม่ถูกให้เช่าต่อให้ลูกค้ารายอื่น และสอง thread ของ physical core หนึ่งตัวจะอยู่ด้วยกันเสมอ ดังนั้นทุก 2 vCPU จึงรวมเป็นหนึ่ง whole core ที่ไม่มีเพื่อนบ้านมาแชร์
• Steal: บน vCPU แบบ dedicated ค่า steal time ควรอยู่ที่ศูนย์หรือใกล้ศูนย์ เราจะเผยแพร่ตัวเลขที่วัดได้จากเครื่องของเราเองพร้อมวันที่ และจะไม่ใช้ค่าประมาณ
• หน่วยความจำ: RAM ของแพ็กเกจของคุณถูกกันไว้สำหรับ VPS ของคุณและไม่มีการ overcommit
• ดิสก์: ที่เก็บข้อมูล NVMe ในทุกแพ็กเกจ
• Load: ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก คำสั่ง VACUUM หรือการสร้าง index ที่ยาวนานจะรันเต็มกำลัง

ตระกูลโปรเซสเซอร์คือ AMD EPYC 9004/9005 (Zen 4 / Zen 5)

เมื่อใดที่ VPS ไม่ใช่ที่ที่เหมาะกับ PostgreSQL?

VPS ไม่ใช่ที่ที่เหมาะเมื่อข้อมูลที่ถูก query ทุกนาทีมีขนาดใหญ่กว่า RAM ของแพ็กเกจที่ใหญ่ที่สุดมาก หรือเมื่อต้องมีคนดูแล replica และ backup ให้ Fell 16 มี 32 GB working set ที่ไม่พอดีกับหน่วยความจำจะเปลี่ยนทุกคำสั่งให้เป็นการอ่านจากดิสก์ และ throughput ของที่เก็บข้อมูล ไม่ใช่ vCPU จะเป็นตัวกำหนดจังหวะ

backup ยังเป็นหน้าที่ของผู้ดูแล: ไม่มีการสำรองข้อมูลในแพ็กเกจใดๆ: โปรดเก็บสำเนาข้อมูลของคุณไว้ที่อื่น pg_dump ที่รันทุกคืนหรือการส่ง WAL archive ไปยังที่เก็บข้อมูลอีกที่หนึ่งครอบคลุมฐานข้อมูลขนาดเล็กส่วนใหญ่ได้ การทดสอบ restore ควรอยู่ในปฏิทินก่อนที่จะต้องใช้จริง

failover ข้าม VPS สองหรือสามเครื่องด้วย streaming replication ทำได้ แต่ต้องจัดการเอง Cobaltfell ขายเซิร์ฟเวอร์ ไม่ใช่ฐานข้อมูลแบบ managed ราคาของแต่ละขนาดแสดงไว้ใน how much a dedicated-core VPS costs