#postgresql

256 bài viết
Lập trình 22/09/2026 10 phút

PgBouncer đo thật: 1.000 client chạy trên đúng 20 backend PostgreSQL trong khi 300 client trực tiếp bị từ chối, proxy một luồng chạm trần 70.000 TPS so với 235.000 trực tiếp, và một SET work_mem của một client làm bẩn pool cho 50 client sau

PgBouncer 1.26 ở transaction mode với pool 20 trước PostgreSQL 16 max_connections 100. Connect mỗi giao dịch: 1.224 TPS trực tiếp, 2.322 qua pool. 300 client trực tiếp nhận FATAL too many clients; 1.000 client qua pool chạy trên 20 backend với 951 client xếp hàng, 64.088 TPS. Nhưng PgBouncer một luồng chạm trần 70.000 TPS truy vấn đơn giản so với 235.000 trực tiếp. Một client SET work_mem rồi ngắt: 50 trong 50 client mới nhận 64MB vì transaction mode không reset phiên. Prepared statement lỗi với max_prepared_statements 0, chạy 89.480 TPS khi bật 100. Pool cạn: SELECT 1 chờ 2,9 giây.

#transaction-pooling#postgresql#van-hanh#pgbouncer#connection-pool
7
Lập trình 22/09/2026 9 phút

Tổng kết sê-ri vận hành PostgreSQL đo thật: runbook bốn mục rút từ mười một phần, tám con số sức khoẻ phải theo dõi, và một bó truy vấn chạy trên chính cụm vừa đi qua năm timeline và 39 GB WAL chỉ ra ngay ba việc cần làm

Phần cuối gom mười một phần thành một runbook: sao lưu hỏi khôi phục về khi nào, sao chép nhớ slot giữ WAL bằng đĩa primary, sức khoẻ theo dõi tám con số, thay đổi schema tính bằng thời gian khoá. Bó mười truy vấn chạy trên cụm lúc kết thúc: archiver 319 segment 0 lỗi, lag 0 byte, slot active, age 0,6% ngưỡng wraparound, nhưng 77% checkpoint bị ép bởi max_wal_size, backend tự ghi 1,5 triệu buffer so với 48.000 của checkpointer, bảng 3 triệu dòng chưa được autovacuum lần nào với 93.000 dead tuple, và replica báo 268 giây kể từ giao dịch cuối trong khi lag thật bằng 0.

#monitoring#postgresql#van-hanh#tong-ket#runbook
7
DevOps 01/09/2026 9 phút

PostgreSQL trong Kubernetes chạy 10.366 tps và khởi động lại trong 0,3 giây — nhưng cordon đúng một node là pod Pending vĩnh viễn, vì dữ liệu không đi theo được

Dựng PostgreSQL bằng StatefulSet, đo phần chạy tốt rồi đo đúng chỗ nó gãy. Phần tốt: 10.366 tps, dừng sạch trong 13 ms, khởi động lại 0,3 giây, giữ nguyên định danh và volume. Phần không sửa được bằng YAML: PersistentVolume ghim vào một node, cordon node đó là pod Pending mãi mãi vì dữ liệu nằm trên đĩa node đó. Kubernetes dựng lại pod giỏi, nhưng chỉ ở nơi có dữ liệu — và nó không biết cái nào là bản chính.

#postgresql#devops#kubernetes#zero-to-hero
31
Backend 01/09/2026 8 phút

Redis nhanh hơn PostgreSQL 4,1 lần khi ghi — không phải 100 lần như lời đồn; và phần lớn khoảng cách đó là độ bền bị bỏ, không phải kiến trúc

Mở đầu sê-ri bốn mươi phần về Redis, không bằng lời quảng cáo mà bằng cách đo nó cạnh PostgreSQL trên đúng cùng một bài toán. Redis nhanh hơn 4,1 lần khi ghi và 2,0 lần khi đọc — nhưng bật cờ UNLOGGED trên Postgres là khoảng cách co còn 1,4 lần, cho thấy Redis nhanh chủ yếu vì mặc định không hứa gì về độ bền. Bộ nhớ mỗi bản ghi gần bằng nhau (185 vs 178 byte), và có một câu hỏi Redis không trả lời được.

#postgresql#redis#hieu-nang#zero-to-hero
32
Backend 01/09/2026 8 phút

Thêm một dòng CREATE INDEX làm truy vấn nhanh hơn 181 lần — tốt hơn cả tỉ lệ trúng cache 99%, và không thêm một hệ thống nào để hỏng

Cache-aside là mẫu dùng Redis phổ biến nhất, nhưng đo thật cho thấy nó thắng ít hơn ta tưởng. Tra khoá chính: Redis GET 0,062 ms ngang PostgreSQL 0,065 ms — đặt cache ở đây chỉ thêm một chỗ để hỏng. Truy vấn đắt 19,9 ms: cache nhanh hơn 321 lần, nhưng một CREATE INDEX kéo nó xuống 0,110 ms — nhanh hơn 181 lần, tốt hơn cả cache trúng 99%. Bộ đệm che một truy vấn chậm; chỉ mục xoá nó.

#postgresql#redis#hieu-nang#zero-to-hero
30
Backend 01/09/2026 7 phút

200 khách cùng gặp một khoá Redis vừa hết hạn tạo ra đúng 200 truy vấn xuống cơ sở dữ liệu — và một dòng khoá kéo nó về 1, còn làm chính người dùng nhanh hơn 6,4 lần

Cache-aside chạy tốt khi mọi thứ bình thường. Bài này đo đúng khoảnh khắc nó không bình thường: một khoá nóng hết hạn và 200 khách cùng lao vào. Không bảo vệ: 200 truy vấn, p50 vọt lên 360 ms. Một khoá độc quyền: 1 truy vấn, p50 xuống 56 ms — nhanh hơn 6,4 lần, vì CSDL không bị 200 mũi cùng đâm. Trả giá trị cũ: không ai phải chờ, p50 chỉ 29 ms.

#postgresql#redis#hieu-nang#zero-to-hero
29