PostgreSQL pg_stat_activity hiển thị CAMIT

Gần đây chúng tôi đã thay thế máy chủ cơ sở dữ liệu của mình bằng một máy được nâng cấp với CPU 4 nhân bốn nhân và ram 32Gb. Chúng tôi cũng tái sử dụng hộp cũ của chúng tôi để phục vụ như một nô lệ với sao chép phát trực tuyến. Cả hai hộp đều đang chạy CentOS 6.3 và PostgreQuery 9.2. Postgres là thứ duy nhất chạy trên mỗi hộp.

Cấu hình này đã được sử dụng khoảng một tháng hoặc lâu hơn, khi đột nhiên chúng tôi bắt đầu gặp phải một số vấn đề khi lưu lượng truy cập bắt đầu tăng mạnh. Những gì chúng ta đã bắt đầu thấy là tải CPU rất cao vào các thời điểm (trên cùng cho thấy mức trung bình tải là 270) và khi chúng ta có thể nhìn vào pg_stat_activitychúng ta sẽ thấy hầu hết các kết nối của chúng ta đang ở COMMITtrạng thái. Khi còn lại một mình, điều này cuối cùng sẽ kết thúc và hệ thống sẽ trở nên phản ứng nhanh với các kết nối đang trở thành IDLE. Chúng tôi đã thử vô hiệu hóa sao chép để xem đó có phải là vấn đề không, nhưng vấn đề vẫn còn tồn tại.

Chúng tôi đã cố gắng chẩn đoán những gì đang xảy ra, và có một chút mất mát. Đầu ra từ việc chạy perfcho thấy một cái gì đó tương tự như bên dưới, và tôi không biết những gì 0x347ba9đại diện.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Không có truy vấn nào được thực hiện bởi ứng dụng đặc biệt phức tạp, với các kế hoạch giải thích mất tối đa 1 giây (hầu hết nhanh hơn nhiều). Ngoài ra, trong khi điều này xảy ra khi lưu lượng truy cập bắt đầu tăng, chúng tôi không nói về tải lưu lượng lớn (Máy cũ được sử dụng để có thể xử lý khá dễ dàng).

Tại thời điểm này tôi hơi bối rối về những gì cần thử tiếp theo. Bất kỳ trợ giúp hoặc đề xuất sẽ được đánh giá cao. Nếu có bất kỳ thông tin bổ sung nào có thể giúp đỡ, chỉ cần hỏi và tôi có thể sửa đổi câu hỏi.

Cấu hình đĩa:

Bộ điều khiển RAID Perc 6i
Ổ đĩa 5 x 146GB 15K
Được cấu hình là 2x146GB RAID-1 cho WAL và 3x146GB RAID-5 cho Hệ thống và Dữ liệu

Cập nhật:

Dưới đây là đầu ra VMStat khi hệ thống hoạt động bình thường và khi CPU khởi động. Khi có một vấn đề, các ngắt dường như tăng vọt.

Trong quá trình hoạt động bình thường:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Khi mức sử dụng CPU cao:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
nguồn

Hộp mới có những loại đĩa nào? Điều này xảy ra trên cả hai nút hoặc chỉ một trong số họ?

— Trygve Laugstøl

@trygvis - Tôi đã cập nhật câu hỏi với thông số kỹ thuật đĩa. Vấn đề đang xảy ra trên nút Master. Tôi đã không cố gắng quảng bá Slave và lưu lượng truy cập trực tiếp đến nó, vì vậy tôi không chắc liệu đó có phải là vấn đề ở đó trong cùng hoàn cảnh hay không. Là một nô lệ, máy dường như không gặp phải bất kỳ vấn đề nào.

— jcern

Cân nhắc sử dụng perfcông cụ này để thực hiện một số lược tả toàn hệ thống và một số lược tả PostgreSQL. Xem nơi sử dụng CPU đang xảy ra. BTW, định dạng thứ 2 của bạn vmstatbị vô hiệu hóa và các cột của người thứ 1 bị sai lệch nên rất khó đọc. Kiểm tra để xem liệu thêm một commit_delayđiều cải thiện. Kiểm tra xem bộ điều khiển RAID của bạn có bộ đệm ghi lại được hỗ trợ bằng pin không và nếu không, hãy lấy một cái. Là dành nhiều thời gian trong iowait? Đây có vẻ là việc sử dụng CPU trong một số báo cáo, nhưng thực sự không phải vậy.

— Craig Ringer

@CraigRinger bộ điều khiển có bộ đệm ghi được hỗ trợ bằng pin và hiện đang được bật. Chờ đợi từ iostat vẫn ở các chữ số đôi đến thấp. Chúng tôi sẽ tiếp tục thử một số hồ sơ với perf. Tôi cũng đã sửa định dạng của VMStat thứ hai, cảm ơn bạn đã chỉ ra điều đó.

— jcern

Sau khi chẩn đoán thêm và một số Googling, chúng tôi đã xem qua bài viết này mô tả nhiều triệu chứng tương tự mà chúng tôi đang gặp phải. Nguyên nhân sâu xa của vấn đề của họ (và từ những gì chúng ta có thể nói, chúng ta cũng vậy) có liên quan đến việc Transparent Huge Pagesthực hiện.

Sau khi vô hiệu hóa Transparent Huge Pagesvới lệnh này:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

Vấn đề dường như đã được giải quyết. Chúng tôi đã chạy dưới một khối lượng công việc tăng lên trong hai tuần qua và vấn đề không xuất hiện trở lại. Bối cảnh và các ngắt của hệ thống luôn bằng 1/10 so với những gì chúng đã có và thời gian hệ thống trung bình cũng giảm theo.

Không chắc chắn nếu đó là giải pháp cho tất cả mọi người, nhưng tôi đăng nó ở đây như một nguyên nhân có thể trong trường hợp nó có thể giúp bất kỳ ai khác giải quyết vấn đề tương tự.

— jcern
nguồn