PostgreSQL JSONB Troubleshooting แก้ปัญหา — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

PostgreSQL JSONB Troubleshooting แก้ปัญหา — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

ในยุคที่ข้อมูลไหลเวียนอย่างไม่หยุดยั้งและโครงสร้างข้อมูลมีความซับซ้อนมากขึ้นเรื่อย ๆ

การจัดการฐานข้อมูลแบบยืดหยุ่นและมีประสิทธิภาพจึงกลายเป็นหัวใจสำคัญของระบบที่ทันสมัย หนึ่งในเครื่องมือที่โดดเด่นที่สุดในวงการนี้คือ PostgreSQL พร้อมกับฟีเจอร์ JSONB ซึ่งไม่ใช่แค่ฟีเจอร์เสริม แต่คือพลังขับเคลื่อนระบบงานที่ต้องการความยืดหยุ่นสูง โดยเฉพาะในบริบทของ DevOps, SRE และผู้ดูแลระบบ IT ที่ต้องเผชิญกับปัญหาที่เกิดขึ้นทุกวัน ไม่ว่าจะเป็นการเชื่อมต่อล้มเหลว การอ่าน/เขียนข้อมูลช้า หรือแม้แต่เหตุการณ์ downtime ที่ส่งผลต่อธุรกิจโดยตรง

ผม อ.บอม ซึ่งมีประสบการณ์ด้านระบบและเทคโนโลยีมาตั้งแต่ปี 1997 ตั้งแต่ยุค Bare Metal จนถึงยุค Cloud และ Container Orchestration ได้ใช้ PostgreSQL JSONB มาอย่างต่อเนื่องในโปรเจกต์จริงทั้งในระดับ production และ high-availability setup พบว่าปัญหาที่เกิดขึ้นไม่ได้เกิดจากตัวฐานข้อมูลเอง แต่เกิดจากความเข้าใจผิดในแนวทางการใช้งาน การตั้งค่าที่ไม่เหมาะสม หรือขาดการ monitoring ที่มีประสิทธิภาพ คู่มือฉบับนี้จึงถือกำเนิดขึ้นเพื่อเป็นแนวทางปฏิบัติจริง ไม่ใช่แค่ทฤษฎี ทุกขั้นตอนถูกทดสอบในสภาพแวดล้อม production โดยตรง ไม่ใช่แค่ใน lab

บทความนี้จะพาคุณลัดเลาะจากปัญหาพื้นฐานไปจนถึงการกู้คืนระบบหลังเกิดเหตุการณ์ร้ายแรง ครอบคลุมทั้งด้านการตั้งค่า การวิเคราะห์ข้อผิดพลาด การแก้ไขปัญหาเฉพาะหน้า และกลยุทธ์ป้องกันในอนาคตข้างหน้า โดยเน้นการใช้งานจริงในสภาพแวดล้อมที่มีความซับซ้อนสูง เช่น ระบบ API Gateway, Microservices ที่ต้องอ่าน/เขียนข้อมูล JSON แบบเรียลไทม์ หรือระบบ monitoring ที่ต้องประมวลผลข้อมูลจำนวนมากในเวลาอันสั้น

ทุกคำแนะนำในบทความนี้ได้รับการทดสอบในสภาพแวดล้อมจริงบน Ubuntu 24.04 LTS พร้อมการตั้งค่า high-availability ด้วย Docker Swarm และ Kubernetes ไม่มีการอ้างอิงจากเอกสารที่ไม่ได้ทดสอบ ทุก command ที่แสดงคือสิ่งที่ผมใช้ในงานจริงมาแล้ว ไม่ว่าคุณจะเป็นมือใหม่ที่เพิ่งเริ่มต้น หรือผู้มีประสบการณ์ที่ต้องการ reference ที่ครบถ้วน คู่มือนี้จะเป็นเพื่อนคู่ใจในการแก้ปัญหา PostgreSQL JSONB ได้อย่างมีประสิทธิภาพในปี 2026

---

ในโลกของระบบฐานข้อมูลที่ใช้ JSONB ปัญหาที่พบบ่อยที่สุดมักไม่ใช่ข้อผิดพลาดของตัว JSONB เอง แต่เกิดจากความเข้าใจผิดในพฤติกรรมของระบบ

หรือการตั้งค่าที่ไม่เหมาะสม ตัวอย่างเช่น การที่ query ช้าลงอย่างผิดปกติ หรือ application ไม่สามารถเชื่อมต่อได้ ซึ่งมักถูกตีความว่าเป็นปัญหาของ PostgreSQL JSONB ทันที ทั้งที่อาจเกิดจาก network, memory, หรือ configuration ของ application ที่ผิดพลาด

ในโลกของระบบฐานข้อมูลที่ใช้ JSONB ปัญหาที่พบบ่อยที่สุดมักไม่ใช่ข้อผิดพลาดของตัว JSONB เอง แต่เกิดจากความเข้าใจผิดในพฤติกรรมของระบบ หรือการตั้งค่าที่ไม่เหมาะสม ตัวอย่างเช่น การที่ query ช้าลงอย่างผิดปกติ หรือ application ไม่สามารถเชื่อมต่อได้ ซึ่งมักถูกตีความว่าเป็นปัญหาของ PostgreSQL JSONB ทันที ทั้งที่อาจเกิดจาก network, memory, หรือ configuration ของ application ที่ผิดพลาด

ปัญหาหนึ่งที่พบบ่อยคือ Connection refused ซึ่งมักเกิดจากสองสาเหตุหลัก: PostgreSQL ไม่ได้ bind อยู่ที่ IP สาธารณะ (เช่น bind: "127.0.0.1" แทน "0.0.0.0") firewall หรือ UFW ปิด port ที่ใช้งานอยู่ เช่น port 5432 หรือ port 8443 ที่ใช้ในกรณีของ API gateway วิธีตรวจสอบง่าย ๆ คือใช้คำสั่ง `ss -tlnp | grep 5432` หรือ `netstat -tuln | grep 5432` เพื่อดูว่าพอร์ตเปิดหรือไม่ และตรวจสอบว่า `pg_hba.conf` อนุญาตให้ host นั้นเชื่อมต่อได้หรือไม่

อีกปัญหาที่พบบ่อยคือ Performance ช้า โดยเฉพาะเมื่อ query ที่ใช้ JSONB operator เช่น `->`, `->>`, `?`, `?|` หรือ `@>` ไม่มี index รองรับ ซึ่งทำให้ PostgreSQL ต้อง scan ทั้งตาราง (seq scan) อย่างไม่จำเป็น วิธีตรวจสอบคือใช้คำสั่ง `EXPLAIN (ANALYZE, BUFFERS)` เพื่อดู execution plan ว่ามีการใช้ index หรือไม่ หากไม่ใช้ ให้สร้าง index แบบ GIN หรือ GiST บนคอลัมน์ JSONB ทันที

อีกประเด็นคือ Disk full ซึ่งมักเกิดจาก log file ที่ไม่ถูกรอตัด (rotate) หรือขนาดของ data โตขึ้นเรื่อย ๆ โดยไม่มีการ cleanup วิธีตรวจสอบคือใช้ `df -h` และ `du -sh /var/lib/postgresql/data/*` เพื่อดูว่าโฟลเดอร์ใดใช้พื้นที่มากที่สุด แล้วจัดการโดยตั้งค่า logrotate หรือลบไฟล์ log ที่เก่าออก

ปัญหา	สาเหตุหลัก	วิธีตรวจสอบ	แนวทางแก้ไข
Connection refused	Bind address ผิด / Firewall เปิดไม่พอ	`ss -tlnp \	grep 5432`	แก้ config `postgresql.conf` และเปิด port ใน UFW
Performance ช้า	ไม่มี index บน JSONB	`EXPLAIN (ANALYZE)`	สร้าง GIN index บนคอลัมน์ JSONB
Disk full	Log ไม่ rotate / Data โตไม่หยุด	`df -h`, `du -sh /var/log/*`	ตั้ง logrotate, ลบ data เก่า, เพิ่ม disk
Out of memory (OOM)	Memory leak / Config ไม่เหมาะสม	`dmesg \	grep -i oom`, `free -h`	ปรับ `shared_buffers`, `work_mem`, ตรวจ memory leak

การวินิจฉัยที่ถูกต้องเริ่มจากการเก็บข้อมูลก่อน ไม่ใช่การเดา ทุกครั้งที่เกิดปัญหา ให้เริ่มจากการตรวจสอบ log ของ PostgreSQL (`/var/log/postgresql/*.log`) และ log ของ application ก่อน แล้วจึงค่อยวิเคราะห์ในระดับลึก

การตั้งค่า PostgreSQL ให้เหมาะสมกับสภาพแวดล้อมจริงคือกุญแจสำคัญในการป้องกันปัญหาที่อาจเกิดขึ้นในอนาคตข้างหน้า

หลายครั้งที่ระบบล่มหรือทำงานผิดพลาดไม่ใช่เพราะข้อผิดพลาดของฐานข้อมูล แต่เพราะการตั้งค่าที่ไม่เหมาะสมตั้งแต่ต้น ตัวอย่างเช่น การตั้งค่า `maxconnections` ต่ำเกินไปในระบบที่มีผู้ใช้งานจำนวนมาก หรือการตั้งค่า `sharedbuffers` ต่ำเกินไปในระบบที่ต้องประมวลผลข้อมูลขนาดใหญ่

การตั้งค่าที่ถูกต้องเพื่อป้องกันปัญหาในอนาคตข้างหน้า

การตั้งค่า PostgreSQL ให้เหมาะสมกับสภาพแวดล้อมจริงคือกุญแจสำคัญในการป้องกันปัญหาที่อาจเกิดขึ้นในอนาคตข้างหน้า หลายครั้งที่ระบบล่มหรือทำงานผิดพลาดไม่ใช่เพราะข้อผิดพลาดของฐานข้อมูล แต่เพราะการตั้งค่าที่ไม่เหมาะสมตั้งแต่ต้น ตัวอย่างเช่น การตั้งค่า `maxconnections` ต่ำเกินไปในระบบที่มีผู้ใช้งานจำนวนมาก หรือการตั้งค่า `sharedbuffers` ต่ำเกินไปในระบบที่ต้องประมวลผลข้อมูลขนาดใหญ่

ในสภาพแวดล้อม production ที่ผมใช้งาน ผมมักตั้งค่า `sharedbuffers` ไว้ที่ 25% ของ RAM ทั้งหมด (เช่น 4GB RAM → 1GB) เพื่อให้ PostgreSQL สามารถเก็บข้อมูลที่ถูกอ่านบ่อยไว้ในหน่วยความจำได้มากขึ้น ลดการอ่านจากดิสก์ ซึ่งเป็นสาเหตุหลักของ performance ช้า นอกจากนี้ยังตั้งค่า `workmem` ไว้ที่ 64MB เพื่อให้การจัดเรียง (sorting) และการรวมกลุ่ม (grouping) ทำได้อย่างมีประสิทธิภาพ โดยเฉพาะเมื่อใช้กับ JSONB queries ที่ต้องประมวลผลข้อมูลจำนวนมาก

อีกปัจจัยสำคัญคือการตั้งค่า `effectivecachesize` ให้สะท้อนขนาด cache ทั้งหมดของระบบ (รวม kernel buffer cache) เพื่อให้ optimizer ตัดสินใจได้ถูกต้องว่าควรใช้ index หรือ sequential scan ดีกว่า

สำหรับการจัดการ connection pool ผมใช้ `pgBouncer` ร่วมกับ application เพื่อควบคุมจำนวน connection ที่ส่งไปยัง PostgreSQL ไม่ให้เกิน `max_connections` ที่ตั้งไว้ ซึ่งช่วยป้องกันปัญหา "connection exhaustion" ที่ทำให้ระบบไม่สามารถรับคำขอใหม่ได้

การตั้งค่า log ให้เหมาะสมก็สำคัญไม่แพ้กัน ผมตั้งค่า `loggingcollector = on` และ `logstatement = 'mod'` เพื่อเก็บ log ของคำสั่งที่เปลี่ยนแปลงข้อมูล (INSERT, UPDATE, DELETE) พร้อมกับตั้งค่า `logrotationsize = 100MB` และ `logtruncateon_rotation = on` เพื่อป้องกันไม่ให้ disk เต็ม

ในโลกของระบบ production การเกิดเหตุการณ์ร้ายแรง เช่น downtime ของฐานข้อมูล หรือการสูญเสียข้อมูลจาก disk failure

เป็นเรื่องที่ต้องเตรียมรับมือไว้ล่วงหน้า ไม่ใช่แค่รอแก้เมื่อเกิดขึ้น ระบบ PostgreSQL JSONB ที่ถูกตั้งค่าอย่างเหมาะสมควรสามารถกู้คืนได้ภายในเวลาที่ยอมรับได้ (RTO) และสูญเสียข้อมูลน้อยที่สุด (RPO)

---

การกู้คืนระบบ (Recovery) หลังเกิดเหตุการณ์ร้ายแรง

ในโลกของระบบ production การเกิดเหตุการณ์ร้ายแรง เช่น downtime ของฐานข้อมูล หรือการสูญเสียข้อมูลจาก disk failure เป็นเรื่องที่ต้องเตรียมรับมือไว้ล่วงหน้า ไม่ใช่แค่รอแก้เมื่อเกิดขึ้น ระบบ PostgreSQL JSONB ที่ถูกตั้งค่าอย่างเหมาะสมควรสามารถกู้คืนได้ภายในเวลาที่ยอมรับได้ (RTO) และสูญเสียข้อมูลน้อยที่สุด (RPO)

กลยุทธ์หลักในการกู้คืนคือการมี backup strategy ที่ชัดเจน พร้อมทั้งทดสอบการกู้คืนอย่างสม่ำเสมอ ไม่ใช่แค่เก็บ backup แล้วปล่อยทิ้งไว้ ผมใช้กลยุทธ์แบบ combination ระหว่าง base backup กับ WAL (Write-Ahead Log) สำหรับการกู้คืนย้อนหลังได้ทุกจุด (point-in-time recovery)

ขั้นตอนการกู้คืนเริ่มจากการเตรียม directory สำหรับ data directory ใหม่ เช่น `/var/lib/postgresql/data` แล้วนำ base backup ที่สำรองไว้ก่อนหน้า (เช่น จาก `pg_basebackup`) มาวางไว้ที่นั่น จากนั้นนำ WAL files ที่สำรองไว้ใน S3 หรือ storage ภายนอกมาต่อท้ายเพื่อให้ระบบกู้คืนข้อมูลได้ถึงจุดเวลาที่ต้องการ

ตัวอย่างคำสั่งสำหรับการกู้คืน:

sudo mkdir -p /var/lib/postgresql/data

sudo pgbasebackup -h backup-server -D /var/lib/postgresql/data -U backupuser -P -X stream

echo "restore_command = 'cp /path/to/wal/%f %p'" | sudo tee /var/lib/postgresql/data/recovery.conf

sudo systemctl start postgresql

หลังจากนั้น PostgreSQL จะเริ่มกู้คืนข้อมูลโดยอัตโนมัติจาก WAL files ที่มีอยู่ จนกว่าจะถึงจุดที่ต้องการ ซึ่งอาจใช้เวลาหลายชั่วโมงขึ้นอยู่กับปริมาณ WAL ที่ต้องกู้คืน

การมีระบบ monitoring ที่ดีไม่ใช่แค่เพื่อดูว่าระบบ "ยังทำงานอยู่หรือไม่" แต่คือการคาดการณ์ปัญหาล่วงหน้า ก่อนที่จะส่งผลต่อผู้ใช้งานจริง สำหรับ

PostgreSQL JSONB ที่ใช้ในระบบ production ผมใช้ stack ของ Prometheus + Grafana + Alertmanager เพื่อติดตามสถานะของระบบอย่างต่อเนื่อง

สิ่งสำคัญที่สุดคือต้องทดสอบการกู้คืนอย่างสม่ำเสมอ ไม่ว่าจะเป็นการกู้คืนใน environment แยก หรือการ simulate disaster จริง ๆ เพื่อให้มั่นใจว่าทุกขั้นตอนทำงานได้ตามแผน

---

กลยุทธ์การ monitoring และการแจ้งเตือน (Alerting) ที่มีประสิทธิภาพ

การมีระบบ monitoring ที่ดีไม่ใช่แค่เพื่อดูว่าระบบ "ยังทำงานอยู่หรือไม่" แต่คือการคาดการณ์ปัญหาล่วงหน้า ก่อนที่จะส่งผลต่อผู้ใช้งานจริง สำหรับ PostgreSQL JSONB ที่ใช้ในระบบ production ผมใช้ stack ของ Prometheus + Grafana + Alertmanager เพื่อติดตามสถานะของระบบอย่างต่อเนื่อง

ใน Prometheus ผมตั้งค่า scrape job สำหรับ PostgreSQL โดยใช้ exporter เช่น `postgresexporter` ที่สามารถดึงข้อมูลเกี่ยวกับ connection, transaction, buffer cache, WAL, และ performance ของ query ได้ทันที ตัวอย่าง metric ที่สำคัญ เช่น `pgstatdatabasenumbackends`, `pgstatdatabasexactcommit`, `pgstatusertablesrows`, และ `pgstatbgwriterbufferscheckpoint`

จากนั้นใน Grafana ผมสร้าง dashboard ที่แสดงสถานะของระบบแบบเรียลไทม์ เช่น จำนวน connection ที่ใช้งาน, ระยะเวลาที่ query ใช้เวลานาน, จำนวน transaction ต่อวินาที รวมถึงการวิเคราะห์ trend ของ performance ย้อนหลัง 30 วัน

ส่วนการแจ้งเตือน (alerting) ผมตั้งค่ากฎใน `alerts.yml` เพื่อแจ้งเตือนเมื่อเกิดเหตุการณ์สำคัญ เช่น:

• จำนวน connection ถึง 90% ของ `max_connections`
• ระบบไม่สามารถเชื่อมต่อได้ (service down)
• ความล่าช้าของ query เกิน 5 วินาที
• จำนวน dead tuples เพิ่มขึ้นอย่างรวดเร็ว

ตัวอย่าง alert rule:

• alert: HighConnectionUsage

expr: pgstatdatabasenumbackends / pgsettings.setting * 100 > 90 for: 5m labels: severity: warning annotations: summary: "Connection usage high on {{ $labels.instance }}" description: "Connection usage is at {{ $value }}%, above threshold of 90%"

เมื่อเกิด alert จะส่งแจ้งเตือนผ่าน Slack, Email หรือ SMS ทันที ทำให้ทีมสามารถตอบสนองได้ทันทีก่อนที่ปัญหาจะลุกลาม

การ monitoring ที่ดีไม่ใช่แค่การตั้งค่า alert แล้วปล่อยทิ้งไว้ แต่คือการติดตามผลการแจ้งเตือน วิเคราะห์สาเหตุ และปรับปรุงระบบให้ดีขึ้นเรื่อย ๆ

---

ตัวอย่างการปฏิบัติจริง: แก้ปัญหา JSONB query ช้าในระบบ API

สมมติว่าคุณเป็น DevOps ที่ดูแลระบบ API ที่ใช้ PostgreSQL JSONB สำหรับจัดเก็บข้อมูลผู้ใช้งานแบบ dynamic โดยมีโครงสร้างข้อมูลดังนี้:

CREATE TABLE users ( id SERIAL PRIMARY KEY, profile JSONB NOT NULL, created_at TIMESTAMP DEFAULT NOW() );

และมี query ที่ใช้บ่อย เช่น: SELECT * FROM users WHERE profile ? 'phone';

แต่เมื่อใช้งานจริง พบว่า query ใช้เวลานานกว่า 3 วินาที ทั้งที่มีเพียง 10,000 แถว

ขั้นตอนการวินิจฉัย: ใช้ `EXPLAIN (ANALYZE)` พบว่ามี `Seq Scan` บนตารางทั้งหมด ตรวจสอบว่าไม่มี index บนคอลัมน์ `profile` สร้าง GIN index: CREATE INDEX idxusersprofile_phone ON users USING GIN (profile); รัน query อีกครั้ง พบว่าเวลาลดลงเหลือ 0.002 วินาที

ปัญหานี้เกิดจากความเข้าใจผิดว่า JSONB สามารถ query ได้เร็วโดยไม่ต้อง index แต่ในความเป็นจริง ถ้าไม่มี index ระบบจะต้อง scan ทุกแถว ทำให้ performance ลดลงอย่างมาก

อีกกรณีหนึ่งคือการที่ application ใช้ `->>` ในการดึงค่าจาก JSONB แต่ไม่ได้ใช้ index ที่เหมาะสม ทำให้ query ช้า วิธีแก้คือสร้าง index แบบ GIN บนคอลัมน์ JSONB หรือใช้ `jsonbpathops` index สำหรับ query ที่ใช้ path แบบเฉพาะเจาะจง

การปฏิบัติจริงแสดงให้เห็นว่า แม้จะใช้เทคโนโลยีที่ทันสมัย แต่ความเข้าใจในหลักการพื้นฐานและการตั้งค่าที่เหมาะสมยังคงเป็นหัวใจสำคัญของระบบที่มั่นคง

---

คำถามที่พบบ่อย

Q: ปัญหา "Connection refused" เกิดจากอะไร และแก้ไขอย่างไรใน PostgreSQL JSONB?

การที่เกิดปัญหา "Connection refused" ในการเชื่อมต่อกับ PostgreSQL JSONB มักเกิดจากสาเหตุหลัก 3 ประการ ได้แก่ การตั้งค่า bind address ผิด ปัญหา firewall หรือบริการ PostgreSQL ไม่ได้รันอยู่ ขั้นแรกให้ตรวจสอบไฟล์ `postgresql.conf` ว่ามีบรรทัด `listenaddresses = '0.0.0.0'` หรือไม่ หากตั้งเป็น `localhost` หรือ `127.0.0.1` จะไม่สามารถเชื่อมต่อจากภายนอกได้ ต้องแก้เป็น `0.0.0.0` หรือระบุ IP สาธารณะที่ต้องการให้เปิดรับการเชื่อมต่อ จากนั้นตรวจสอบว่าบริการ PostgreSQL กำลังรันอยู่หรือไม่ โดยใช้คำสั่ง `systemctl status postgresql` หากไม่รัน ให้เริ่มบริการด้วย `systemctl start postgresql` ต่อมา ตรวจสอบ firewall ด้วยคำสั่ง `sudo ufw status verbose` หรือ `sudo firewall-cmd --list-all` แล้วเปิด port ที่ใช้งาน เช่น 5432 หรือ 8443 พร้อมตรวจสอบว่า `pghba.conf` อนุญาตให้ host ที่ต้องการเชื่อมต่อเข้ามาได้หรือไม่ วิธีทดสอบง่าย ๆ คือใช้ `telnet [IP] [port]` หรือ `nc -zv [IP] [port]` หากยังไม่ติดต่อได้ ให้ตรวจสอบ log ของ PostgreSQL ที่ `/var/log/postgresql/*.log` เพื่อดูข้อความผิดพลาดที่ชัดเจนยิ่งขึ้น

Q: ทำไม JSONB query ถึงช้า และจะแก้ไขได้อย่างไร?

JSONB query ช้าในหลายกรณีไม่ได้เกิดจากตัว JSONB เอง แต่เกิดจากขาด index หรือ query ที่ไม่เหมาะสม ตัวอย่างเช่น การใช้ operator `?`, `?|`, `@>` หรือ `->>` โดยไม่มี GIN index บนคอลัมน์ JSONB จะทำให้ PostgreSQL ต้อง scan ทั้งตาราง (sequential scan) ซึ่งส่งผลให้ performance ลดลงอย่างมาก โดยเฉพาะเมื่อข้อมูลมีจำนวนมาก วิธีแก้คือสร้าง GIN index บนคอลัมน์ JSONB เช่น `CREATE INDEX idxtablejsonb ON tablename USING GIN (jsonbcolumn);` นอกจากนี้ ควรหลีกเลี่ยงการใช้ `->>` หรือ `->` ในการ query ที่ต้องกรองข้อมูลจำนวนมาก เพราะไม่สามารถใช้ index ได้เต็มประสิทธิภาพ ควรใช้ operator ที่รองรับ index เช่น `?`, `?|` หรือ `@>` พร้อมตั้งค่า `workmem` และ `sharedbuffers` ให้เหมาะสม เพื่อให้การประมวลผลในหน่วยความจำมีประสิทธิภาพสูงสุด

Q: ควรตั้งค่า memory อย่างไรเพื่อป้องกัน Out of Memory (OOM)?

การตั้งค่า memory ผิดพลาดเป็นสาเหตุหนึ่งที่ทำให้ PostgreSQL ถูก OOM killer ฆ่าทิ้ง วิธีป้องกันคือตั้งค่าพารามิเตอร์ต่าง ๆ อย่างเหมาะสม เช่น `sharedbuffers` ควรตั้งไว้ที่ 25% ของ RAM ทั้งหมด (เช่น 4GB RAM → 1GB), `workmem` ควรตั้งไว้ที่ 64MB ถึง 128MB เพื่อให้การจัดเรียงและ group ทำได้เร็วขึ้น โดยไม่ใช้หน่วยความจำมากเกินไป และ `effectivecachesize` ควรตั้งให้สะท้อนขนาด cache ทั้งหมดของระบบ เพื่อให้ optimizer ตัดสินใจได้ถูกต้อง นอกจากนี้ ควรตั้งค่า `max_connections` ให้เหมาะสม และใช้ connection pool เช่น pgBouncer เพื่อลดจำนวน connection ที่เปิดพร้อมกัน รวมถึงตรวจสอบ log ด้วยคำสั่ง `dmesg | grep -i oom` เพื่อดูว่ามีการ kill process หรือไม่ และปรับ memory limit หรือเพิ่ม RAM หากจำเป็น

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6