Một hoạt động chân không / autovacuum sẽ mất bao nhiêu thời gian?

Tôi quản lý một cơ sở dữ liệu lớn (vài trăm hợp đồng biểu diễn) có chứa các bảng với nhiều vai trò khác nhau, một số trong số chúng chứa hàng triệu bản ghi. Một số bảng chỉ nhận được số lượng lớn chèn và xóa, một số bảng khác chèn và số lượng cập nhật lớn.

Cơ sở dữ liệu chạy trên PostgreSQL 8.4 trên hệ thống Debian 6.0 amd64 với 16 gigabyte RAM.

Câu hỏi đôi khi là quá trình tự động trên bàn, mất một thời gian rất dài (ngày) để hoàn thành. Tôi muốn có thể nói đại khái là một lệnh chân không cụ thể sẽ mất bao nhiêu thời gian, để có thể quyết định có nên hủy nó hay không. Ngoài ra nếu có một chỉ báo tiến độ cho các hoạt động chân không postgres, nó sẽ thực sự hữu ích.

Biên tập:

Tôi không tìm kiếm một giải pháp chống đạn. Chỉ cần một gợi ý sơ bộ về số lượng bộ dữ liệu chết hoặc byte I / O cần thiết là đủ để quyết định. Thật sự rất khó chịu khi không có manh mối khi nào VACUUMsẽ kết thúc, dù thế nào đi nữa.

Tôi đã thấy rằng pg_catalog.pg_stat_all_tablescó một cột cho số bộ dữ liệu chết. Vì vậy, có thể có một ước tính, ngay cả khi nó có nghĩa là người ta phải ANALYZEbàn trước đó. Mặt khác, autovacuum_vacuum_thresholdvà autovacuum_vacuum_scale_factorcác thiết lập một mình chứng minh rằng chính postgres biết điều gì đó về lượng thay đổi trên các bảng và có lẽ cũng đặt nó vào tay DBA.

Tôi không chắc chắn nên chạy truy vấn nào, bởi vì khi tôi chạy VACUUM VERBOSE, tôi thấy rằng không chỉ các bảng mà cả các chỉ mục trên chúng cũng đang được xử lý.

Trên PostgreSQL của tôi (8.3) tôi sử dụng thủ thuật này:

1. Tôi nhận được kích thước đĩa của bảng bằng cách sử dụng pg_total_relation_size()- bao gồm các chỉ mục và kích thước TOAST, đây là VACUUMquy trình. Điều này cho tôi ý tưởng về việc VACUUMphải đọc bao nhiêu byte .
2. Tôi chạy VACUUMtrên bàn.
3. Tôi tìm ra pidcác VACUUMquá trình (trong pg_catalog.pg_stat_activity).
4. Trong Linux shell tôi chạy while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(nơi 123là pid) - điều này cho tôi thấy các byte được đọc bởi quá trình từ đĩa cho đến nay.

Điều này cho tôi ý tưởng sơ bộ về số lượng byte được xử lý (đọc) mỗi phút bởi VACUUM. Tôi đoán rằng VACUUMphải đọc qua toàn bộ bảng (bao gồm các chỉ mục và TOAST), có kích thước đĩa tôi biết từ bước 1.

Tôi cho rằng bảng đủ lớn để phần lớn các trang của nó phải được đọc từ đĩa (chúng không có trong bộ nhớ chia sẻ của Postgres), vì vậy read_bytestrường này đủ tốt để được sử dụng làm bộ đếm tiến trình.

Mỗi lần tôi làm điều này, tổng số byte được đọc bởi quá trình không quá 5% so với tổng kích thước quan hệ, vì vậy tôi đoán cách tiếp cận này có thể đủ tốt cho Bạn.

Điều này rất khó xác định. Bạn có thể điều chỉnh quá trình tự động để trở nên dễ chịu hơn hoặc nhẹ nhàng hơn. Nhưng khi được đặt ở mức nhẹ và bị tụt lại phía sau và tải I / O cơ sở quá cao, có thể xảy ra rằng nó không bao giờ đạt đến trạng thái chân không thích hợp - sau đó bạn thấy quá trình chạy và chạy. Hơn nữa, các phiên bản PostreQuery sau này có nhiều khả năng tự động cải tiến hơn, chỉ riêng điều này có thể đủ để chuyển sang một trong số chúng (tốt nhất là 9,2 như phiên bản gần đây nhất).

Thanh tiến trình nghe có vẻ là một ý tưởng tốt nhưng tôi tưởng tượng nó không dễ thực hiện một cách có ý nghĩa. Khi bạn có tải liên tục trên các bảng của mình, hoàn toàn có thể tiến trình rõ ràng đang đi lùi (ý tôi là số lượng hàng chết / phần trăm tăng thay vì giảm) - vậy bạn rút ra kết luận gì?

Trong sản xuất của chúng tôi, một trong những bảng lớn nhất có nhật ký này:

pages: 0 removed, 1801722 remain
tuples: 238912 removed, 42582083 remain, 1396 are dead but not yet removable
buffer usage: 9477565 hits, 3834218 misses, 2220101 dirtied
avg read rate: 2.976 MB/s, avg write rate: 1.723 MB/s
system usage: CPU 68.47s/177.49u sec elapsed 10065.08 sec

Đây là mức tiêu thụ tài nguyên tồi tệ nhất, tất cả các bảng khác chỉ mất chưa đến 2 giây.

Để xem các loại nhật ký này, bạn nên thực hiện điều này:

alter system set log_autovacuum_min_duration TO 5; 

(trong 5 ms), tải lại tệp cấu hình.

Tôi thấy bài đăng này và bài đăng này hữu ích, nhưng giống như những người khác đã đề cập, có thể khó tính được tiến trình chung của chân không, vì quá trình này bao gồm một vài thao tác riêng biệt.

Tôi sử dụng truy vấn này để theo dõi tiến trình quét bảng chân không, dường như là phần lớn công việc:

SELECT heap_blks_scanned/cast(heap_blks_total as numeric)*100 as heap_blks_percent, progress.*, activity.query
FROM pg_stat_progress_vacuum AS progress
INNER JOIN pg_stat_activity AS activity ON activity.pid = progress.pid;

Tuy nhiên, điều này sẽ không bao gồm quét chỉ mục, xảy ra sau đó và có thể mất nhiều thời gian, nếu không lâu hơn, nếu bạn có rất nhiều chỉ mục. Thật không may, tôi không thể tìm thấy cách nào để theo dõi quá trình quét / hút bụi.