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

> PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS? หนึ่ง dedicated vCPU ต่อหนึ่ง active query, shared_buffers ที่ 25% ของ RAM, 2 ถึง 16 vCPU จ่ายด้วยคริปโต

- URL: https://cobaltfell.com/th/vps-for-postgresql/
- อัปเดตล่าสุด: 2026-11-02
- ผู้เผยแพร่: Cobaltfell (https://cobaltfell.com)

PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS? PostgreSQL เปลี่ยนการเชื่อมต่อเป็นงาน CPU อย่างไร เอกสาร PostgreSQL 18 กล่าวถึงหน่วยความจำว่าอย่างไร แพ็กเกจไหนเหมาะกับฐานข้อมูลแบบไหน และทำไม CPU steal ถึงปรากฏในคำสั่งที่ช้าที่สุดก่อน

**คำตอบแบบสั้น — PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS?**

PostgreSQL ต้องใช้ประมาณหนึ่ง vCPU ต่อหนึ่งคำสั่งที่รันพร้อมกัน และ RAM ให้เพียงพอที่จะเก็บ working set ไว้ในแคช บน **Cobaltfell** แพ็กเกจ Fell 2 (4 GB) เหมาะกับแอปโปรดักชันขนาดเล็ก และ Fell 8 (16 GB) เหมาะกับฐานข้อมูลที่รันรายงานควบคู่กับทราฟฟิกสด เอกสาร PostgreSQL 18 ซึ่งอ่านเมื่อวันที่ 2 พฤศจิกายน 2026 ระบุให้ตั้ง shared_buffers เริ่มต้นที่ 25% ของ RAM

## 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](https://cobaltfell.com/th/vcpu-vs-core/ "dedicated vCPU บน VPS เป็น core หรือ 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](https://cobaltfell.com/th/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026")

*shared_buffers = 25% ของ RAM ของแพ็กเกจ ซึ่งเป็นค่าเริ่มต้นในเอกสาร PostgreSQL 18 คอลัมน์ "Fits" เป็นจุดเริ่มต้น ไม่ใช่การวัด: ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง*

| แพ็กเกจ | vCPU | RAM | shared_buffers ที่ 25% | พอดี |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | ฐานข้อมูลของแอปเดียว มีการเชื่อมต่อที่ใช้งานอยู่ไม่กี่รายการในแต่ละช่วง |
| Fell 4 | 4 | 8 GB | 2 GB | SaaS backend ที่มีทราฟฟิกสม่ำเสมอ หรือฐานข้อมูลพร้อมแอป |
| Fell 8 | 8 | 16 GB | 4 GB | ทราฟฟิกสดพร้อมรายงานหรือการสแกนแบบ parallel |
| Fell 16 | 16 | 32 GB | 8 GB | คำสั่งจำนวนมากที่รันพร้อมกันและ working set ขนาดหลายสิบกิกะไบต์ |

## 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](https://cobaltfell.com/th/cpu-steal-time/ "CPU steal time คืออะไร และตรวจสอบบน VPS ของฉันได้อย่างไร?")
- **กรณีที่แย่ที่สุด:** `pg_stat_statements` รายงาน `max_exec_time` และ `stddev_exec_time` ต่อคำสั่ง แต่ไม่มี percentile
- **Percentile:** `log_min_duration_statement` (เช่น `250ms`) บันทึกคำสั่งที่ช้า ส่วน latency histogram ในแอปพลิเคชันให้ค่า p99 โดยตรง

*นับคำสั่งที่ active หากรณีที่แย่ที่สุด ดู steal*

```bash
# 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](https://cobaltfell.com/th/dedicated-vs-shared-vcpu/ "shared vCPU กับ dedicated vCPU บน VPS ต่างกันอย่างไร?") บน 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](https://cobaltfell.com/th/pricing/ "dedicated-vCPU VPS ราคาเท่าไหร่?")

## มีคำถามอื่นอะไรบ้างที่ผู้คนถามเกี่ยวกับ PostgreSQL บน VPS?

### 2 vCPU เพียงพอสำหรับ PostgreSQL หรือไม่?

สำหรับแอปพลิเคชันเดียวที่มีการเชื่อมต่อที่ใช้งานอยู่จำนวนพอประมาณ เพียงพอ สอง vCPU รันสองคำสั่งพร้อมกันได้ คำสั่งที่สามต้องรอ thread ว่าง Fell 4 คือขั้นถัดไปเมื่อ `pg_stat_activity` แสดงคำสั่งที่ active มากกว่า vCPU บ่อยครั้ง หรือเมื่อแอปแชร์ VPS เดียวกัน

### แอปกับฐานข้อมูลควรแชร์ VPS เดียวกันหรือไม่?

บน Fell 2 และ Fell 4 เป็นเรื่องปกติและประหยัดการเดินทางผ่านเครือข่ายหนึ่ง hop process ที่ยุ่งของแอปนับเป็นผู้ใช้ vCPU เพิ่มเติม แยกออกจากกันเมื่อการ deploy หรือทราฟฟิกพุ่งเริ่มปรากฏใน slow-query log ของฐานข้อมูล

### PostgreSQL บน VPS ต้องใช้ connection pooler หรือไม่?

ในเว็บแอปพลิเคชันส่วนใหญ่ ต้องใช้ `max_connections` มีค่าเริ่มต้นเป็น 100 และแต่ละการเชื่อมต่อคือ process เต็มรูปแบบที่ถือหน่วยความจำไว้ pooler อย่าง PgBouncer ช่วยให้จำนวน backend ที่ active ใกล้เคียงกับจำนวน vCPU ขณะที่แอปเปิดการเชื่อมต่อฝั่งไคลเอนต์ได้มากเท่าที่ต้องการ

### ควรตั้งค่าอะไรก่อนหลังติดตั้ง PostgreSQL?

shared_buffers ที่ 25% ของ RAM, effective_cache_size ให้เท่ากับหน่วยความจำที่ shared_buffers และ page cache เก็บไว้รวมกัน และ `log_min_duration_statement` เพื่อให้คำสั่งที่ช้าทิ้งร่องรอยไว้ work_mem ควรอยู่ใกล้ค่าเริ่มต้นจนกว่า slow plan จะแสดงให้เห็นว่า sort ล้นลงดิสก์

### backup รวมอยู่ใน VPS ของ Cobaltfell หรือไม่?

ไม่รวม ไม่มีการสำรองข้อมูลในแพ็กเกจใดๆ: โปรดเก็บสำเนาข้อมูลของคุณไว้ที่อื่น

## แหล่งข้อมูล

1. [PostgreSQL 18: Resource consumption (shared_buffers, work_mem, worker processes)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Query planning (effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
3. [PostgreSQL 18: Connections and authentication (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
4. [PostgreSQL 18: Vacuuming (autovacuum_max_workers)](https://www.postgresql.org/docs/current/runtime-config-vacuum.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
5. [PostgreSQL 18: Error reporting and logging (log_min_duration_statement)](https://www.postgresql.org/docs/current/runtime-config-logging.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
6. [PostgreSQL 18: How connections are established](https://www.postgresql.org/docs/current/connect-estab.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
7. [PostgreSQL 18: pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
8. [ระบบไฟล์ /proc: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [หน้าคู่มือ mpstat(1) (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfell เป็นผู้ให้บริการ VPS ที่มีคอร์ vCPU เฉพาะ จ่ายด้วยคริปโตโดยไม่ต้องอัปโหลดบัตรประชาชน ดำเนินการโดย DomaineGoat LLC บริษัทจดทะเบียนในปานามา vCPU ทุกคอร์ถูกผูกไว้กับเซิร์ฟเวอร์ของคุณเพียงเครื่องเดียว บนโปรเซสเซอร์ AMD EPYC 9004/9005 (Zen 4 / Zen 5) พร้อมที่เก็บข้อมูล NVMe ในอัมสเตอร์ดัม (เนเธอร์แลนด์) ซูริก (สวิตเซอร์แลนด์) และบูคาเรสต์ (โรมาเนีย) ในระยะสัญญา 12 เดือน แต่ละแพ็กเกจมีราคาต่ำกว่าแผน dedicated-CPU ที่เทียบเคียงได้และระบุชื่อไว้อย่างน้อย 25% โดยเลือกจากผู้ให้บริการ crypto VPS แบบไม่ต้อง KYC 6 ราย และอ่านข้อมูลเมื่อวันที่ 2 พฤศจิกายน 2026