Một trong những phần hữu ích hơn của tài liệu
PostgreSQL mà tôi từng làm việc là Điều chỉnh Máy chủ PostgreSQL
của bạn. Khi điều đó được viết vào mùa hè năm 2008, một vài tháng sau khi
phát hành PostgreSQL 8.3, thật khó để tìm thấy bất kỳ hướng dẫn tương tự nào
vừa (tương đối) ngắn gọn và hiện tại. Kể từ đó, tôi và
nhiều cộng tác viên PostgreSQL khác đã giúp giữ cho tài liệu đó được cập nhật
khi các thay đổi đối với PostgreSQL được thực hiện.
Xu hướng thú vị và hữu ích
trong khoảng thời gian đó là các thông số tiếp tục biến mất khỏi tập hợp
trong số những người bạn cần lo lắng. Trong PostgreSQL 8.2, có một danh sách dài
các tham số mà bạn có thể cần để điều chỉnh để có hiệu suất tốt
trên máy chủ PostgreSQL:shared_buffers, effect_cache_size,
checkpoint_searies, autovacuum, max_fsm_pages,
default_st Statistics_target, work_mem, wal_buffers và (nếu sử dụng phân vùng
) bind_exclusion.
8.3 đã đặt autovacuum mặc định được bật
lên với hành vi hợp lý, cùng với việc xóa một số
các thông số của người viết nền không gây ra vấn đề gì ngoài rắc rối (chúng không bao giờ lọt vào danh sách). 8.4 đã loại bỏ sự cần thiết của hai tham số
max_fsm_ *, tăng default_st Statistics_target lên giá trị khởi đầu tốt hơn nhiều
và làm cho việc thiết lập bind_exclusion
không cần thiết trong các trường hợp phổ biến nhất. Đó là sáu tham số ít hơn
mà bạn có thể cần phải điều chỉnh.
Rất tiếc, phiên bản 9.0 chỉ khiến cấu hình máy chủ
phức tạp hơn. Và các hạt nhân Linux mới hơn thậm chí còn
đẩy lùi hành vi mặc định. Bắt đầu với hạt nhân Linux
2.6.33, giá trị mặc định được chọn cho wal_sync_method đã thay đổi thành
open_datasync. Điều này hóa ra có tác động
đến hiệu suất khủng khiếp đối với PostgreSQL, đặc biệt khi kết hợp với cài đặt mặc định
thấp cho wal_buffers trong máy chủ.
Nhưng hành vi tiến tới
mặc định tốt hơn gần đây đã tiếp tục cho những gì cuối cùng được lên kế hoạch là
PostgreSQL 9.1. Trong commitFest cuối cùng, một bản vá bắt nguồn từ Marti
Raudsepp để khắc phục sự cố wal_sync_method đã được cam kết
sau một số tranh cãi gay gắt về hình thức mà thay đổi sẽ thực hiện.
Khám phá ra rằng thay đổi hành vi này đã phá vỡ hoàn toàn PostgreSQL
khi chạy trên ext4 với tùy chọn “data =journal” đã giúp
giải quyết việc đúng đắn cần làm ở đây theo mặc định.
Hai thông số tôi không khuyên
chạm vào trong hầu hết các trường hợp là commit_siblings và commit_delay,
tạo tác của một nỗ lực cũ hơn nhằm cải thiện hiệu suất trên các hệ thống có
thời gian cam kết chậm (bao gồm hầu hết các hệ thống không có bộ nhớ đệm ghi
dự phòng bằng pin để tăng tốc khu vực đó). Ngày nay,
việc tắt tham số sync_commit được giới thiệu trong 8.3 có nhiều khả năng giúp ích hơn ở đây. Mặc dù những điều này không có khả năng cải thiện
hiệu suất, nhưng những người cố gắng thiết lập chúng đã phải chịu nhiều hơn
cần thiết từ những mặt trái của quyết định đó. Hành vi
trường hợp xấu nhất ở đây đã được cải thiện đáng kể trong một bản vá mà tôi đã viết để tối ưu hóa cách thực thi logic điều khiển các tham số đó.
Và tuần này, thông số mới nhất được
loại bỏ hiệu quả trong hầu hết các trường hợp là wal_buffers. Thay đổi mà tôi
đề xuất đã được cam kết đặt điều này tự động dưới dạng tỷ lệ phần trăm của kích thước (khoảng 3%)
được phân bổ cho các thông số shared_buffers thông thường lớn hơn nhiều.
Điều này đặt giá trị của wal_buffers thành giới hạn trên bình thường của phạm vi hiệu quả
của nó, 16MB, khi bạn đã phân bổ ít nhất 512MB cho
shared_buffers. Và nếu bạn đã tăng shared_buffers từ mặc định
nhỏ bé của nó, bạn sẽ nhận được một cải tiến tương ứng trong thông số hiệu suất cam kết quan trọng
này. Bạn sẽ phải cố gắng phá bỏ cài đặt của thông số này để tránh những tình huống xấu
có thể xảy ra trong các phiên bản trước đó.
Có lượng cấu hình bạn
cần thực hiện với máy chủ theo mặc định sẽ ít phức tạp hơn luôn
đáng giá, và việc thấy các tham số biến mất trong danh sách quan trọng là
một thay đổi đáng hoan nghênh. Cái gì tiếp theo? Các vấn đề cốt lõi với việc phân bổ
bộ nhớ dùng chung trên các hệ điều hành có nguồn gốc từ UNIX, đặc biệt là Linux, khiến việc loại bỏ bộ đệm chia sẻ rất khó khăn. Và những lo ngại
về việc máy chủ tiếp quản hệ thống hoàn toàn hạn chế khả năng
tự động đặt các tham số như work_mem ở phạm vi phù hợp.
Một số đề xuất để quản lý nhóm bộ nhớ hoạt động tốt hơn đã được
được đề xuất, để người ta có thể thấy một số cải tiến.
Tham số tiếp theo mà tôi để mắt đến là
checkpoint_searies. Sau khi chỉ thêm đăng nhập bổ sung vào khu vực này trong
commitFest cuối cùng, có một số cải tiến trong lĩnh vực này gần
cam kết ngay bây giờ để thực sự cải thiện hành vi của trạm kiểm soát. Tôi hy vọng cuối cùng sẽ
chuyển qua điều chỉnh trạm kiểm soát để được kiểm soát chặt chẽ
thông qua các tham số hướng thời gian, thay vì yêu cầu người dùng
hiểu cơ chế hoạt động của nhật ký ghi trước để điều chỉnh
hệ thống. Vẫn còn quá nhiều tình huống xấu có thể xảy ra ở đây để thực hiện
điều đó trong thời gian 9.1, nhưng việc đặt số lượng phân đoạn tự động là
khả thi để nhắm mục tiêu cho 9.2.
