Bạn nên theo dõi những chỉ số nào về việc triển khai PostgreSQL của mình? Loạt bài đăng trên blog này nhằm mục đích cung cấp một tập hợp tối thiểu, bắt đầu của các giao dịch giám sát cần thiết mà bạn nên thực hiện để đảm bảo sức khỏe và sự ổn định của các máy chủPostgres của bạn.
Đây là phần thứ hai của loạt bài blog và bao gồm các tham số cấp cơ sở dữ liệu.
Phần 2:Cấp cơ sở dữ liệu
Trong phần này, chúng tôi xem xét các chỉ số và thông tin cần được theo dõi trước cơ sở dữ liệu quan trọng mà bạn sử dụng.
Hầu hết các truy vấn SQL được liệt kê bên dưới sẽ được chạy khi được kết nối với cơ sở dữ liệu được đề cập.
1. Khách hàng được kết nối
Máy khách được kết nối chiếm hệ điều hành và tài nguyên hệ thống. Postgres có kiến trúc quy trình cho mỗi máy khách và quá nhiều máy khách có thể làm chậm thời gian phản hồi truy vấn của mọi người. Cân nhắc sử dụng PgBouncer orpgpool để giảm số lượng kết nối mà máy chủ Postgres sẽ phải phục vụ.
Theo dõi những thay đổi trong đường cơ sở sau khi cập nhật ứng dụng và tăng cường kết nối do lưu lượng truy cập tăng.
Hành động:Theo dõi số lượng khách hàng được kết nối tối đa qua mỗi ngày / tuần, điều tra các thay đổi trong xu hướng.
Cách thực hiện:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Kích thước
Kích thước đĩa thực tế được sử dụng bởi cơ sở dữ liệu phải được theo dõi. Trong hầu hết các trường hợp, kích thước cơ sở dữ liệu không ngừng tăng lên, do đó, tốc độ tăng trưởng là điều đáng quan tâm hơn. Một lần nữa, hãy cảnh giác với tốc độ tăng trưởng gia tăng sau khi các bản cập nhật ứng dụng mới.
Hành động:Theo dõi sự phát triển về quy mô của cơ sở dữ liệu qua mỗi tuần / tháng, điều tra xu hướng, cung cấp lại.
Cách thực hiện:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Bloat bảng trên tất cả các bảng
Do kiến trúc MVCC của Postgres, các phiên bản cũ hơn của các hàng nằm xung quanh trong các tệp dữ liệu vật lý cho mọi bảng và được gọi là bloat . Thao tác loại bỏ các phiên bản hàng lỗi thời được gọi là chân không . Postgres chạy một quy trình nền có tên là autovacuum , chọn các bảng ứng cử viên (dựa trên các thông số có thể định cấu hình) và xóa chúng cho bạn.
Bloat làm chậm các hoạt động của bảng và lãng phí dung lượng ổ đĩa, đồng thời có thể hết tác dụng với autovacuum. Cần phải giám sát sự cồng kềnh, dưới dạng số byte tuyệt đối cũng như tỷ lệ phần trăm (dữ liệu chết trên tổng dữ liệu). Điều này có thể được thực hiện ở cấp cơ sở dữ liệu với tổng số trên tất cả các bảng, với khả năng đi sâu vào “các bảng cồng kềnh nhất”.
Hành động:Liên tục theo dõi tổng lượng phình ra dưới dạng byte và tỷ lệ phần trăm, cảnh báo nếu giá trị vượt quá ngưỡng đã đặt.
Cách thực hiện:
Sử dụng check_postgres orpgmetrics để nhận ước tính cồng kềnh. Xem thewiki để biết thêm thông tin.
4. Chỉ mục Bloat trên tất cả các chỉ mục
Các chỉ mục cồng kềnh có thể làm chậm quá trình chèn và giảm hiệu suất tra cứu. Theo dõi khối lượng chỉ mục dưới dạng cả giá trị tuyệt đối (số byte) và tỷ lệ phần trăm. Các chỉ mục sẽ phải được xây dựng lại khi chúng trở nên quá cồng kềnh.
Hành động:Liên tục theo dõi tổng lượng phình ra dưới dạng byte và tỷ lệ phần trăm, cảnh báo nếu giá trị vượt quá ngưỡng đã đặt.
Cách thực hiện:
Sử dụng check_postgres orpgmetrics để nhận ước tính cồng kềnh. Xem thewiki để biết thêm thông tin.
5. Giao dịch dài hạn
Các giao dịch mở quá lâu không phải là tin tốt cho PostgreSQL. Các giao dịch trong thời gian dài có thể gây ra việc lưu giữ các tệp WAL, có thể bị khóa và ngăn chặn chân không. Các ứng dụng phải được thiết kế để giữ cho thời lượng giao dịch ở mức thấp nhất có thể.
Một chương trình phụ trợ chạy một giao dịch lâu dài có thể bị hủy bằng pg_cancel_backend () và pg_termina_backend () các chức năng.
Hành động:Liên tục theo dõi số lượng giao dịch đã chạy trong hơn một khoảng thời gian đã đặt, cảnh báo nếu giá trị vượt quá ngưỡng đã đặt.
Cách thực hiện:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Bế tắc
Trong PostgreSQL, phần phụ trợ đặt các ổ khóa trên các hàng và bảng một cách ngầm định khi nó tiếp tục thực thi các truy vấn sửa đổi các hàng. Các truy vấn cũng có thể đặt các khóa rõ ràng (như CHỌN .. ĐỂ CẬP NHẬT ). Cũng giống như trong lập trình đa luồng, các giao dịch hai chiều đặt các khóa, ngầm hoặc rõ ràng, theo thứ tự đối lập có thể dẫn đến bế tắc.
PostgreSQL sẽ phát hiện các bế tắc và sẽ khôi phục một trong các giao dịch đã được giải quyết (Tất cả các khóa được giữ bởi một giao dịch sẽ được giải phóng khi nó được cam kết hoặc cuộn lại). Thông tin chi tiết sẽ được ghi vào đích ghi nhật ký PostgreSQL.
Các ứng dụng nên được thiết kế để tránh khả năng bị bế tắc. Họ cũng chọn thử lại một giao dịch trong trường hợp bế tắc.
Hành động:Theo dõi số lần bế tắc qua từng ngày / tuần, thiết kế lại ứng dụng để giảm số lượng, điều tra các thay đổi.
Cách thực hiện:
Các lần xuất hiện bế tắc, cùng với thông tin bổ sung, được ghi vào tệp nhật kýPostgreSQL. Sử dụng pgmetrics, pgbadgeror các công cụ xử lý nhật ký dành riêng cho PostgreSQL khác để trích xuất thông tin này.
7. Máy hút cũ nhất
Hút bụi bàn thường xuyên, bằng máy hút bụi tự động hoặc với các công việc đã lên lịch, hoặc bằng tay là điều bắt buộc để giữ cho các thao tác trên bàn diễn ra nhanh chóng. Tuy nhiên, các máy hút chân không có thể bị lỗi vì các lý do khác nhau, bao gồm các giao dịch đang hoạt động lâu, các bản sao không hoạt động, v.v.
Vì việc hút bụi các bảng thường xuyên là khá quan trọng trong thế giới Postgres, tốt nhất bạn nên thường xuyên kiểm tra xem tất cả các bảng đã được hút bụi ít nhất một lần trong khoảng thời gian đã định hay chưa.
Và mặc dù chúng có xu hướng bị khuất và mất trí, các bảng danh mục hệ thống cũng nên được hút bụi.
Hành động:Liên tục kiểm tra xem có bàn nào chưa được hút bụi trong số giờ / ngày đã đặt trước hay không, thông báo nếu có.
Cách thực hiện:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Phân tích cũ nhất
Để thực hiện các truy vấn SELECT của bạn, công cụ lập kế hoạch truy vấn chuẩn bị một kế hoạch thực hiện mô tả chỉ mục và bảng nào phải được đọc và cách thức. Thông tin thống kê như vậy về dữ liệu trong bảng được phân tích thu thập và duy trì các hoạt động. Các bảng có thống kê cập nhật dẫn đến truy vấn nhanh hơn và I / O không cần thiết.
Quy trình autovacuum được đề cập ở trên thường cũng chạy ANALYZE trên bàn, nó trống để giữ cho thông tin này được cập nhật. Tuy nhiên, chỉ điều này có thể không cung cấp đủ phạm vi phân tích cho các bảng của bạn. Bạn sẽ muốn hỗ trợ bằng cách chạy ANALYZE như các công việc đã lên lịch hoặc sau các lần xử lý bảng quan trọng.
Vì lợi ích của hiệu suất truy vấn, tốt nhất là liên tục kiểm tra các bảng trong khi các bảng đã được phân tích ít nhất một lần trong một khoảng thời gian nhất định.
Hành động:Liên tục kiểm tra xem có bảng nào chưa được phân tích trong số giờ / ngày đã đặt trước hay không, cảnh báo nếu có.
Cách thực hiện:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Thu thập các chỉ số này
Các phần trên cung cấp các câu lệnh SQL để trích xuất các số liệu cần thiết từ máy chủ Postgres đang chạy. Nếu bạn không muốn tự mình viết kịch bản, hãy xem pgmetrics của công cụ mã nguồn mở. Nó có thể thu thập các chỉ số ở trên, v.v. và báo cáo chúng ở định dạng văn bản và JSON.
Bạn có thể gửi trực tiếp các báo cáo pgmetrics tới dịch vụ thương mại của chúng tôi, pgDash, nơi lưu trữ và xử lý các báo cáo này để hiển thị đồ thị và thực hiện cảnh báo.
Tiếp theo
Phần tiếp theo của loạt bài này sẽ đề cập đến các chỉ số cấp bảng, cấp chỉ mục và cấp hệ thống. Hãy theo dõi!
