Làm thế nào để làm cho pg_dump bớt tham lam tài nguyên

Tôi đã cấu hình cron để gọi pg_dump hàng ngày bằng cách sử dụng quy tắc sau:

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

Về cơ bản, nó hoạt động. Cơ sở dữ liệu phát triển tương đối nhanh và theo cấp số nhân (tuy nhiên số mũ không lớn lắm). Hiện tại bãi chứa gzipped mất khoảng 160MB. Khi cơ sở dữ liệu bị đổ, hệ thống bắt đầu thu thập dữ liệu. Tải trung bình tôi thấy bằng cách sử dụng toplệnh là về 200, 200, 180. Về cơ bản máy chủ hầu như không đáp ứng.

Câu hỏi đầu tiên là làm thế nào để xác định nơi tắc nghẽn. Là hiệu suất kém gây ra bởi các hoạt động I / O nặng? Có phải do vấn đề khóa bảng? Có lẽ đó là một vấn đề bộ nhớ? Đầu ra của pg_dumplệnh được dẫn đến gziplệnh. Là nó tuần tự, tức là toàn bộ kết xuất được đặt trong bộ nhớ (vấn đề hoán đổi?) Và sau đó được nén hoặc đồng thời (tức là gzip nén những gì nó nhận được và chờ thêm)? Nó có thể được gây ra bởi một số yếu tố khác?

Câu hỏi thứ hai là làm thế nào để làm cho hoạt động bán phá giá ít xâm phạm hơn đối với các chức năng chính của hệ thống. Theo như tôi hiểu, việc kết xuất không thể mất quá nhiều thời gian vì tính toàn vẹn của cơ sở dữ liệu. Có khóa ghi bảng, v.v. Tôi có thể làm gì để hạn chế các vấn đề (hoặc trì hoãn nó, xem xét tăng trưởng cơ sở dữ liệu).

Câu hỏi thứ ba : Đã đến lúc tìm hiểu về các cấu hình cơ sở dữ liệu nâng cao hơn chưa? Hệ thống hoạt động tốt, khi sao lưu cơ sở dữ liệu không được thực hiện, nhưng có lẽ sự cố đổ db là triệu chứng đầu tiên của các sự cố đến?

Ồ Số lượng câu hỏi tuyệt vời. Tôi sẽ cố gắng giải quyết một số, nhưng câu trả lời này vẫn chưa hoàn thành.

Làm thế nào để xác định nơi tắc nghẽn.

Sử dụng topđầu tiên để xem những gì đang xảy ra trong bãi rác. Kiểm tra quá trình sử dụng CPU, trạng thái quá trình. Dcó nghĩa là "chờ I / O".

Là hiệu suất kém gây ra bởi các hoạt động I / O nặng?

Vâng, rất có thể.

Có phải do vấn đề khóa bảng?

Có lẽ. bạn có thể sử dụng pg_stat_activitychế độ xem hệ thống để xem những gì đang diễn ra trong postgres trong khi kết xuất.

Có lẽ đó là một vấn đề bộ nhớ?

Rất khó xảy ra.

Đầu ra của lệnh pg_dump được dẫn đến lệnh gzip. Là nó tuần tự, tức là toàn bộ bãi chứa được đặt trong bộ nhớ (vấn đề hoán đổi?)

Số gzip là một máy nén khối làm việc ở chế độ luồng, nó không giữ tất cả đầu vào trong bộ nhớ.

và sau đó được nén hoặc đồng thời (tức là gzip nén những gì nó nhận được và chờ thêm)?

Có, nó nén từng khối, đầu ra và chờ thêm.

Nó có thể được gây ra bởi một số yếu tố khác?

Đúng.

Theo như tôi hiểu, việc kết xuất không thể mất quá nhiều thời gian vì tính toàn vẹn của cơ sở dữ liệu. Có khóa ghi bảng, v.v. Tôi có thể làm gì để hạn chế các vấn đề (hoặc trì hoãn nó, xem xét tăng trưởng cơ sở dữ liệu).

Thời gian đổ không ảnh hưởng đến tính toàn vẹn của bãi chứa. Tính toàn vẹn được đảm bảo bằng cách sử dụng một giao dịch với mức cô lập đọc lặp lại theo tất cả quy trình pg_dump. Không có khóa ghi bảng.

Đã đến lúc tìm hiểu về các cấu hình cơ sở dữ liệu nâng cao hơn? Hệ thống hoạt động tốt, khi sao lưu cơ sở dữ liệu không được thực hiện, nhưng có lẽ sự cố đổ db là triệu chứng đầu tiên của các sự cố đến?

Không bao giờ quá muộn. Bắt đầu với http://wiki.postgresql.org/wiki/Performance_Optimization .

Tôi khuyên bạn nên xem lưu trữ liên tục của postgresql. Dưới đây là những lợi thế của việc sử dụng pg_dump:

1. Không cần phải sao lưu đầy đủ mỗi lần. Một bản sao lưu đầy đủ là đủ ngay từ đầu, nhưng bạn nên có một bản sao lưu đầy đủ cứ sau vài ngày.
2. Nhanh hơn rất nhiều để khôi phục khi DB tăng kích thước.
3. Khả năng khôi phục lại một số điểm khác (Phục hồi tại thời điểm).
4. Bạn sẽ thực hiện sao lưu gia tăng mỗi giờ (30 phút hoặc lâu hơn). Điều này có thể được cấu hình và cũng phụ thuộc vào hoạt động cập nhật.

Tuy nhiên, có một số nhược điểm (có thể không phải là vấn đề trong hầu hết các trường hợp):

1. Thông thường cần nhiều không gian hơn vì đây là các bản sao lưu nhị phân. Thư mục DB có thể được nén.
2. Bạn không thể khôi phục chúng trên một kiến ​​trúc khác (dữ liệu nhị phân).