VACUUM ANALYZE thông thường vẫn được khuyến nghị dưới 9.1?


38

Tôi đang sử dụng PostgreSQL 9.1 trên Ubuntu. Được lên lịch VACUUM ANALYZEvẫn được đề xuất, hoặc tự động đủ để chăm sóc tất cả các nhu cầu?

Nếu câu trả lời là "nó phụ thuộc", thì:

  • Tôi có một cơ sở dữ liệu lớn (kích thước kết xuất nén 30 GiB, thư mục dữ liệu 200 GiB)
  • Tôi thực hiện ETL vào cơ sở dữ liệu, nhập gần 3 triệu hàng mỗi tuần
  • Các bảng có thay đổi thường xuyên nhất đều được kế thừa từ bảng chính, không có dữ liệu trong bảng chính (dữ liệu được phân vùng theo tuần)
  • Tôi tạo ra các danh sách hàng giờ và từ đó, báo cáo hàng ngày, hàng tuần và hàng tháng

Tôi đang hỏi bởi vì lịch trình VACUUM ANALYZEđang ảnh hưởng đến báo cáo của tôi. Nó chạy được hơn 5 giờ và tôi đã phải giết nó hai lần trong tuần này, vì nó ảnh hưởng đến việc nhập cơ sở dữ liệu thường xuyên. check_postgreskhông báo cáo bất kỳ sự phình to đáng kể nào trên cơ sở dữ liệu, vì vậy đó không thực sự là một vấn đề.

Từ các tài liệu, autovacuum cũng sẽ đảm nhiệm việc bọc ID giao dịch. Câu hỏi đặt ra: tôi vẫn cần a VACUUM ANALYZE?


Chà, tôi sẽ nói 'không', nhưng xây dựng câu trả lời này (ví dụ, thiết lập các tham số tự động) sẽ cần một số thử nghiệm trên bản sao DB.
dezso

Câu trả lời:


32

VACUUM chỉ cần thiết trên các hàng được cập nhật hoặc bị xóa trong các bảng không tạm thời. Rõ ràng là bạn đang thực hiện nhiều CHỨNG MINH nhưng không rõ ràng từ mô tả rằng bạn cũng đang thực hiện nhiều CẬP NHẬT hoặc XÓA.

Các hoạt động này có thể được theo dõi với pg_stat_all_tableschế độ xem, cụ thể là n_tup_updn_tup_delcác cột. Ngoài ra, thậm chí nhiều hơn, có một n_dead_tupcột cho biết, trên mỗi bảng, có bao nhiêu hàng cần được hút bụi. (xem Giám sát số liệu thống kê trong tài liệu về các chức năng và chế độ xem liên quan đến thu thập số liệu thống kê).

Một chiến lược khả thi trong trường hợp của bạn sẽ là triệt tiêu VACUUM theo lịch trình, theo dõi quan điểm này và kiểm tra xem bảng n_dead_tupnào sẽ tăng đáng kể. Sau đó, chỉ áp dụng VACUUM tích cực cho các bảng này. Đây sẽ là một chiến thắng nếu có các bảng lớn mà các hàng không bao giờ bị xóa cũng như không được cập nhật và VACUUM tích cực chỉ thực sự cần thiết trên các bảng nhỏ hơn.

Nhưng hãy tiếp tục chạy ANALYZE để trình tối ưu hóa luôn có số liệu thống kê mới.


4
Autovacuum cũng chăm sóc ANALYZE. Vẫn là một ý tưởng tốt để chạy PHÂN TÍCH thủ công giữa một CẬP NHẬT / XÁC NHẬN / XÓA hàng loạt và ngay lập tức theo các truy vấn lớn. +1 cho lời khuyên tốt, mặc dù.
Erwin Brandstetter

Cảm ơn con trỏ đến n_dead_tup và bạn bè. Tôi có các bảng cuộn lên mà tôi thường xuyên (hàng giờ) phá hủy và tạo lại hàng ngàn hàng. Tôi sẽ kiểm tra các giá trị và lên lịch phù hợp. Câu trả lời luôn là "theo dõi, suy nghĩ, hành động" bằng mọi cách :)
François Beausoleil

25

Tôi không thấy gì trong câu hỏi của bạn mà autovacuumkhông quan tâm. Nó phần lớn phụ thuộc vào mô hình hoạt động viết của bạn . Bạn đề cập đến 3 triệu hàng mới mỗi tuần, nhưng INSERT(hoặc COPY) thường không tạo bảng và chỉ mục phình to. ( autovacuumchỉ phải chăm sóc số liệu thống kê cột , bản đồ hiển thị và một số công việc nhỏ). UPDATEDELETElà nguyên nhân chính của sự phình to của bảng và chỉ mục, đặc biệt là khi nhắm mục tiêu các hàng ngẫu nhiên. Tôi không thấy bất kỳ điều đó trong câu hỏi của bạn.

autovacuumđã đi một chặng đường dài và đang làm một công việc tuyệt vời trong Postgres 9.1 trở lên. Tôi sẽ có một cái nhìn vào các autovacuumcài đặt . Nếu việc hút bụi có xu hướng cản trở tải công việc của bạn, hãy xem "Độ trễ chân không dựa trên chi phí" . Hút bụi bằng tay nên là ngoại lệ hiếm.

Nếu bạn có nhiều UPDATEs ngẫu nhiên , bạn có thể muốn đặt FILLFACTORmức thấp hơn 100, để cho phép cập nhật NÓNG ngay lập tức và giảm nhu cầu VACUUM. Thêm thông tin cập nhật HOT:

Cũng lưu ý rằng các bảng tạm thời cần thủ công VACUUM& ANALYZE. Tôi trích dẫn hướng dẫn trênCREATE TABLE :

Trình nền tự động không thể truy cập và do đó không thể hút bụi hoặc phân tích các bảng tạm thời. Vì lý do này, các hoạt động phân tích và chân không thích hợp nên được thực hiện thông qua các lệnh SQL phiên. Ví dụ: nếu một bảng tạm thời sẽ được sử dụng trong các truy vấn phức tạp, thì nên chạy ANALYZEtrên bảng tạm thời sau khi nó được điền.


6

Mặc dù tôi đồng ý rằng sử dụng các tính năng tự động là tốt nhất thay vì chạy rộng cơ sở dữ liệu, nhưng trong hầu hết các trường hợp, mỗi lần điều chỉnh bảng là cần thiết.

Tôi không hoàn toàn đồng ý với sự lựa chọn thiết kế của postgres để liên kết chân không và phân tích, tôi đã thấy một số trường hợp cơ sở dữ liệu thực hiện nhiều thao tác chèn / cập nhật nhưng rất ít xóa không bao giờ được phân tích và bắt đầu thực hiện kém.

Giải pháp là đi vào các bảng được sử dụng nhiều và phải chịu các truy vấn lớn và đặt cài đặt phân tích tự động cho các bảng đó xuống một cái gì đó để chúng được phân tích một lần hoặc mỗi ngày.

Bạn có thể nhận được các cài đặt trên mỗi bảng trong gui trên tab chân không tự động và bạn sẽ thấy các cài đặt phân tích ở đó bạn có thể đặt độc lập với chân không.

Các cài đặt kết thúc trong bảng reloptions và có thể được nhìn thấy bằng truy vấn

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

và một giá trị mẫu có phân tích áp lực có thể là

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Để xem lần cuối cùng bảng của bạn có truy vấn được phân tích tự động

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;

2
Nếu bạn không ANALYZE, làm thế nào PostgreSQL sẽ biết rằng các số liệu thống kê đã thay đổi? Và làm thế nào bạn có thể xác định rằng nó là ANALYZEmột mất nhiều thời gian? Đồng thời, trong khi không rõ ràng về GUI mà bạn đề cập ở trên, bạn có quyền trong các cài đặt trên mỗi bảng cụ thể có thể hữu ích.
dezso
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.