ปรับแต่ง PostgreSQL เบื้องต้นให้เหมาะกับขนาดเครื่อง

PostgreSQL มาพร้อมค่าเริ่มต้นที่ระมัดระวังมาก เพราะออกแบบให้เริ่มทำงานได้บนเครื่องเล็กที่สุด ค่า shared_buffers เริ่มต้นเพียง 128 MB หมายความว่าเซิร์ฟเวอร์ 32 GB ของคุณกำลังใช้หน่วยความจำไม่ถึงหนึ่งเปอร์เซ็นต์สำหรับแคชข้อมูล

คู่มือนี้ตั้งค่าตามขนาดเครื่องจริง พร้อมอธิบายว่าแต่ละค่าทำอะไรและมีผลอย่างไร เพื่อให้ปรับต่อได้เองเมื่อภาระงานเปลี่ยน

สิ่งที่ต้องเตรียม

• PostgreSQL 14 ขึ้นไปบน Linux
• รู้จำนวน RAM และชนิดดิสก์ของเครื่อง
• ช่วงเวลาที่รีสตาร์ตบริการได้ เพราะบางค่าต้องรีสตาร์ต

psql -c "SELECT version();"
free -h
lscpu | grep -E '^CPU\(s\)|Model name'

ขั้นตอนที่ 1: ดูค่าปัจจุบัน

sudo -u postgres psql -c "SHOW shared_buffers;"
sudo -u postgres psql -c "SHOW work_mem;"
sudo -u postgres psql -c "SHOW effective_cache_size;"
sudo -u postgres psql -c "SHOW max_connections;"

# ดูค่าที่ถูกแก้จากค่าเริ่มต้นทั้งหมด
sudo -u postgres psql -c "SELECT name, setting, unit, source FROM pg_settings WHERE source NOT IN ('default','override') ORDER BY name;"

หาไฟล์คอนฟิก

sudo -u postgres psql -c "SHOW config_file;"
sudo nano /etc/postgresql/16/main/postgresql.conf

ขั้นตอนที่ 2: ค่าหน่วยความจำ

ตัวอย่างต่อไปนี้อิงเครื่อง 16 GB RAM ที่ใช้เป็นฐานข้อมูลอย่างเดียว ปรับตามสัดส่วนสำหรับเครื่องขนาดอื่น

# แคชข้อมูลของ PostgreSQL เอง ประมาณ 25% ของ RAM
shared_buffers = 4GB

# บอก Planner ว่ามีหน่วยความจำรวมทั้งระบบเท่าไรสำหรับแคช
# ไม่ได้จองจริง ใช้ประกอบการตัดสินใจเลือกแผน ประมาณ 60-75% ของ RAM
effective_cache_size = 12GB

# หน่วยความจำต่อการเรียงหรือ hash หนึ่งครั้ง จัดสรรได้หลายครั้งต่อ Query
work_mem = 32MB

# ใช้ตอนสร้าง Index หรือ VACUUM ตั้งสูงได้เพราะทำไม่บ่อย
maintenance_work_mem = 1GB

ข้อควรระวังที่สำคัญที่สุดคือ work_mem ค่านี้จัดสรรต่อการดำเนินการ ไม่ใช่ต่อการเชื่อมต่อ Query เดียวที่มีการเรียงสามจุดและทำงานขนานสองสายอาจใช้ work_mem ถึงหกเท่า คำนวณเพดานคร่าว ๆ ด้วย max_connections คูณ work_mem คูณสาม แล้วดูว่ายังอยู่ในหน่วยความจำที่มี

ขั้นตอนที่ 3: ค่าการเขียนลงดิสก์

# ขนาดของ WAL ก่อนเกิด checkpoint ตั้งใหญ่ลดการเขียนซ้ำ
max_wal_size = 4GB
min_wal_size = 1GB

# กระจายการเขียนของ checkpoint ให้ทั่วช่วงเวลา ลดอาการกระตุก
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min

# บัฟเฟอร์ WAL
wal_buffers = 16MB

# ค่าต้นทุนการอ่านแบบสุ่ม สำหรับ SSD ต้องลดจาก 4.0
random_page_cost = 1.1
effective_io_concurrency = 200

random_page_cost = 1.1 เป็นค่าที่มีผลมากและมักถูกลืม ค่าเริ่มต้น 4.0 ตั้งไว้สำหรับฮาร์ดดิสก์จานหมุน บน SSD ค่านี้ทำให้ Planner หลีกเลี่ยงการใช้ Index ทั้งที่ควรใช้ การลดลงมาทำให้เลือกแผนที่ดีขึ้นทันที

ขั้นตอนที่ 4: ค่าการทำงานขนาน

max_worker_processes = 8
max_parallel_workers = 8
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 4

ตั้ง max_worker_processes เท่ากับจำนวนคอร์ การทำงานขนานช่วยได้มากกับ Query ที่สแกนข้อมูลจำนวนมาก แต่ไม่ช่วยกับ Query ที่ดึงไม่กี่แถวผ่าน Index

ขั้นตอนที่ 5: ค่าการบำรุงรักษาอัตโนมัติ

autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 30s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

ค่าเริ่มต้นของ autovacuum_vacuum_scale_factor คือ 0.2 หมายถึงรอจนมีแถวตายถึง 20% ของตารางจึงเริ่มทำความสะอาด สำหรับตารางล้านแถวคือรอถึงสองแสนแถว ซึ่งช้าเกินไปและทำให้ตารางบวมขึ้นเรื่อย ๆ ลดเหลือ 0.05 ทำให้ทำงานถี่ขึ้นแต่แต่ละครั้งเบากว่า

ขั้นตอนที่ 6: เปิดการเก็บสถิติ Query

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all

# บันทึก Query ที่ช้ากว่าหนึ่งวินาที
log_min_duration_statement = 1000
log_checkpoints = on
log_lock_waits = on
log_temp_files = 0

sudo systemctl restart postgresql
sudo -u postgres psql -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;"

ขั้นตอนที่ 7: วัดผล

-- Query ที่ใช้เวลารวมมากที่สุด
SELECT substr(query, 1, 80) AS query,
       calls,
       round(total_exec_time::numeric, 0) AS total_ms,
       round(mean_exec_time::numeric, 2) AS mean_ms,
       rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

-- อัตราการอ่านจากแคช ควรสูงกว่า 99% สำหรับระบบที่ปรับดีแล้ว
SELECT datname,
       round(100.0 * blks_hit / NULLIF(blks_hit + blks_read, 0), 2) AS cache_hit_pct
FROM pg_stat_database
WHERE datname NOT IN ('template0','template1');

-- ตารางที่มีแถวตายสะสมมาก
SELECT relname, n_live_tup, n_dead_tup,
       round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

ล้างสถิติเพื่อเริ่มวัดรอบใหม่หลังปรับค่า

SELECT pg_stat_statements_reset();

ขั้นตอนที่ 8: ตรวจการใช้ Index

-- Index ที่ไม่เคยถูกใช้
SELECT schemaname, relname, indexrelname, idx_scan,
       pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

-- ตารางที่ถูกสแกนทั้งตารางบ่อย
SELECT relname, seq_scan, seq_tup_read, idx_scan,
       round(seq_tup_read::numeric / NULLIF(seq_scan, 0), 0) AS avg_rows_per_scan
FROM pg_stat_user_tables
WHERE seq_scan > 100
ORDER BY seq_tup_read DESC LIMIT 10;

ปัญหาที่พบบ่อย

รีสตาร์ตไม่ขึ้นหลังแก้คอนฟิก

ดูสาเหตุจาก Log ก่อนเสมอ

sudo journalctl -u postgresql -n 50 --no-pager
sudo tail -50 /var/log/postgresql/postgresql-16-main.log

สาเหตุที่พบบ่อยคือ shared_buffers ใหญ่เกินกว่าที่หน่วยความจำร่วมของระบบอนุญาต ปรับ kernel.shmmax ด้วย sysctl หรือลดค่าลง

ตั้ง work_mem สูงแล้วเครื่องหมดหน่วยความจำ

จำไว้ว่าค่านี้จัดสรรต่อการดำเนินการ ลดลงมาเป็นค่ากลาง แล้วตั้งสูงเฉพาะเซสชันที่ต้องการด้วย SET work_mem = '256MB'; ก่อนรัน Query หนัก

Query ยังช้าแม้ปรับค่าแล้ว

การปรับค่าไม่แก้ปัญหา Query ที่ออกแบบไม่ดีหรือขาด Index ใช้ EXPLAIN (ANALYZE, BUFFERS) ดูแผนจริง และแก้ที่ Query หรือ Index เป็นอันดับแรกเสมอ

พื้นที่ดิสก์โตขึ้นเรื่อย ๆ

ตารางบวมเพราะ autovacuum ตามไม่ทัน ตรวจตามขั้นตอนที่ 7 และพิจารณา VACUUM FULL ในช่วงที่ปิดระบบได้ เพราะคำสั่งนี้ล็อกตารางทั้งตาราง

ต้องการให้ทีมวิศวกรช่วยปรับจูน PostgreSQL ให้เหมาะกับงานของคุณ ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/