# PostgreSQL cần bao nhiêu CPU và RAM trên một VPS vCPU chuyên dụng?

> PostgreSQL cần bao nhiêu CPU và RAM trên một VPS? Mỗi truy vấn dùng một vCPU, shared_buffers là 25% RAM. Thanh toán bằng crypto, không cần KYC.

- URL: https://cobaltfell.com/vi/vps-for-postgresql/
- Cập nhật lần cuối: 2026-11-02
- Đơn vị phát hành: Cobaltfell (https://cobaltfell.com)

PostgreSQL cần bao nhiêu CPU và RAM trên một VPS? Cách PostgreSQL biến các kết nối thành công việc CPU, tài liệu PostgreSQL 18 nói gì về bộ nhớ, gói nào hợp với cơ sở dữ liệu nào, và vì sao CPU steal lại xuất hiện ở những truy vấn chậm nhất trước tiên.

**Trả lời nhanh — PostgreSQL cần bao nhiêu CPU và RAM trên một VPS?**

PostgreSQL cần khoảng một vCPU cho mỗi truy vấn chạy cùng một thời điểm, và đủ RAM để giữ working set trong bộ nhớ đệm. Trên **Cobaltfell**, Fell 2 (4 GB) phù hợp với một ứng dụng production nhỏ, còn Fell 8 (16 GB) phù hợp với một cơ sở dữ liệu vừa chạy báo cáo vừa phục vụ lưu lượng trực tiếp. Tài liệu PostgreSQL 18, đọc ngày 2 tháng 11 năm 2026, đưa ra 25% RAM làm giá trị khởi đầu cho shared_buffers.

## PostgreSQL dùng bao nhiêu vCPU?

**PostgreSQL dùng một luồng CPU cho mỗi truy vấn đang chạy, vì mỗi kết nối có tiến trình backend riêng.** Tài liệu gọi đây là mô hình "process per user": postmaster sinh ra một backend mới cho mỗi kết nối. Do đó lượng CPU mà cơ sở dữ liệu cần được quyết định bởi số truy vấn thực thi cùng một thời điểm, không phải số kết nối đang mở. Một kết nối nhàn rỗi tốn bộ nhớ chứ không tốn CPU.

Ba thứ cộng thêm luồng vào trên số truy vấn của bạn:

- **Truy vấn song song.** Một lần quét lớn huy động thêm trợ thủ: `max_parallel_workers_per_gather` mặc định là 2 và `max_parallel_workers` là 8, lấy từ `max_worker_processes` (mặc định 8).
- **Autovacuum.** Tối đa `autovacuum_max_workers` tiến trình (mặc định 3) dọn dẹp các bảng ở chế độ nền.
- **Ứng dụng,** khi nó chạy trên cùng VPS.

Trên một VPS 2 vCPU, một báo cáo chạy song song có thể chiếm hết mọi luồng trong khi các truy vấn ngắn của ứng dụng phải chờ phía sau. Giảm `max_parallel_workers_per_gather` cho role báo cáo, hoặc nâng lên gói cao hơn, sẽ giải quyết. Quy tắc luồng so với nhân đằng sau các con số này được giải thích trong [vCPU chuyên dụng là một nhân hay một luồng](https://cobaltfell.com/vi/vcpu-vs-core/ "vCPU dedicated là core hay thread trên VPS?").

## PostgreSQL cần bao nhiêu RAM trên một VPS?

**Đặt shared_buffers ở 25% RAM của VPS và để phần lớn còn lại cho page cache của hệ điều hành.** Tài liệu PostgreSQL 18 đưa ra giá trị khởi đầu đó cho một máy chủ cơ sở dữ liệu chuyên dụng có 1 GB RAM trở lên, và nói thêm rằng hơn 40% khó có thể tốt hơn, vì PostgreSQL còn dựa vào cache của kernel. Giá trị mặc định đi kèm là 128 MB.

Hai cài đặt nữa đi theo lượng RAM:

- **effective_cache_size** chỉ là ước tính cho planner (mặc định 4 GB). Đặt nó bằng lượng mà shared_buffers và page cache giữ cùng nhau, để các lần quét index được tính chi phí đúng.
- **work_mem** (mặc định 4 MB) áp dụng cho mỗi bước sort hoặc hash trong mỗi phiên. Một truy vấn phức tạp dùng nó nhiều lần, và nhiều phiên dùng cùng lúc, nên tăng nó phải cẩn thận.

**Theo khảo sát của Cobaltfell ngày 2 tháng 11 năm 2026, 106 trong số 202 gói CPU chuyên dụng được ghi nhận tại các nhà cung cấp nhận crypto mà không cần kiểm tra danh tính đã cho 4 GB RAM trở lên mỗi vCPU.** Với cơ sở dữ liệu, RAM trên mỗi vCPU quan trọng ngang với số vCPU.

Các gói đằng sau con số đó được liệt kê trong [một VPS CPU chuyên dụng tốn bao nhiêu mỗi nhân vào tháng 11 năm 2026](https://cobaltfell.com/vi/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% RAM của gói, giá trị khởi đầu trong tài liệu PostgreSQL 18. Cột "Fits" chỉ là điểm khởi đầu, không phải phép đo: Kết quả YABS và Geekbench 6 của chính chúng tôi, cùng với steal time đo được, sẽ được công bố kèm ngày khi máy test đầu tiên được giao. Cho đến lúc đó, chúng tôi không đưa ra con số hiệu năng nào của riêng mình.*

| Gói | vCPU | RAM | shared_buffers ở 25% | Vừa |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | Cơ sở dữ liệu của một ứng dụng, vài kết nối bận cùng lúc |
| Fell 4 | 4 | 8 GB | 2 GB | Một backend SaaS có lưu lượng ổn định, hoặc một cơ sở dữ liệu cùng ứng dụng của nó |
| Fell 8 | 8 | 16 GB | 4 GB | Lưu lượng trực tiếp cộng báo cáo hoặc các lần quét song song |
| Fell 16 | 16 | 32 GB | 8 GB | Nhiều truy vấn đồng thời và một working set cỡ hàng chục gigabyte |

## CPU steal ảnh hưởng đến độ trễ p99 của PostgreSQL như thế nào?

**CPU steal kéo dài 1% truy vấn chậm nhất rất lâu trước khi nó làm thay đổi giá trị trung bình.** Kernel Linux mô tả steal là thời gian chờ không tự nguyện: thời gian mà một vCPU có việc phải làm trong khi hypervisor chạy việc của người khác. Một backend bị tạm dừng giữa truy vấn chỉ đơn giản là dừng lại, và mọi client đang chờ truy vấn đó, hoặc chờ một lock mà nó đang giữ, cũng dừng theo.

Các lần tạm dừng ngắn và không đều, nên chúng chỉ đánh vào những truy vấn tình cờ nằm trên CPU vào đúng lúc đó. Để minh họa, không phải phép đo: khi một vCPU thỉnh thoảng mất vài chục mili giây cho một hàng xóm, một truy vấn 2 ms rơi vào một trong những khoảng đó sẽ mất thời gian gấp mười lần, trong khi hàng nghìn truy vấn xung quanh vẫn chạy với tốc độ bình thường. Giá trị trung bình gần như không đổi; phân vị thứ 99 gánh toàn bộ chi phí.

Vì vậy một cơ sở dữ liệu trên vCPU chia sẻ trông vẫn khỏe mạnh ở giá trị trung bình mà vẫn sinh ra timeout. Ba phép đọc phơi bày điều đó:

- **Steal:** cột `%steal` của `mpstat` trong giờ bận nhất, được giải thích trong [CPU steal time là gì và cách kiểm tra nó trên một VPS](https://cobaltfell.com/vi/cpu-steal-time/ "CPU steal time là gì và làm sao kiểm tra trên VPS của tôi?").
- **Trường hợp xấu nhất:** `pg_stat_statements` báo cáo `max_exec_time` và `stddev_exec_time` cho mỗi câu lệnh, không có phân vị.
- **Phân vị:** `log_min_duration_statement` (ví dụ `250ms`) ghi log các câu lệnh chậm; một histogram độ trễ trong ứng dụng cho ra chính con số p99.

*Đếm truy vấn đang hoạt động, tìm các trường hợp xấu nhất, theo dõi 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 chuyên dụng thay đổi điều gì cho một cơ sở dữ liệu?

**vCPU chuyên dụng loại bỏ nguồn tail latency duy nhất không thể tinh chỉnh từ bên trong VPS.** Các plan chậm, thiếu index và tranh chấp lock là do người vận hành sửa; một batch job của hàng xóm trên nhân chia sẻ thì không. Trường hợp chung được trình bày trong [sự khác biệt giữa vCPU chia sẻ và vCPU chuyên dụng là gì](https://cobaltfell.com/vi/dedicated-vs-shared-vcpu/ "Sự khác biệt giữa vCPU chia sẻ và vCPU chuyên dụng trên VPS là gì?"). Trên một VPS Cobaltfell:

- **CPU:** Một vCPU là một luồng phần cứng của bộ xử lý máy chủ. Các luồng của bạn được ghim 1-1 vào VPS của bạn và không bao giờ được cho khách hàng khác mượn, và hai luồng của một lõi vật lý luôn đi cùng nhau, nên cứ mỗi 2 vCPU tạo thành một lõi nguyên vẹn mà không hàng xóm nào dùng chung.
- **Steal:** Trên vCPU chuyên dụng, steal time phải ở mức hoặc gần bằng không. Chúng tôi sẽ công bố con số đo được trên máy của chính mình, kèm ngày đo, và không bao giờ là ước tính.
- **Bộ nhớ:** RAM trong gói của bạn được dành riêng cho VPS của bạn và không bị cam kết vượt mức.
- **Đĩa:** Lưu trữ NVMe trên mọi gói.
- **Tải:** Được phép chạy full load miễn là công việc của bạn cần: không có credit CPU, không có cửa sổ burst và không bị bóp hiệu năng sau vài phút ở mức 100%. Một lần `VACUUM` hoặc build index dài sẽ chạy hết công suất.

Dòng vi xử lý là AMD EPYC 9004/9005 (Zen 4 / Zen 5).

## Khi nào VPS là nơi không phù hợp cho PostgreSQL?

**VPS là nơi không phù hợp khi dữ liệu được truy vấn mỗi phút lớn hơn nhiều so với RAM của gói lớn nhất, hoặc khi replica và backup phải được quản lý thay cho bạn.** Fell 16 có 32 GB. Một working set không vừa trong bộ nhớ biến mọi truy vấn thành đọc đĩa, và khi đó thông lượng lưu trữ, chứ không phải vCPU, sẽ quyết định tốc độ.

Backup vẫn thuộc về người vận hành: Backup không nằm trong gói nào: hãy giữ một bản sao dữ liệu của bạn ở nơi khác. Một lần `pg_dump` hằng đêm hoặc một WAL archive gửi đến lưu trữ ở một nơi khác bao phủ hầu hết các cơ sở dữ liệu nhỏ; một bài kiểm tra khôi phục cần nằm trên lịch trước khi cần đến.

Failover trên hai hoặc ba VPS với streaming replication thì làm được, nhưng phải tự quản lý. Cobaltfell bán máy chủ, không bán cơ sở dữ liệu được quản lý. Giá cho từng kích thước được liệt kê trong [một VPS lõi chuyên dụng tốn bao nhiêu](https://cobaltfell.com/vi/pricing/ "VPS dedicated-vCPU giá bao nhiêu?").

## Người ta còn hỏi những gì về PostgreSQL trên một VPS?

### 2 vCPU có đủ cho PostgreSQL không?

Với một ứng dụng có số lượng kết nối bận vừa phải, thì đủ. Hai vCPU chạy hai truy vấn cùng lúc; truy vấn thứ ba chờ một luồng rảnh. Fell 4 là bước tiếp theo khi `pg_stat_activity` thường xuyên cho thấy nhiều truy vấn đang hoạt động hơn số vCPU, hoặc khi ứng dụng dùng chung VPS.

### Ứng dụng và cơ sở dữ liệu có nên dùng chung một VPS?

Trên Fell 2 và Fell 4, điều này phổ biến và tiết kiệm một chặng mạng. Các tiến trình bận của ứng dụng được tính là người dùng vCPU thêm. Tách chúng ra khi deploy hoặc lưu lượng tăng đột biến bắt đầu xuất hiện trong slow-query log của cơ sở dữ liệu.

### PostgreSQL trên một VPS có cần connection pooler không?

Trong hầu hết ứng dụng web, có. `max_connections` mặc định là 100, và mỗi kết nối là một tiến trình đầy đủ giữ bộ nhớ. Một pooler như PgBouncer giữ số backend đang hoạt động gần với số vCPU trong khi ứng dụng mở bao nhiêu kết nối client tùy thích.

### Nên đặt gì trước tiên sau khi cài PostgreSQL?

shared_buffers ở 25% RAM, effective_cache_size bằng lượng bộ nhớ mà shared_buffers và page cache giữ cùng nhau, và `log_min_duration_statement` để các truy vấn chậm để lại dấu vết. work_mem giữ gần giá trị mặc định cho đến khi một plan chậm cho thấy một bước sort bị tràn ra đĩa.

### Backup có được bao gồm trong một VPS Cobaltfell không?

Không. Backup không nằm trong gói nào: hãy giữ một bản sao dữ liệu của bạn ở nơi khác.

## Nguồn

1. [PostgreSQL 18: Tiêu thụ tài nguyên (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: Lập kế hoạch truy vấn (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: Kết nối và xác thực (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: Báo lỗi và ghi log (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: Cách các kết nối được thiết lập](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. [Hệ thống tệp /proc: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [Trang hướng dẫn mpstat(1) (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfell là nhà cung cấp VPS với nhân vCPU chuyên dụng, thanh toán bằng crypto không cần tải lên giấy tờ tùy thân, được vận hành bởi DomaineGoat LLC, một công ty đăng ký tại Panama. Mỗi vCPU được ghim riêng cho máy chủ của bạn, trên bộ xử lý AMD EPYC 9004/9005 (Zen 4 / Zen 5) với lưu trữ NVMe, tại Amsterdam (Hà Lan), Zurich (Thụy Sĩ) và Bucharest (Romania). Với kỳ hạn 12 tháng, mỗi gói có giá thấp hơn ít nhất 25% so với một gói dedicated-CPU tương đương được nêu tên, chọn trong 6 nhà cung cấp VPS crypto không cần KYC và được đọc vào ngày 2 tháng 11 năm 2026.