Cấu hình PostgreSQL cho hiệu suất ghi

Một trong những máy chủ PostgreSQL của tôi lưu trữ một số cơ sở dữ liệu (1-3) nhận được luồng dữ liệu liên tục. Dữ liệu không có cấu trúc đặc biệt, nó có thời gian hiện tại và nhiều loại dữ liệu được quan sát cho thời điểm cụ thể đó. Tốc độ dữ liệu khá cao; nó hoạt động khoảng một gigabyte mỗi ngày cho một cơ sở dữ liệu, khoảng một phần mười trong số đó cho cơ sở dữ liệu khác. Tôi không hy vọng tỷ lệ này sẽ tăng. Hiệu suất đọc là một ưu tiên thấp hơn nhiều và hiện đang được chấp nhận.

Trong nhật ký tôi có thông báo này:

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Giá trị này hiện được đặt thành 16, theo phép lịch sự pgtune.

Các cài đặt tôi nên xem xét để cải thiện hiệu suất ghi là gì? Tôi muốn giữ an toàn nhất có thể. Xem xét khối lượng dữ liệu đến, tôi có thể chấp nhận mất một số dữ liệu gần đây trong một thất bại miễn là phần lớn dữ liệu còn nguyên vẹn.

Chỉnh sửa: Hiện tại tôi đang sử dụng PostgreSQL 9.0, nhưng tôi dự định nâng cấp lên 9.1. Tôi không đăng chi tiết phần cứng bởi vì trong khi tôi thừa nhận tầm quan trọng của chúng, cuối cùng tôi sẽ cần thực hiện tối ưu hóa này trên một số máy có phần cứng rất đa dạng. Nếu phần cứng là điều cần thiết cho câu trả lời, xin vui lòng cho tôi thông tin chung để tôi có thể áp dụng câu trả lời cho các máy có cấu hình phần cứng khác nhau.

1 Gigabyte mỗi ngày không phải là mức tải cao. Trải ra suốt cả ngày, tức là khoảng 50 nghìn một giây. Một ổ USB chậm có thể xử lý việc đó. Tôi cho rằng nó bùng nổ hơn mặc dù. Như a_horse_with_no_name gợi ý, hãy tăng các phân đoạn điểm kiểm tra. 100 hoặc không phải là không bình thường.

Sau đó tăng lên checkpoint_timeout1 giờ, cũng như xem xét tăng của bạn checkpoint_completion_targetlên một cái gì đó gần hơn với 1.0 (100%). Mục tiêu hoàn thành cho PostgreQuery biết cách viết mã nền một cách mạnh mẽ để nó hoàn thành x% trước khi chạy một điểm kiểm tra, điều này buộc tất cả dữ liệu phải được ghi ra từ WAL và sẽ làm chậm hệ thống để thu thập dữ liệu trong khi nó xảy ra.

Lý do bạn thường không đặt nó thành 100% là vì việc viết vào cùng một khối nhiều lần là khá phổ biến và bằng cách trì hoãn WAL viết ra cửa hàng chính, bạn ngăn chặn cùng một khối được viết hai lần mà không có lý do.

Nếu không chắc bạn sẽ viết vào cùng một khối nhiều hơn một lần trước khi hết thời gian chờ, tức là tất cả những gì bạn làm là chèn sau đó đặt nó ở mức khá cao có ý nghĩa để nâng nó lên 0,9 hoặc hơn. Điều tồi tệ nhất sẽ xảy ra là bạn sẽ viết thường xuyên hơn một chút so với những gì bạn có thể cần, nhưng tác động của điểm kiểm tra sẽ giảm đi rất nhiều.

Trong một hệ thống rất 'viết nặng', bạn có khả năng bị giới hạn bởi tốc độ WAL có thể được viết trong hoạt động cao điểm.

Nếu bạn thực sự có thể "chấp nhận mất một số dữ liệu gần đây trong một thất bại", bạn có thể tắt cam kết đồng bộ :

có thể là một sự thay thế hữu ích khi hiệu suất quan trọng hơn sự chắc chắn chính xác về độ bền của giao dịch

Nếu bạn có thể thay đổi phần cứng của mình, bạn có thể xem xét bất kỳ phần nào trong số này để tối ưu hóa ghi:

• RAID10 trên RAID5
• Rất nhiều trục chính (có thể có nghĩa là 2,5 "thay vì 3,5" chẳng hạn)
• SAS trên SATA
• Ổ đĩa 15K trên 10K
• SSD

--chỉnh sửa

Dựa trên nhận xét của bạn về câu trả lời xuất sắc của @ Scott : "Khối lượng ghi thực sự gần như hoàn toàn thống nhất" và tốc độ dữ liệu ngụ ý là "50 nghìn một giây", tôi nghi ngờ bạn cần làm bất cứ điều gì có nguy cơ mất dữ liệu. Có lẽ nó sẽ giúp để biết một số tham số cấu hình khác của bạn được đặt thành gì.

Bạn cũng có thể kiểm tra tần suất / kích thước của các cam kết của mình: Gần đây tôi gặp phải một vấn đề trong đó tôi đang cố cập nhật> 1 triệu hồ sơ trong một giao dịch. Tôi đã nhận được thông báo nhật ký tương tự như thông báo được mô tả bởi OP, nhưng giao dịch không thể hoàn thành ngay cả sau vài giờ. Khi tôi chia nhỏ ghi thành nhiều giao dịch nhỏ hơn (10.000 hồ sơ hoặc hơn), tổng thời gian cần thiết giảm xuống còn khoảng 15 phút.

Điều tôi nghĩ đã xảy ra là Postgres đã dành quá nhiều thời gian để viết nhật ký mà checkpoint_timeout đã trôi qua trước khi nó có thể đạt được tiến bộ đáng kể trong việc lưu các hồ sơ. Tôi không chắc lời giải thích đó có đúng không. Tôi vẫn nhận được các cảnh báo, nhưng tất cả các bài viết cuối cùng đã được xử lý. Tuy nhiên, tôi cần (và tìm thấy) một cách giải quyết theo chương trình thay vì yêu cầu cấu hình lại cơ sở dữ liệu.

Xem thêm http://www.postgresql.org/docs/9.3/static/wal-configuration.html