Postgres cơ sở dữ liệu tạm dừng dài


7

Tôi có một bảng khá lớn (1 triệu hàng) và cơ sở dữ liệu của tôi bị kẹt trên chế độ tự động (> 30 phút) trên bảng này, khiến toàn bộ cơ sở dữ liệu bị kẹt. Ứng dụng thậm chí sẽ không tải ngay bây giờ.

-00:37:31.137859 autovacuum: VACUUM public.users
SELECT n_tup_del, n_tup_upd FROM pg_stat_all_tables WHERE relname = 'users';

nhập mô tả hình ảnh ở đây

Đây là các cài đặt tự động lưu trên bảng người dùng của tôi:

autovacuum_vacuum_scale_factor=0.0, 
autovacuum_vacuum_threshold=5000,
autovacuum_analyze_scale_factor=0.0,
autovacuum_analyze_threshold=5000

Những cài đặt được đề xuất này tôi đã sử dụng từ Slow PostgreQuery Performance? Đừng quên hút bụi cơ sở dữ liệu của bạn

Tôi có phải đợi nó không? Những lựa chọn của tôi là gì?

Cập nhật

Tôi đã nâng cấp lên Postgres 9.5 và cũng đã tăng RDS IOPS của mình lên 900 và quá trình chân không vẫn tối đa hóa IOPS và không thể làm gì khác với cơ sở dữ liệu. Quá trình đã diễn ra tại một thời điểm 1 ngày trước khi nâng cấp.

Tôi cũng đã xóa các cài đặt tự động tùy chỉnh mà tôi có và bây giờ chỉ sử dụng mặc định.

Đây là một tập tin đính kèm kết quả của các truy vấn này;

SELECT * FROM pg_stat_activity;
SELECT * FROM pg_stat_database;
SELECT * FROM pg_stat_user_tables;
SELECT * FROM pg_stat_user_indexes;
SELECT * FROM pg_locks;

http://www.filedropper.com/output_5


1
Bộ dữ liệu cập nhật 1G trên bảng hàng 1M? Bạn đang làm một số cập nhật nặng. Có nhiều khả năng có một cách tiếp cận tốt hơn cho vấn đề của bạn, bất kể đó là gì.
dezso

@dezso yea Tôi nghĩ nguyên nhân cốt lõi của vấn đề là một số cập nhật lớn tôi đang thực hiện trên bảng để cập nhật khi người dùng trực tuyến. Tôi đã quyết định chuyển cái này sang cơ sở dữ liệu redis, vì vậy hy vọng sẽ giải quyết được vấn đề.
Andrew Cetinic

Nếu quá trình tự động mất nhiều thời gian, có lẽ nó sẽ tự điều chỉnh và bạn nên đặt vacuum_cost_limitở mức cao hơn, nhưng khó có thể nói điều đó liên quan đến vấn đề IOPS mà bạn đang gặp phải
jberryman

Câu trả lời:


5

VACUUM các quá trình được khởi chạy bởi autovacuum có thể bị giết một cách an toàn với:

SELECT pg_terminate_backend(PID_of_backend);

Trên thực tế, bất kỳ quy trình khách hàng nào trong Postgresql đều có thể được chấm dứt theo cách này. Công việc không được cam kết bởi phụ trợ này sẽ bị loại bỏ.

Sau đó, bạn có thể chạy lại VACUUMthủ công ở thời điểm lưu lượng thấp:

VACUUM VERBOSE users;

Kiểm tra xem độ trễ chân không dựa trên chi phí có thể giúp bạn. Điều này sẽ giới hạn số lượng I / O quy trình tự động sử dụng của bạn.

Có lẽ bạn chỉ cần đạt giới hạn IOPS của bạn. Bạn sẽ có thể thấy các số trên giao diện AWS. Trên Linux độc lập sử dụng iostat -dtkxy 10để đo I / O. ( iostatthường được đóng gói trong sysstatgói).

Có thể các VACUUMcú đá lại thường xuyên như vậy vì các cài đặt tích cực trong cấu hình của bạn.


4
Không thể cài đặt và sử dụng hai công cụ này trên một ví dụ RDS.
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.