ใช้ PostgreSQL 9.1.2
ฉันเห็นการใช้งาน CPU มากเกินไปและมีการเขียนไปยังดิสก์จำนวนมากจากงานไปรษณีย์ สิ่งนี้เกิดขึ้นแม้ในขณะที่แอปพลิเคชันของฉันไม่ได้ทำอะไรเลย (เม็ดมีด 10 เม็ดต่อนาที) มีจำนวนการเชื่อมต่อที่เปิดอยู่อย่างไรก็ตาม
ฉันพยายามระบุว่าอะไรในแอปพลิเคชันของฉันทำให้เกิดสิ่งนี้ ฉันค่อนข้างใหม่กับ postgresql และไม่ได้ไปไกลขนาดนี้ ฉันได้เปิดใช้งานตัวเลือกการบันทึกบางอย่างในไฟล์กำหนดค่าของฉันและดูการเชื่อมต่อในตาราง pg_stat_activity แต่ทั้งหมดไม่ได้ใช้งาน การเชื่อมต่อแต่ละครั้งใช้ CPU ประมาณ 50% และกำลังเขียน ~ 15M / s ไปยังดิสก์ (ไม่ต้องอ่านอะไรเลย)
ฉันใช้พื้น postgresql.conf โดยทั่วไปแล้วมีการปรับแต่งเล็กน้อย ฉันขอขอบคุณคำแนะนำหรือคำแนะนำเกี่ยวกับสิ่งที่ฉันสามารถทำได้เพื่อติดตามเรื่องนี้
นี่คือตัวอย่างของสิ่งที่แสดงให้ฉันเห็น:
Cpu(s): 18.9%us, 14.4%sy, 0.0%ni, 53.4%id, 11.8%wa, 0.0%hi, 1.5%si, 0.0%st
Mem: 32865916k total, 7263720k used, 25602196k free, 575608k buffers
Swap: 16777208k total, 0k used, 16777208k free, 4464212k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17057 postgres 20 0 236m 33m 13m R 45.0 0.1 73:48.78 postmaster
17188 postgres 20 0 219m 15m 11m R 42.3 0.0 61:45.57 postmaster
17963 postgres 20 0 219m 16m 11m R 42.3 0.1 27:15.01 postmaster
17084 postgres 20 0 219m 15m 11m S 41.7 0.0 63:13.64 postmaster
17964 postgres 20 0 219m 17m 12m R 41.7 0.1 27:23.28 postmaster
18688 postgres 20 0 219m 15m 11m R 41.3 0.0 63:46.81 postmaster
17088 postgres 20 0 226m 24m 12m R 41.0 0.1 64:39.63 postmaster
24767 postgres 20 0 219m 17m 12m R 41.0 0.1 24:39.24 postmaster
18660 postgres 20 0 219m 14m 9.9m S 40.7 0.0 60:51.52 postmaster
18664 postgres 20 0 218m 15m 11m S 40.7 0.0 61:39.61 postmaster
17962 postgres 20 0 222m 19m 11m S 40.3 0.1 11:48.79 postmaster
18671 postgres 20 0 219m 14m 9m S 39.4 0.0 60:53.21 postmaster
26168 postgres 20 0 219m 15m 10m S 38.4 0.0 59:04.55 postmaster
Total DISK READ: 0.00 B/s | Total DISK WRITE: 195.97 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
17962 be/4 postgres 0.00 B/s 14.83 M/s 0.00 % 0.25 % postgres: aggw aggw [local] idle
17084 be/4 postgres 0.00 B/s 15.53 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17963 be/4 postgres 0.00 B/s 15.00 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17188 be/4 postgres 0.00 B/s 14.80 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
17964 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.24 % postgres: aggw aggw [local] idle
18664 be/4 postgres 0.00 B/s 15.13 M/s 0.00 % 0.23 % postgres: aggw aggw [local] idle
17088 be/4 postgres 0.00 B/s 14.71 M/s 0.00 % 0.13 % postgres: aggw aggw [local] idle
18688 be/4 postgres 0.00 B/s 14.72 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
24767 be/4 postgres 0.00 B/s 14.93 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18671 be/4 postgres 0.00 B/s 16.14 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
17057 be/4 postgres 0.00 B/s 13.58 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
26168 be/4 postgres 0.00 B/s 15.50 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
18660 be/4 postgres 0.00 B/s 15.85 M/s 0.00 % 0.00 % postgres: aggw aggw [local] idle
อัปเดต : มีการเขียนไฟล์จำนวนมากดูเหมือนว่าจะเป็นไฟล์ชั่วคราว (?) บางไฟล์ในไดเรกทอรี $ PG_DATA / base / ความเข้าใจของฉันเกี่ยวกับโครงสร้างไฟล์ที่นี่คือแต่ละตารางจะถูกจัดเก็บเป็นไฟล์ที่มีชื่อเป็น OID ของตาราง อย่างไรก็ตามมีชื่อไฟล์tnn_nnnnnnnมากมายและเป็นไฟล์เหล่านี้ที่ดูเหมือนว่าจะเขียน (อาจเขียนทับ) อย่างต่อเนื่อง ไฟล์เหล่านี้มีไว้เพื่ออะไร? มีไฟล์ ~ 4700 และมีขนาด 8K:
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t12_1430975
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t16_1432736
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439066
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436243
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t24_1436210
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t19_1393372
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t28_1439051
-rw-------. 1 postgres postgres 8192 Jul 3 23:08 t8_1430334
อัปเดต : การเรียกใช้ strace บนกระบวนการโพสต์มาสเตอร์โดยทั่วไปจะแสดงไฟล์ I / O เป็นจำนวนมาก:
open("base/16388/t24_1435947_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
ftruncate(9, 0) = 0
lseek(9, 0, SEEK_END) = 0
open("base/16388/t24_1435941", O_RDWR) = 18
lseek(18, 0, SEEK_END) = 0
write(9, "\0\0\0\0\0\0\0\0\1\0\0\0000\0\360\37\360\37\4 \0\0\0\0b1\5\0\2\0\0\0"..., 8192) = 8192
lseek(18, 0, SEEK_END) = 0
close(9) = 0
open("base/16388/t24_1435947", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 8192
close(18) = 0
close(9) = 0
open("base/16388/t24_1435944_fsm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944_vm", O_RDWR) = -1 ENOENT (No such file or directory)
open("base/16388/t24_1435944", O_RDWR) = 9
lseek(9, 0, SEEK_END) = 0
close(9) = 0
ปรับปรุง : ดังนั้นปัญหานี้ดูเหมือนจะเป็นทุกอย่างที่จะทำกับตารางชั่วคราว เราเปลี่ยนการตั้งค่าเพื่อให้ตารางชั่วคราวเป็นตาราง 'ปกติ' และกิจกรรมบนดิสก์ทั้งหมดหายไปและประสิทธิภาพกลับไปสู่ตำแหน่งที่ฉันคาดไว้ ตอนนี้การเปลี่ยนแปลงนี้เป็นเพียงการทดสอบที่รวดเร็วและสกปรก: หากเราจะเปลี่ยนไปใช้ตารางปกติเรามีปัญหาเกี่ยวกับการทำงานพร้อมกันและการล้างข้อมูล ตารางชั่วคราวนั้นชั่วร้ายจริง ๆ หรือว่าเราใช้ในทางที่ผิด
ปรับปรุง : พื้นหลังบางอย่างเพิ่มเติม ฉันทำใช้ในบ้านพัฒนาคำสั่งตามตัวกลางการจำลองแบบ มันค่อนข้างเป็นผู้ใหญ่และมีการใช้งานในหลายโครงการมานานหลายปี แต่ใช้ MySQL เราได้ทำงานกับ PostgreSQL ในช่วงสองสามปีที่ผ่านมาเท่านั้น เราใช้ตารางชั่วคราวเป็นส่วนหนึ่งของกลไกการจำลองแบบ เมื่อใดก็ตามที่มีการเชื่อมต่อใหม่เราจะสร้างตารางชั่วคราวสำหรับแต่ละตารางในฐานข้อมูล ด้วยการเชื่อมต่อ 10-20 รายการ (อายุการใช้งานยาวนาน) และ ~ 50 ตารางสิ่งนี้สามารถรวมกับตารางชั่วคราวจำนวนมาก สร้างตารางชั่วคราวทั้งหมดด้วย:
CREATE TEMPORARY TABLE... ON COMMIT DELETE ROWS;
ซีแมนทิกส์ของตารางชั่วคราวนั้นเข้ากันได้ดีกับชุดการจำลองแบบของเราและทำให้รหัสจำนวนมากง่ายขึ้นที่เราต้องใช้กับ MySQL แต่ดูเหมือนว่าการนำไปใช้นั้นไม่ยุติธรรมเช่นกัน จากการค้นคว้าเล็กน้อยที่ฉันทำฉันไม่คิดว่าตารางชั่วคราวมีความหมายสำหรับฟังก์ชันที่เราใช้
ฉันไม่ใช่ผู้เชี่ยวชาญในบ้าน (ไม่แม้แต่ปิด) ในหัวข้อนี้เพียงแค่เป็นผู้ใช้ดังนั้นคำอธิบายของฉันอาจไม่แม่นยำ 100% แต่ฉันคิดว่ามันค่อนข้างใกล้เคียง