Thời gian thực hiện PostgreSQL ANALYZE trong hơn 24h (vẫn đang chạy)

Tôi đã nâng cấp Postgres DB 9.3.2 -> 10.5 bằng pg_upTHER (tại chỗ). Tôi đã làm mọi thứ theo tài liệu và hướng dẫn được cung cấp bởi pg_upTHER. Mọi thứ đều ổn nhưng sau đó tôi nhận ra rằng các chỉ mục không được sử dụng trong một trong các bảng (có thể các bảng khác cũng bị ảnh hưởng).

Vì vậy, tôi đã bắt đầu một cái ANALYZEtrên bàn hôm qua vẫn đang chạy (trong hơn 22h) ...!

Câu hỏi: Có bình thường ANALYZEkhi có thời gian thực hiện lâu như vậy không?

Bảng chứa khoảng 30M hồ sơ. Cấu trúc là:

CREATE TABLE public.chs_contact_history_events (
    event_id bigint NOT NULL
           DEFAULT nextval('chs_contact_history_events_event_id_seq'::regclass),
    chs_id integer NOT NULL,
    event_timestamp bigint NOT NULL,
    party_id integer NOT NULL,
    event integer NOT NULL,
    cause integer NOT NULL,
    text text COLLATE pg_catalog."default",
    timestamp_offset integer,
    CONSTRAINT pk_contact_history_events PRIMARY KEY (event_id)
);

ALTER TABLE public.chs_contact_history_events OWNER to c_chs;

CREATE INDEX ix_chs_contact_history_events_chsid
    ON public.chs_contact_history_events USING hash (chs_id)
    TABLESPACE pg_default;

CREATE INDEX ix_chs_contact_history_events_id
    ON public.chs_contact_history_events USING btree (event_id)
    TABLESPACE pg_default;

CREATE INDEX ix_history_events_partyid
    ON public.chs_contact_history_events USING hash (party_id)
    TABLESPACE pg_default;

CẬP NHẬT:

Tôi đã chạy truy vấn bên dưới để có được các quy trình hiện đang chạy và nhận được nhiều kết quả thú vị hơn:

SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes'
AND state = 'active';

Có vẻ như các nhiệm vụ bảo trì và giải trí đồng thời của bảng chỉ số bị đóng băng!

Vì vậy, câu hỏi tiếp theo: có an toàn để hủy bỏ các quy trình? Và phải làm gì tiếp theo? IMO dừng tất cả chúng và khởi động lại việc tạo chỉ mục sẽ là cần thiết nhưng tôi không chắc chắn.

PHỤ LỤC 1

Có thể các lỗi liên quan đã được sửa trong v9:

9.3.7 và 9.4.2 Khắc phục lỗi có thể xảy ra trong quá trình tách nhóm chỉ số băm, nếu các quy trình khác đang sửa đổi chỉ mục đồng thời

9.3.18 và 9.4.13 và 9.5.8 và 9.6.4 Khắc phục tham nhũng xác suất thấp của bảng băm khóa biến vị ngữ được chia sẻ trong các bản dựng Windows

9.5.4 Khắc phục việc xây dựng các chỉ mục băm lớn (lớn hơn shared_buffers) Đường dẫn mã được sử dụng cho các chỉ mục lớn có lỗi gây ra các giá trị băm không chính xác được chèn vào chỉ mục, do đó các tìm kiếm chỉ mục tiếp theo luôn thất bại, ngoại trừ các bộ dữ liệu được chèn vào chỉ mục sau khi xây dựng ban đầu.

Có thể các lỗi liên quan được sửa trong v10:

10.2 Khắc phục lỗi không đánh dấu siêu dữ liệu của chỉ số băm bẩn sau khi thêm trang tràn mới, có khả năng dẫn đến tham nhũng chỉ mục

Ngăn chặn lỗi hết bộ nhớ do sự tăng trưởng quá mức của các bảng băm đơn giản

Và cuối cùng nhưng không kém phần quan trọng khiến tôi lo ngại (vì một bản nâng cấp dường như không thực tế trên môi trường sản xuất):

10.6 Tránh vượt quá siêu dữ liệu của chỉ số băm khi BLCKSZ nhỏ hơn mặc định

Sửa lỗi cập nhật tổng kiểm tra trang bị mất trong chỉ mục băm

PHỤ LỤC 2

Hướng dẫn nâng cấp trong v10:

Các chỉ mục băm phải được xây dựng lại sau pg_upTHER-ing từ bất kỳ phiên bản PostgreQuery chính nào trước đó

Cải thiện chỉ số băm lớn đòi hỏi yêu cầu này. pg_upTHER sẽ tạo một tập lệnh để hỗ trợ việc này.

Lưu ý rằng tôi đã chạy tập lệnh đó tất nhiên tại thời điểm nâng cấp.

Sau vài giờ nghiên cứu và kiểm tra tình hình hiện tại, tôi nghĩ rằng tôi đã giải quyết được vấn đề. (Rất cám ơn người dùng ypercube đã truyền cảm hứng và cho Erwin Brandstetter, người đã song hành cùng một giải pháp.)

Vì vậy, có một số lớp của vấn đề.

1.) NÂNG CẤP

Nâng cấp với pg_upTHER 9.3.2 -> 10.5 nên được thực hiện theo hai bước. Đầu tiên trong cùng một dòng (9.3.2 -> 9.3.25) và sau đó đến 10.x (10.5 trong trường hợp của tôi)

Tôi đã thực hiện nâng cấp trực tiếp và có vẻ như đó là nguyên nhân gốc rễ của vấn đề.

2.) CHỈ SỐ HASH

Có vẻ như các chỉ mục băm bị một số lỗi lạ trong các postgres đã được sửa nhưng việc sử dụng các chỉ mục của các phiên bản sửa trước dẫn đến lỗi

3.) NHIỆM VỤ FROZEN

Thật có ý nghĩa để tìm kiếm các quá trình postgres đang chạy trong thời gian dài không thực tế. (Xem truy vấn trong câu hỏi.) Trong trường hợp của tôi, hóa ra việc giải trí các chỉ mục bị mắc kẹt bằng cách nào đó và một số nhiệm vụ khác cũng bị chặn.

Có thể hủy hầu hết chúng SELECT pg_cancel_backend(__pid__);trong đó pid là ID tiến trình được tìm thấy trong tập kết quả của truy vấn được đề cập trước đó. Vì vậy, tôi đã làm nó. Tôi thậm chí đã dừng các quá trình autovacuum.

4.) XỬ LÝ NHỚ

Khi sau tất cả những điều này cuối cùng tôi đã nghĩ rằng tôi có thể xóa và tạo các chỉ mục mới mà tôi gặp phải vấn đề tiếp theo. Sau khoảng một phút, tất cả các truy vấn bảo trì đã thoát với thông báo lỗi:

ERROR: out of memory
DETAIL: Failed on request of size 22355968.
SQL state: 53200

Có vẻ như việc xử lý bộ nhớ đã thay đổi trong khoảng từ 9.3 đến 10. Tôi đã phải giảm lượng bảo trì_mem trong cấu hình:

maintenance_work_mem = 64MB     # min 1MB

Đó là 512MB trước đó và mặc dù máy chủ có 32GB RAM nhưng nó vẫn không hoạt động với điều đó.

5.) CHỈ SỐ THU HỒI

Sau tất cả, nó có thể tạo lại các chỉ mục (bỏ cái cũ và tạo cái mới). Nó sẽ dễ dàng hơn với một kịch bản phù hợp nhưng tôi phải làm nó bằng tay. Đừng quên rằng việc tạo và xóa các chỉ mục sẽ khóa bảng vì vậy trong môi trường sản xuất (như của tôi), bạn nên thực hiện điều đó một cách TUYỆT VỜI.

Biên tập:

Tôi cũng nhận ra rằng việc sử dụng các chỉ số băm trong trường hợp cụ thể của tôi không thực sự có ý nghĩa nên tôi quyết định thay đổi chúng thành btree tại giải trí.

6.) PHÂN TÍCH

Sau khi tạo lại các chỉ mục, cần phải chạy một phân tích trên các bảng bị ảnh hưởng (hoặc toàn bộ DB). Sau tất cả các hành động trên, nó sẽ chạy nhanh một cách đáng ngạc nhiên ngay cả trong một DB lớn như của tôi.

Các chỉ mục một lần nữa được sử dụng và hiệu suất hoàn hảo trở lại. Vì vậy, đây là một kết thúc có hậu trong bài viết StackExchange đầu tiên của tôi. :-)