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ứ ba và là phần cuối cùng của loạt blog, bao gồm các chỉ số cấp bảng, chỉ mục và hệ thống. Chỉ số cấp độ cụm được che phủ đầu tiên và chỉ số cấp độ cơ sở dữ liệu được che phủ thứ hai.
Mức bảng
Thông thường, dữ liệu trong cơ sở dữ liệu tuân theo quy tắc 80-20. 20% các bảng chứa hầu hết dữ liệu và được truy cập hoặc thay đổi nhiều nhất. Việc đặt giám sát upextra chỉ cho các bảng này có thể cung cấp thông tin chi tiết quan trọng nhưng có khối lượng thấp.
Dưới đây là một số chỉ số cấp bảng đáng xem:
1. Kích thước bảng
Kích thước đĩa thực tế được sử dụng bởi bảng phải được theo dõi. Trong hầu hết các trường hợp, bảng tiếp tục phát triển, vì vậy tốc độ tăng trưởng là điều thú vị hơn.
Thường xảy ra trường hợp tốc độ tăng trưởng thay đổi sau khi triển khai phiên bản mới của ứng dụng hoặc thay đổi cơ bản về lưu lượng / tải / mẫu đầu vào của chính ứng dụng đó. Những thay đổi như vậy phải được điều tra, ít nhất là để xác minh rằng tốc độ mới là bền vững bởi phần cứng được cung cấp.
Hành động:Theo dõi sự gia tăng kích thước của bảng qua mỗi tuần / tháng, điều tra những thay đổi đột ngột.
Cách thực hiện:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Bảng Bloat
Do kiến trúc MVCC của Postgres, các phiên bản cũ hơn của 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).
Số liệu này có thể được theo dõi ở cấp bảng riêng lẻ hoặc tổng hợp trên các bảng đã chọn hoặc ở cấp cơ sở dữ liệu.
Hành động:Liên tục theo dõi độ phồng của bảng 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, VACUUM nếu cần.
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.
3. Quét tuần tự
Khi các truy vấn được thực thi không sử dụng tối ưu các chỉ mục có sẵn hoặc nếu thông tin thống kê được liên kết với bảng quá lỗi thời, thì Postgres có thể phải xem qua từng hàng của bảng. Đây được gọi là quét tuần tự , và không được mong muốn lắm trong trường hợp chung. Điều tốt hơn nên có là quét chỉ mục , nơi các hàng của bảng được truy cập trực tiếp thông qua tra cứu chỉ mục.
PostgreSQL có thể cho bạn biết số lần một bảng được quét tuần tự và cách một chỉ mục được sử dụng bao nhiêu lần. Bạn có thể sử dụng công cụ này để theo dõi số lần quét tuần tự (nếu bạn muốn tránh chúng hoàn toàn) hoặc như một tỷ lệ phần trăm của tổng số lần quét.
Hành động:Liên tục theo dõi seq. số lượng hoặc phần trăm quét, cảnh báo nếu giá trị vượt quá ngưỡng đã đặt.
Cách thực hiện:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Mức chỉ mục
1. Kích thước chỉ mục
Các chỉ mục có thể chiếm dung lượng ổ đĩa đáng kể. Mỗi chỉ mục của bảng về mặt tiềm năng có thể có nhiều dấu vết đĩa như chính bảng đó. Sẽ rất hữu ích khi theo dõi tổng kích thước của các chỉ mục trong cơ sở dữ liệu hoặc chỉ mục của các bảng quan trọng, đặc biệt là trong các triển khai nơi các chỉ mục có thể được tạo thông qua các quy trình tự động.
Các chỉ mục lớn bất hợp lý có thể là do quá tải hoặc chỉ là một chỉ mục được thiết kế tồi. Trong cả hai trường hợp, việc khắc phục nguyên nhân (bằng cách xây dựng lại chỉ mục hoặc bằng cách cấu trúc lại truy vấn / chỉ mục) có thể mang lại thời gian truy vấn nhanh hơn, vì vậy nó sẽ giúp điều chỉnh các chỉ mục lớn.
Hành động:Theo dõi tổng kích thước của các chỉ mục thú vị qua mỗi tuần / tháng, điều tra khi lớn bất hợp lý.
Cách thực hiện:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Chỉ mục Bloat
Các chỉ mục cũng có thể bị phình ra. Có quá nhiều yếu tố, bao gồm khối lượng công việc trên bảng, loại chỉ mục, phiên bản Postgres và hơn thế nữa, quyết định anindex trở nên cồng kềnh như thế nào. Các chỉ mục bị phồng lên có thể làm chậm quá trình chèn và giảm hiệu suất giao diện. Theo dõi số lượng chỉ mục dưới dạng giá trị tuyệt đối (số byte) và 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 chỉ mục phình to theo byte và tỷ lệ phần trăm, cảnh báo các giá trị nếu 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.
3. Tỷ lệ truy cập bộ nhớ đệm
PostgreSQL lưu vào bộ nhớ đệm các vùng được truy cập thường xuyên của chỉ mục (và cả bảng) trong bộ nhớ. Nếu bạn đã điều chỉnh các truy vấn của mình để không chạm vào các bảng ngoại trừ truy xuất các hàng, thì bước tiếp theo là đảm bảo dung lượng lưu trữ trong bộ nhớ cache tối đa cho các chỉ mục quan trọng đang thực sự tăng tốc truy vấn của bạn.
Việc sử dụng bộ nhớ cache của một chỉ mục có thể được đo bằng tỷ lệ truy cập bộ nhớ cache, là tỷ lệ phần trăm khối của chỉ mục được đọc từ bộ nhớ cache trên tổng số khối được đọc.
Hành động:Liên tục theo dõi phần trăm tỷ lệ truy cập bộ nhớ cache, cảnh báo nếu giá trị giảm xuống dưới ngưỡng đã đặt. Điều tra các giá trị thấp cho các chỉ mục quan trọng.
Cách thực hiện:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Cấp hệ thống
Ngoài các chỉ số PostgreSQL, điều quan trọng là phải theo dõi một vài chỉ số của máy hoặc VM mà bạn đang chạy Postgres của mình. Bạn có thể sử dụng bất kỳ giải pháp giám sát phổ biến nào cho việc này hoặc thậm chí tự lấy và theo dõi chúng.
1. Bộ nhớ đã sử dụng
Các hệ thống Linux hiện đại có tính toán bộ nhớ phức tạp. Chúng tôi khuyên bạn nên theo dõi “bộ nhớ đã sử dụng”, là bộ nhớ còn lại sau khi tính cho bộ nhớ được đánh dấu là trống , dưới dạng bộ đệm , dưới dạng đã lưu trong bộ nhớ cache và dưới dạng phiến . Bộ đệm và bộ nhớ cache sẽ chịu áp lực và hầu hết (thường trên 95%) tấm sàn cũng vậy.
Tuy nhiên, bộ nhớ đã sử dụng phải được đo trong một khoảng thời gian dài thích hợp. Nếu bạn có các công việc hàng loạt, báo cáo, ETL, v.v. chạy vào cuối tuần, thì khoảng thời gian sẽ là một tuần. Số liệu thực mà bạn sẽ cần theo dõi là bộ nhớ được sử dụng tối đa trong khoảng thời gian này.
Thông thường, khi kích thước cơ sở dữ liệu của bạn tăng lên, giá trị này có xu hướng tăng lên. Bạn sẽ phải đảm bảo mức sử dụng bộ nhớ tối đa nằm trong giới hạn thoải mái của bộ nhớ khả dụng, chẳng hạn như 60-80%. Bỏ qua điều này sẽ khiến khối lượng công việc của youranalytics / OLAP không thành công do thiếu bộ nhớ.
Hành động:Theo dõi bộ nhớ đã sử dụng tối đa trong một tuần / hai đêm, cảnh báo nếu số lần vượt quá ngưỡng đã đặt, hãy xem xét lại.
Cách thực hiện :
Bộ nhớ đã sử dụng được cung cấp bởi MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , trong đó Mem* các trường từ /proc/meminfo . Để biết thêm thông tin, hãy xem bài viết RedHat này.
2. Trung bình tải
Giá trị trung bình tải đơn giản vẫn là cách dễ nhất và nhanh nhất để ước tính tải trên máy chủ. Điều này đặc biệt đúng đối với các máy chủ Postgres, vì mỗi máy chủ là một quy trình hệ điều hành riêng biệt và việc có nhiều máy chủ trong số chúng ở trạng thái có thể chạy được sẽ làm tăng giá trị trung bình tải.
Đối với một máy chủ Postgres nhất định, mức trung bình tải phải nằm trong phạm vi hợp lý trong một chu kỳ kinh doanh (như một tuần, bao gồm cả các lần chạy công việc hàng loạt).
Hành động:Theo dõi mức trung bình tải tối đa qua mỗi ngày / tuần, điều tra các xu hướng gia tăng.
Cách thực hiện :
Mức trung bình tải 1 phút, 5 phút và 15 phút là 3 trường đầu tiên của dòng đầu tiên trong tệp /proc/loadavg .
3. Dung lượng đĩa trống
Mục cuối cùng trong danh sách của chúng tôi là mục rõ ràng nhất cần theo dõi:dung lượng ổ đĩa trống trong mỗi hệ thống tệp được máy chủ PostgreSQL của bạn sử dụng, bao gồm không gian bảng, thư mục tệp WAL, thư mục sao lưu và tệp nhật ký máy chủ. Trong trường hợp nhiều (hàng trăm triệu) tệp được tạo trong một hệ thống tệp duy nhất, hãy đảm bảo rằng số lượng inode miễn phí cũng được theo dõi. Thiếu inodes cũng được báo cáo do dung lượng ổ đĩa thấp.
Hành động:Liên tục theo dõi dung lượng đĩa trống và việc sử dụng inode trên tất cả các hệ thống cấu hình có liên quan, cảnh báo nếu giá trị giảm xuống dưới ngưỡng đã đặt.
Cách thực hiện :
Không thể truy xuất trực tiếp dung lượng đĩa trống trong hệ thống tệp bằng cách đọc bất kỳ tệp nào trong /proc . Bạn có thể sử dụng stat -f /path/to/mount hoặc thậm chí df để tìm dung lượng đĩa đã sử dụng, miễn phí và dành riêng cho một hệ thống tệp cụ thể, được gắn kết.
Tham khảo nhanh
Dưới đây là danh sách đầy đủ tất cả các số liệu mà chúng ta đã thảo luận cho đến nay trong loạt bài này. Hãy nhớ rằng đây chỉ là bộ số liệu tối thiểu, thiết yếu nhất mà bạn phải theo dõi để phát hiện khi mọi thứ sắp trở nên tồi tệ với việc triển khaiPostgreSQL của bạn.
Cấp độ cụm
- Phạm vi ID giao dịch
- Số lượng phụ trợ
- Vị trí sao chép không hoạt động
- Các khoản phụ trợ đang chờ trên ổ khóa
- Các khoản phụ trợ không hoạt động trong giao dịch
- Trễ sao chép cho các kết nối đang hoạt động
- Trễ sao chép cho các khe sao chép
- Số lượng tệp WAL
- Số lượng tệp WAL sẵn sàng lưu trữ
Cấp cơ sở dữ liệu
- Khách hàng được Kết nối
- Kích thước
- Bảng Bloat trên tất cả các bảng
- Chỉ mục Bloat trên tất cả các chỉ mục
- Giao dịch dài hạn
- Bế tắc
- Chân không cũ nhất
- Phân tích Cũ nhất
Mức bảng
- Kích thước bảng
- Bàn Bloat
- Quét tuần tự
Mức chỉ mục
- Kích thước chỉ mục
- Chỉ mục Bloat
- Tỷ lệ truy cập bộ nhớ cache
Cấp hệ thống
- Bộ nhớ đã sử dụng
- Trung bình tải
- Dung lượng đĩa trống
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.
