sử dụng PostgreSQL 9.1.2
Tôi đang thấy việc sử dụng CPU quá mức và số lượng lớn ghi vào đĩa từ các tác vụ của người quản lý bưu điện. Điều này xảy ra ngay cả khi ứng dụng của tôi không làm gì cả (10 giây chèn mỗi PHÚT). Có một số lượng hợp lý các kết nối mở tuy nhiên.
Tôi đã cố gắng xác định những gì trong ứng dụng của tôi gây ra điều này. Tôi khá mới với postgresql và chưa đi đến đâu. Tôi đã bật một số tùy chọn ghi nhật ký trong tệp cấu hình của mình và xem xét các kết nối trong bảng pg_stat_activity, nhưng tất cả đều không hoạt động. Tuy nhiên, mỗi kết nối tiêu thụ ~ 50% CPU và ghi ~ 15M / s vào đĩa (không đọc gì).
Về cơ bản, tôi đang sử dụng stock postgresql.conf với rất ít điều chỉnh. Tôi đánh giá cao bất kỳ lời khuyên hoặc gợi ý về những gì tôi có thể làm để theo dõi điều này.
Đây là một ví dụ về những gì top / iotop đang hiển thị cho tôi:
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
Cập nhật : Rất nhiều tệp ghi dường như là một số tệp tạm thời (?) Trong thư mục $ PG_DATA / base /. Sự hiểu biết của tôi về cấu trúc tệp ở đây là mỗi bảng về cơ bản được lưu trữ dưới dạng một tệp có tên là OID của bảng. Tuy nhiên, có hàng tấn tệp được đặt tên tnn_nnnnnnnvà chính những tệp này dường như được ghi vào (có lẽ được ghi lại) liên tục. Những tập tin này để làm gì? Có ~ 4700 tệp và tất cả đều có kích thước 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
Cập nhật : Chạy strace trên các quy trình postmaster về cơ bản hiển thị rất nhiều tập tin 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
Cập nhật : Vì vậy, vấn đề này dường như là tất cả để làm với các bảng tạm thời. Chúng tôi đã thay đổi thiết lập của mình để các bảng tạm thời là các bảng 'thông thường' và tất cả hoạt động của đĩa đều biến mất và hiệu suất trở lại như tôi mong đợi. Bây giờ, thay đổi này chỉ là một thử nghiệm nhanh và bẩn: nếu chúng ta thực sự sẽ thay đổi để sử dụng các bảng thông thường, chúng ta có vấn đề với đồng thời và dọn dẹp. Là những cái bàn tạm thời thực sự xấu xa, hay chúng ta đang lạm dụng chúng?
Cập nhật : Một số nền tảng. Tôi đang sử dụng một phần mềm trung gian nhân rộng dựa trên tuyên bố phát triển nội bộ . Nó khá trưởng thành và đã được sử dụng cho một số dự án trong một số năm, nhưng sử dụng MySQL. Chúng tôi chỉ làm việc với PostgreSQL trong một hoặc hai năm qua. Chúng tôi chủ yếu sử dụng các bảng tạm thời như là một phần của cơ chế sao chép. Bất cứ khi nào một kết nối mới được thiết lập, chúng tôi tạo một bảng tạm thời cho mỗi bảng trong cơ sở dữ liệu. Với 10-20 kết nối (tồn tại lâu) và ~ 50 bảng, điều này có thể lên tới rất nhiều bảng tạm thời. Tất cả các bảng tạm thời đã được tạo với:
CREATE TEMPORARY TABLE... ON COMMIT DELETE ROWS;
Các ngữ nghĩa của các bảng tạm thời rất phù hợp với sơ đồ sao chép của chúng tôi và đơn giản hóa rất nhiều mã chúng tôi phải sử dụng cho MySQL, nhưng có vẻ như việc triển khai cũng không công bằng. Từ một chút nghiên cứu tôi đã thực hiện, tôi không nghĩ các bảng tạm thời thực sự có ý nghĩa đối với chức năng mà chúng tôi đang sử dụng chúng cho.
Tôi không phải là chuyên gia nội bộ (thậm chí không gần gũi) về chủ đề này, chỉ là người dùng nó, vì vậy lời giải thích của tôi có thể không chính xác 100%, nhưng tôi nghĩ nó khá gần.