Một chút quan tâm và chỉnh sửa đối với việc triển khai PostgreSQL của bạn sẽ giúp bạn đảm bảo hiệu suất một cách lâu dài, tránh những phát hiện khó chịu và thiết lập khả năng dự đoán tự tin. Dưới đây là 7 điều bạn nên để ý.
Bảng Bloat
PostgreSQL triển khai các giao dịch bằng kỹ thuật gọi làMVCC.MVCC quá dài và liên quan đến một chủ đề cần thảo luận chi tiết, nhưng có ba những điều bạn phải biết về nó:
- Việc xóa một hàng chỉ đánh dấu hàng đó là "ẩn" đối với các giao dịch trong tương lai.
- Việc cập nhật một hàng sẽ tạo ra một phiên bản mới của hàng đó. Phiên bản cũ được đánh dấu là hiển thị với các giao dịch trong tương lai và phiên bản mới được đánh dấu là hiển thị.
- Theo định kỳ, ai đó cần xem xét tất cả các giao dịch hiện đang chạy và nói:OK, giao dịch cũ nhất ở đây là # 42, vì vậy mọi phiên bản hàng ẩn đến # 42 đều có thể bị xóa thực tế mà không ảnh hưởng đến tính nhất quán của dữ liệu.
Đó là cách MVCC hoạt động (về cơ bản) và ngụ ý là các bản cập nhật sẽ tăng dung lượng lưu trữ cơ sở dữ liệu vật lý của bạn và xóa sẽ không giảm bớt. MVCC nghe có vẻ như là một cách lười biếng để làm mọi việc, nhưng nó được ưa chuộng vì nó mang lại cả tính nhất quán và hiệu suất.
Các phiên bản hàng lỗi thời, không mong muốn trong bảng được gọi là bloat (hoặc xác chết ). Quá trình có thể làm sạch khối phồng được gọi là hút chân không . PostgreSQL có một quy trình chân không được kích hoạt tự động với các ngưỡng có thể điều chỉnh được gọi làautovacuum và tất nhiên là lệnh VACUUM.
Nói chung, bloat cũng có thể làm chậm các truy vấn do bản đồ hiển thị không chính xác và I / O ổ đĩa lãng phí.
Do đó, bạn nên thường xuyên:
- theo dõi lượng phồng lên trong cơ sở dữ liệu
- chạy chân không thường xuyên
- theo dõi xem máy hút có được chạy thường xuyên cho tất cả các bảng không
Có một số SQL queriesto cung cấp một ước tính cồng kềnh cho mỗi bảng. Công cụ mã nguồn mởpgmetrics cung cấp ước tính độ phồng cũng như thời gian chạy cuối cùng của máy hút chân không thủ công và tự động.
Chỉ mục Bloat
Các chỉ mục cũng có thể phình ra. Mặc dù cấu trúc bên trong của các chỉ mục là không rõ ràng đối với người dùng SQL và thay đổi theo loại chỉ mục (BTree, băm, GIN, GIST, v.v.), ý tưởng chung vẫn là khi các hàng được chỉ mục tham chiếu bị xóa, không gian bị chiếm bởi thông tin liên quan bên trong chỉ mục chỉ được xóa hợp lý và không được giải phóng trở lại hệ thống tệp. Khoảng trắng đã xóa hợp lý có thể được chỉ mục sử dụng lại sau này.
Có hai cách để Postgres thu nhỏ kích thước vật lý của một chỉ mục:
- phiên bản ĐẦY ĐỦ của lệnh VACUUM
- REINDEX
Phải giám sát quá trình phình chỉ mục, để bạn ít nhất biết về lượng khoảng trống còn lại chưa được sử dụng. Trong các bảng có sự xáo trộn hàng cao, việc thiết lập các công việc xây dựng lại chỉ mục thường xuyên không phải là hiếm.
Chỉ mục bloat cũng có thể được lấy bằng các truy vấn giống như trước đây và cũng có thể thông qua pgmetrics.
Giao dịch dài hạn
Các giao dịch nên được giữ càng ngắn càng tốt, đặc biệt là trong hệ thống MVCC.
Hãy tưởng tượng rằng một giao dịch bắt đầu vào ngày hôm qua và ngay sau đó đã có một đợt giao dịch chân không. Bây giờ, miễn là giao dịch này còn mở, các khoảng trống tiếp theo là vô dụng, vì theo định nghĩa, giao dịch của chúng tôi sẽ cần phải xem tất cả các hàng của tất cả các bảng như khi giao dịch của chúng tôi bắt đầu ngày hôm qua. Ngay cả khi giao dịch của chúng tôi ở chế độ chỉ đọc, trường hợp này vẫn xảy ra.
Kết quả là, các giao dịch kéo dài tạo ra sự cồng kềnh. Chúng cũng bám vào tài nguyên hệ thống, giữ các ổ khóa chưa được liên kết và tăng khả năng xảy ra bế tắc.
Cách tốt nhất để theo dõi các giao dịch đang diễn ra trong thời gian dài là thiết lập cảnh báo cho số lượng giao dịch đã chạy trong khoảng thời gian nhất định hơn. Bạn có thể lấy thông tin này từ chế độ xem thống kê pg_stat_activity , như vậy:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Trễ sao chép
Khi sao chép trực tuyến được sử dụng để sao chép tất cả các thay đổi từ máy chủPostgreSQL chính sang chế độ chờ nóng (còn gọi là bản sao đọc), thường có độ trễ nhỏ giữa thời gian xảy ra cập nhật hàng trên máy chủ chính và khi các thay đổi hiển thị với các ứng dụng được kết nối với chế độ chờ .
Tuy nhiên, có những trường hợp độ trễ này có thể tăng lên:
- hệ thống ở chế độ chờ không thể nhận và áp dụng các thay đổi từ thiết bị chính đủ nhanh để theo kịp với hệ thống đó, thường là do tải cao hoặc cung cấp dưới mức
- mạng hoặc đĩa bị xuống cấp
- xung đột truy vấn
Chế độ chờ với độ trễ nhân bản cao hoặc thậm chí tệ hơn, ngày càng tăng có thể dẫn đến các truy vấn trên chế độ chờ trả về dữ liệu cũ và chế độ chờ không thích hợp để chuyển tiếp.
Nếu bạn có thiết lập sao chép trực tuyến, việc theo dõi độ trễ của quá trình sao chép giữa mỗi cặp chính ở chế độ chờ là rất quan trọng và bạn sẽ muốn thiết lập cảnh báo để kiểm tra xem độ trễ sao chép có vượt quá một phút hay bất kỳ ngưỡng nào cho phép thiết lập của bạn.
Bài đăng này có nhiều thông tin hơn về cách đo lường và theo dõi độ trễ sao chép từ cả đầu chính và đầu chờ.
Các vị trí sao chép không hoạt động
Việc sử dụng các khe sao chép, được giới thiệu trong PostgreSQL 9.4, làm cho việc phát trực tuyến trở nên mạnh mẽ và hiệu quả hơn. Về cơ bản, chế độ chờ sẽ báo cáo tiến trình sao chép của nó đến chính, nơi lưu trữ thông tin này trong “vùng sao chép”.
Bởi vì điều này, lúc này thiết bị chính luôn biết phía sau chế độ chờ bao xa. Điều này cho phép tệp chính giữ lại đủ tệp WAL tồn đọng (cần thiết để tiếp tục sao chép) khi chế độ chờ chuyển sang chế độ ngoại tuyến. Do đó, khi chế độ chờ quay trở lại, ngay cả sau một thời gian dài, phần mềm chính vẫn có thể đảm bảo rằng quá trình sao chép có thể được tiếp tục.
Trước khi có các vị trí sao chép, bộ chính có thể xóa các tệp WAL cũ, vì giờ đây nó đã biết liệu các ngăn chứa có cần chúng hay không. Nếu tệp WAL mà astandby cần bị xóa, không có cách nào để tiếp tục sao chép; nó phải thiết lập lại từ đầu.
Tuy nhiên, hành vi lưu giữ các tệp WAL vô thời hạn của các cơ quan chính dẫn đến một vấn đề khác. Nếu chế độ chờ đã ngừng hoạt động và vùng sao chép liên quan không bị xóa, các tệp WAL sẽ được giữ lại vĩnh viễn. Các tệp WAL được lưu giữ vì lý do này không tuân theo các giới hạn do max_wal_size đặt và các tùy chọn cấu hình khác.
Tình trạng này sẽ tiếp diễn cho đến khi tệp WAL chiếm hết dung lượng ổ đĩa, thậm chí không có cảnh báo trong tệp nhật ký PostgreSQL.
Không cần phải nói, các khe sao chép không hoạt động phải được xử lý khi chúng được phát hiện. Tìm vùng sao chép không hoạt động của bạn bằng cách sử dụng:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Phân tích trạng thái
ANALYZE chạy trên các bảng để thu thập và cập nhật thông tin thống kê về nội dung của bảng. Thông tin này được người lập kế hoạch truy vấn sử dụng để chuẩn bị kế hoạch thực thi cho mọi truy vấn SQL. Thống kê cập nhật về nội dung bảng dẫn đến kế hoạch thực thi tốt hơn, do đó dẫn đến truy vấn nhanh hơn.
Daemon autovacuum thường chạy ANALYZE sau VACUUM. Tuy nhiên, điều này có thể không đủ thường xuyên cho ANALYZE. Nếu phân phối dữ liệu có thể thay đổi thường xuyên, bạn nên chạy ANALYZE thường xuyên hơn.
Thông thường, ANALYZE hoạt động khá tốt - nó chỉ cần khóa đọc, không sử dụng quá nhiều tài nguyên và hoàn thành trong thời gian hợp lý. Việc chạy nó thường xuyên hơn là không an toàn.
Để mắt đến các bảng đã không được ANALYZEd trong một thời gian là một ý tưởng hay. Tìm hiểu lần cuối cùng các bảng của bạn được phân tích (tự động) bằng truy vấn:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Sử dụng Tài nguyên
Việc theo dõi tải CPU, bộ nhớ và việc sử dụng đĩa là một chặng đường dài trong việc đảm bảo bạn sẽ có đủ dung lượng để đáp ứng nhu cầu ngày càng tăng của các ứng dụng bằng cách sử dụng cơ sở dữ liệu của bạn.
PostgreSQL sinh ra một quy trình để xử lý một kết nối. Mặc dù đây có thể không phải là kiến trúc có khả năng mở rộng tốt nhất hiện nay, nhưng nó đóng góp rất nhiều vào mặt ổn định. Nó cũng làm cho mức trung bình tải của hệ điều hành có ý nghĩa hơn. Như thường các hộp PostgreSQL chỉ chạy PostgreSQL, mức trung bình tải nói là 3 thường có nghĩa là có 3 kết nối đang chờ các lõi CPU khả dụng mà chúng có thể được sắp xếp theo lịch trình. Theo dõi mức trung bình tải tối đa của bạn trong một ngày hoặc tuần thông thường để đưa ra ước tính về mức độ cung cấp quá mức hoặc quá thấp của hộp của bạn trên mặt trước CPU.
Bộ nhớ và không gian đĩa trống tất nhiên là những thứ tiêu chuẩn cần theo dõi. Nhiều kết nối hơn và các giao dịch chạy lâu hơn đặt ra yêu cầu cao hơn về bộ nhớ. Và trong khi theo dõi dung lượng đĩa trống, hãy nhớ theo dõi nó trên mỗi vùng bảng.
