Tại sao VACUUM ANALYZE sẽ không xóa tất cả các bộ dữ liệu đã chết?

Chúng tôi chạy "hướng dẫn" VACUUM ANALYZE VERBOSEtrên một số bảng lớn hơn sau khi chúng tôi thực hiện các DELETE/INSERTthay đổi lớn đối với chúng. Điều này dường như hoạt động mà không có vấn đề mặc dù đôi khi VACUUMcông việc của một bảng sẽ chạy trong nhiều giờ (xem bài đăng này cho các vấn đề và lý do tương tự).

Khi thực hiện nhiều nghiên cứu hơn, tôi thấy rằng chúng ta có các bảng lớn với số lượng lớn các bộ dữ liệu chết ngay cả sau khi chạy VACUUM. Ví dụ: đây là một số thống kê được tạo từ truy vấn trong phản hồi này .

-[ RECORD 50 ]--+---------------------------
relname         | example_a
last_vacuum     | 2014-09-23 01:43
last_autovacuum | 2014-08-01 01:19
n_tup           |    199,169,568
dead_tup        |    111,048,906
av_threshold    |     39,833,964
expect_av       | *
-[ RECORD 51 ]--+---------------------------
relname         | example_b
last_vacuum     | 2014-09-23 01:48
last_autovacuum | 2014-08-30 12:40
n_tup           |    216,596,624
dead_tup        |    117,224,220
av_threshold    |     43,319,375
expect_av       | *
-[ RECORD 52 ]--+---------------------------
relname         | example_c
last_vacuum     | 2014-09-23 01:55
last_autovacuum | 2014-09-23 18:25
n_tup           |    309,831,136
dead_tup        |    125,047,233
av_threshold    |     61,966,277
expect_av       | *

Trường cuối cùng tuyên bố rằng những cái này (và hầu hết các bảng) sẽ đáp ứng ngưỡng cho quá trình tự động. Tuy nhiên, chỉ cần chạy VACUUM ANALYZE VEBOSEtrên mỗi bảng trong số đó, không nên đếm số tuple chết là 0 (hoặc gần bằng 0, không phải 125M của 300M)?

Các tài liệu nêu:

VACUUM lấy lại bộ nhớ bị chiếm dụng bởi các bộ dữ liệu đã chết.

Điều này có nghĩa là chúng tôi VACUUMkhông làm việc?

CẬP NHẬT

Mỗi yêu cầu trong repsonse ở đây là một số nhật ký từ các VERBOSEcông việc:

INFO:  vacuuming "public.example_1"
INFO:  scanned index "idx_example_1_on_gp_id_and_dd_id" to remove 378386 row versions
DETAIL:  CPU 1.83s/3.42u sec elapsed 23.01 sec.
INFO:  scanned index "index_example_1_on_q_id" to remove 378386 row versions
DETAIL:  CPU 2.10s/3.91u sec elapsed 18.92 sec.
INFO:  "example_1": removed 378386 row versions in 7085 pages
DETAIL:  CPU 0.09s/0.05u sec elapsed 0.19 sec.
INFO:  index "idx_example_1_on_gp_id_and_dd_id" now contains 30347438 row versions in 291065 pages
DETAIL:  378386 index row versions were removed.
165587 index pages have been deleted, 164287 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "index_example_1_on_q_id" now contains 30347438 row versions in 333287 pages
DETAIL:  378386 index row versions were removed.
152773 index pages have been deleted, 152757 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "example_1": found 1773 removable, 401984 nonremovable row versions in 14438 out of 1493006 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 10567 unused item pointers.
0 pages are entirely empty.
CPU 4.26s/7.51u sec elapsed 46.10 sec.
INFO:  vacuuming "pg_toast.pg_toast_17917"
INFO:  index "pg_toast_17917_index" now contains 0 row versions in 1 pages
DETAIL:  0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "pg_toast_17917": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.example_1"
INFO:  "example_1": scanned 30000 of 1493006 pages, containing 611502 live rows and 0 dead rows; 30000 rows in sample, 40563141 estimated total rows

Bảng này hiện hiển thị 0 bộ dữ liệu chết trong số liệu thống kê. Hầu hết các bảng đều là các bộ dữ liệu chết thấp hơn nhiều vào sáng nay vì vậy VACUUMhoặc bộ lọc tự động của chúng tôi đang hoạt động.

Chúng tôi có một số bảng không tạo ra kết quả gì nhưng vẫn hiển thị các bộ dữ liệu đã chết:

-[ RECORD 49 ]--+---------------------------
relname         | example_2
last_vacuum     | 2014-09-23 02:23
last_autovacuum | 2014-09-02 14:30
n_tup           |    117,914,944
dead_tup        |     34,507,388
av_threshold    |     23,583,039
expect_av       | *

Một vài lần tôi đã thấy trong các bản ghi nơi các chỉ mục sẽ được kiểm tra nhiều lần. Điều này dường như tương ứng với các VACUUMcông việc dài hạn . Bất cứ ý tưởng tại sao? Có phải điều này chỉ hoạt động xung quanh việc khóa hồ sơ (tôi không nghĩ rằng bất kỳ ghi nào đã xảy ra trong quá trình chạy công việc này.)

INFO:  vacuuming "public.example_2"
...
INFO:  scanned index "index_example_2_on_gsg_id_and_dd_id" to remove 2795959 row versions
DETAIL:  CPU 3.88s/16.54u sec elapsed 23.09 sec.
INFO:  scanned index "index_example_2_on_q_id" to remove 2795959 row versions
DETAIL:  CPU 6.74s/21.13u sec elapsed 84.64 sec.
INFO:  "example_2": removed 2795959 row versions in 48214 pages
DETAIL:  CPU 0.71s/0.32u sec elapsed 33.65 sec.
INFO:  scanned index "index_example_2_on_gsg_id_and_dd_id" to remove 2591011 row versions
DETAIL:  CPU 2.84s/16.11u sec elapsed 19.28 sec.
INFO:  scanned index "index_example_2_on_q_id" to remove 2591011 row versions
DETAIL:  CPU 5.46s/22.70u sec elapsed 130.57 sec.
INFO:  "example_2": removed 2591011 row versions in 45539 pages
DETAIL:  CPU 0.67s/0.38u sec elapsed 15.16 sec.
INFO:  index "index_example_2_on_gsg_id_and_dd_id" now contains 123807784 row versions in 1560915 pages
DETAIL:  108836958 index row versions were removed.
1100790 index pages have been deleted, 718471 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.25 sec.
INFO:  index "index_example_2_on_q_id" now contains 123807784 row versions in 1886087 pages
DETAIL:  110336259 index row versions were removed.
1058063 index pages have been deleted, 266983 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.07 sec.
INFO:  "example_2": found 124808 removable, 1355901 nonremovable row versions in 2086343 out of 6966379 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 7858495 unused item pointers.
0 pages are entirely empty.
CPU 595.49s/2130.13u sec elapsed 5656.34 sec.
INFO:  vacuuming "pg_toast.pg_toast_18079"
INFO:  index "pg_toast_18079_index" now contains 0 row versions in 1 pages
DETAIL:  0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "pg_toast_18079": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.example_2"
INFO:  "example_2": scanned 30000 of 6966379 pages, containing 528443 live rows and 522 dead rows; 30000 rows in sample, 152953760 estimated total rows

VACUUM chỉ có thể loại bỏ các bộ dữ liệu đã chết từ lâu, nghĩa là đã chết cho tất cả các mục đích sử dụng có thể. Nếu bạn có các giao dịch tồn tại lâu dài, chúng có thể ngăn các bộ dữ liệu gần đây bị xóa.

Đây là một ví dụ về tình huống giao dịch tồn tại lâu bị ngăn chặn:

INFO:  "pgbench_accounts": found 0 removable, 2999042 nonremovable row versions in 49181 out of 163935 pages
DETAIL:  2999000 dead row versions cannot be removed yet.

Nó không thực sự là giao dịch lâu dài, nhưng ảnh chụp nhanh tồn tại lâu. Chắc chắn một câu lệnh chọn hoặc chèn chạy dài sẽ làm điều đó. Đối với các mức cô lập cao hơn mức cam kết đọc, toàn bộ giao dịch sẽ giữ lại ảnh chụp nhanh cho đến khi nó ngừng hoạt động, vì vậy nếu một số mở giao dịch đọc lặp lại và sau đó đi nghỉ mà không thực hiện, đó sẽ là một vấn đề. Các giao dịch được chuẩn bị sẵn cũng sẽ như vậy (nếu bạn không biết giao dịch được chuẩn bị là gì, thì có lẽ bạn không sử dụng chúng).

Các ví dụ bạn hiển thị không chỉ ra vấn đề, nhưng bạn cũng nói rằng vấn đề đã được giải quyết trước đó. Nếu đây là sự cố lặp lại, có lẽ bạn nên bắt đầu ghi nhật ký đầu ra của câu lệnh VACUUM ĐỘNG TỪ, để bạn có thể tìm thấy thông tin bao gồm khoảng thời gian xảy ra sự cố.

Nhiều lần vượt qua chỉ mục là do cài đặt bảo trì_work_mem của bạn. Nó chỉ có thể xóa một tuple cho mỗi 6 byte bộ nhớ trên mỗi lần vượt qua chỉ mục và cần thực hiện nhiều lần vượt qua nếu bạn cần loại bỏ nhiều hơn thế. Vì vậy, tăng bảo trì_work_mem sẽ giúp.

Kích thước của bảng vật lý thường (trừ việc cắt tỉa cơ hội các trang có thể tháo rời từ cuối bảng) không bị giảm khi chạy VACUUM(hoặc VACUUM ANALYZE). Bạn cần phải chạy VACUUM FULLđể thực sự thu nhỏ bảng.

Đây là một trích dẫn từ câu trả lời liên quan, có nhiều chi tiết hơn:

• Đối với bảng được tối ưu hóa căn chỉnh lớn hơn bảng gốc - tại sao?

Trên mỗi tài liệu (thực tế chỉ là một vài dòng dưới trích dẫn của bạn):

Plain VACUUM(không có FULL) chỉ đơn giản là lấy lại không gian và làm cho nó có sẵn để sử dụng lại. Dạng lệnh này có thể hoạt động song song với việc đọc và ghi thông thường của bảng, vì không có khóa độc quyền. Tuy nhiên, không gian thêm không được trả lại cho hệ điều hành (trong hầu hết các trường hợp);

Thêm ở đây:

• VACUUM trả lại không gian đĩa cho hệ điều hành

Bạn sẽ quan tâm đến pg numpack , có thể làm tương tự như VACUUM FULLkhông có khóa độc quyền.