Tôi có Postgres 9.2 DB trong đó một bảng nhất định có rất nhiều hàng chết không thể phá hủy:

# SELECT * FROM public.pgstattuple('mytable');
 table_len  | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
------------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
 2850512896 |      283439 | 100900882 |          3.54 |          2537195 |     2666909495 |              93.56 |   50480156 |         1.77
(1 row)

Hút bụi thông thường cũng cho thấy rất nhiều hàng chết không thể di chuyển:

# VACUUM VERBOSE mytable;
[...]
INFO:  "mytable": found 0 removable, 2404332 nonremovable row versions in 309938 out of 316307 pages
DETAIL:  2298005 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 1.90s/2.05u sec elapsed 16.79 sec.
[...]

Bảng chỉ có khoảng 300.000 hàng dữ liệu thực tế, nhưng 2,3 triệu hàng chết (và điều này dường như làm cho các truy vấn nhất định rất chậm).

Theo SELECT * FROM pg_stat_activity where xact_start is not null and datname = 'mydb' order by xact_start;đó không có giao dịch cũ truy cập cơ sở dữ liệu. Các giao dịch cũ nhất đã cũ vài phút và chưa sửa đổi bất cứ điều gì trên bàn.

Tôi cũng đã kiểm tra select * from pg_prepared_xacts(để kiểm tra các giao dịch đã chuẩn bị) và select * from pg_stat_replication(để kiểm tra các bản sao đang chờ xử lý), cả hai đều trống.

Có rất nhiều phần chèn, cập nhật và xóa được thực hiện trên bảng đó, vì vậy tôi có thể hiểu rằng có rất nhiều hàng chết đang được tạo. Nhưng tại sao chúng không bị xóa bởi lệnh VACUUM?

Các giao dịch cũ nhất đã cũ vài phút và chưa sửa đổi bất cứ điều gì trên bàn.

Điều đó là không đủ. Tôi nghĩ điều cần thiết để đánh dấu các hàng này là đã chết là khi các giao dịch này được bắt đầu, không có giao dịch nào khác chạm vào các hàng này (thực hiện CẬP NHẬT hoặc XÓA trên chúng).

Cập nhật hoặc xóa một hàng sẽ giữ phiên bản trước của hàng đó ở vị trí cũ và đặt xmaxtrường của nó thành TXID của giao dịch hiện tại. Từ quan điểm của các giao dịch khác, phiên bản cũ của hàng này vẫn hiển thị nếu đó là một phần của ảnh chụp nhanh của họ. Ảnh chụp từng có một xminvà xmaxđể đó xminvà xmaxcác phiên bản hàng có thể so sánh. Vấn đề là VACUUM phải so sánh các phiên bản hàng với khả năng hiển thị kết hợp của tất cả các ảnh chụp nhanh trực tiếp, trái ngược với việc kiểm tra đơn giản nếu một thay đổi hàng được cam kết chắc chắn. Cái sau là cần thiết nhưng không đủ để tái chế không gian được sử dụng bởi phiên bản cũ.

Ví dụ: đây là một chuỗi các sự kiện sao cho VACUUM không thể dọn sạch các hàng chết mặc dù giao dịch đã sửa đổi chúng đã kết thúc:

• t0: Giao dịch chạy dài TX1 bắt đầu
• t0+30mn: TX2 khởi động và tự đặt ở chế độ REPEATABLE READ.
• t0+35mn: TX1 kết thúc.
• t0+40mn: pg_stat_activity chỉ hiển thị TX2 cũ 10 triệu
• t0+45mn: VACUUM chạy nhưng sẽ không loại bỏ các phiên bản cũ của các hàng được sửa đổi bởi TX1 (vì TX2 có thể cần chúng).

Tôi đã có thể tạo lại điều này. Về cơ bản, khi bên trong một giao dịch,

• Ở READ COMMITTEDcấp độ giao dịch mặc định:
  • SELECT được một AccessShareLock
  • VACUUM có thể dọn sạch các phiên bản hàng chết
  • pg_stat_activity.backend_xmin IS NULL cho giao dịch
• Trong SERIALIZABLEhoặc REPEATABLE READcấp độ giao dịch:
  • SELECT được một AccessShareLock
  • VACUUMcó thể không dọn dẹp hàng phiên bản chết
  • pg_stat_activity.backend_xmin IS NOT NULL cho giao dịch
  • VERBOSEbáo cáo các hàng này là "phiên bản hàng không thể di chuyển" và "phiên bản hàng chết"

Dữ liệu mẫu

CREATE TABLE bar AS
SELECT x::int FROM generate_series(1,10) AS t(x);

Như một lưu ý phụ, nếu bạn xóa bất cứ thứ gì từ barsau khi bạn tạo bảng, những hàng đó sẽ trở thành removablevà VACUUMbạn sẽ thấy.

INFO:  "bar": removed # row versions in # pages

Trình tự giao dịch

Bây giờ, đây là bảng txn để tạo lại kịch bản.

txn1       - BEGIN; SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
txn1       - SELECT * FROM bar;
      txn2 - DELETE FROM bar;      -- We delete after the select
      txn2 - VACUUM VERBOSE bar;   -- Can't remove the "dead row versions"

VACUUMkhông thể xóa các phiên bản hàng đó vì phần tiếp SELECT * FROM bar;theo REPEATABLE READvẫn sẽ thấy chúng! Các VACUUMsản phẩm trên,

# VACUUM VERBOSE bar;
INFO:  vacuuming "public.bar"
INFO:  "bar": found 0 removable, 10 nonremovable row versions in 1 out of 1 pages
DETAIL:  10 dead row versions cannot be removed yet.
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.

Đó chính xác là những gì bạn đang thấy.

Gỡ lỗi

Để tìm ra truy vấn nào ngăn chặn việc VACUUMdọn sạch các hàng chết, hãy chạy nó ..

SELECT query, state,locktype,mode
FROM pg_locks
JOIN pg_stat_activity
  USING (pid)
WHERE relation::regclass = 'bar'::regclass
  AND granted IS TRUE
  AND backend_xmin IS NOT NULL;

Điều này sẽ trả lại một cái gì đó như thế này ..

       query        │        state        │ locktype │      mode       
────────────────────┼─────────────────────┼──────────┼─────────────────
 SELECT * FROM bar; │ idle in transaction │ relation │ AccessShareLock

Giải pháp

Vì vậy, hãy quay trở lại TXN của chúng tôi .. Chúng tôi cần phải giết / commit / rollback txn1 và chạy lại VACUUM

txn1       - COMMIT;
      txn2 - VACUUM VERBOSE bar;

Và bây giờ chúng ta thấy,

# VACUUM VERBOSE bar;
INFO:  vacuuming "public.bar"
INFO:  "bar": removed 10 row versions in 1 pages
INFO:  "bar": found 10 removable, 0 nonremovable row versions in 1 out of 1 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "bar": truncated 1 to 0 pages
DETAIL:  CPU 0.00s/0.00u sec elapsed 0.01 sec.

Ghi chú đặc biệt

1. Không quan trọng hàng nào đã bị xóa và hàng nào bạn đã chọn. Việc chọn được ACCESS SHAREkhóa trên bàn. Và, sau đó VACUUMkhông thể xóa các hàng chết để chúng được đánh dấu là "không thể xóa được".

2. Tôi nghĩ rằng đây là hành vi khá kém cho VACUUM VERBOSE. Tôi rất muốn xem ..

   DETAIL:  10 dead row versions cannot be removed yet
            could not aquire SHARE UPDATE EXCLUSIVE lock on %TABLE
   

đọc thêm

• Đây là một bài viết thực sự tuyệt vời của Erwin, "Hậu quả của việc không kết thúc giao dịch cơ sở dữ liệu là gì?" . Anh chạm vào VACUUMđó.

• Nhận xét này của @Craig Ringer tổng hợp điều này

  SERIALIZABLE hoặc REPEATABLE READ xacts chặn chân không loại bỏ các hàng chết. Đây chỉ là một xact READ READ mà không có ảnh chụp nhanh hoạt động cho phép tiến hành hút bụi. Một số điều khác, như với con trỏ GIỮ, xact đã chuẩn bị, vv cũng làm như vậy.

• Đối với những gì có thể là một chuyến đi xuống hố thỏ câu hỏi của tôi để biết thêm thông tin về backend_xmincảm hứng từ công việc của tôi với câu trả lời này

Ngoài ra, cảm ơn Daniel Vérité vì đã khiến tôi xem xét danh mục hệ thống và hành vi của VACUUMcái này.

Tôi đã phải đối mặt với vấn đề này ngay cả sau khi xác minh rằng cơ sở dữ liệu của tôi không có bất kỳ giao dịch hoạt động hoặc khóa hoạt động nào trên một bảng "foo" nhất định.

Phương pháp sau đây đã xóa thành công tất cả các hàng chết không thể tháo rời khỏi "foo":

CREATE TEMP TABLE temp_foo AS SELECT * FROM "foo";
TRUNCATE TABLE "foo";
INSERT INTO "foo" SELECT * FROM temp_foo;
DROP table temp_foo;

Chỉ cần lưu ý rằng nếu bạn có một bảng lớn có quá nhiều hàng thì đây có thể không phải là giải pháp khả thi, vì tất cả các hàng của bảng được chuyển sang một bảng tạm thời và sau đó được chuyển trở lại bảng ban đầu.