Tôi có một phiên bản PostgreSQL 9.2 chạy trên RHEL 6.3, máy 8 lõi với 16GB RAM. Máy chủ được dành riêng cho cơ sở dữ liệu này. Cho rằng postgresql.conf mặc định khá bảo thủ về cài đặt bộ nhớ, tôi nghĩ có thể nên cho phép Postgres sử dụng nhiều bộ nhớ hơn. Thật ngạc nhiên, theo lời khuyên trên wiki.postgresql.org/wiki/Tuning_Your_PostgreQuery_Server đã làm chậm đáng kể thực tế mọi truy vấn tôi chạy nhưng rõ ràng đáng chú ý hơn đối với các truy vấn phức tạp hơn.
Tôi cũng đã thử chạy pgtune, đưa ra khuyến nghị sau với nhiều tham số được điều chỉnh hơn, nhưng điều đó không thay đổi gì cả. Nó gợi ý shared_buffers bằng 1/4 kích thước RAM có vẻ phù hợp với lời khuyên ở nơi khác (và đặc biệt là trên PG wiki).
default_statistics_target = 50
maintenance_work_mem = 960MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 11GB
work_mem = 96MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 3840MB
max_connections = 80
Tôi đã thử lập lại toàn bộ cơ sở dữ liệu sau khi thay đổi cài đặt (sử dụng reindex database), nhưng điều đó cũng không giúp được gì. Tôi đã chơi xung quanh với shared_buffers và work_mem. Dần dần thay đổi chúng từ các giá trị mặc định rất bảo thủ (128k / 1MB) giảm dần hiệu suất.
Tôi đã chạy EXPLAIN (ANALYZE,BUFFERS)trên một vài truy vấn và thủ phạm dường như là Hash Join chậm hơn đáng kể. Tôi không rõ tại sao.
Để đưa ra một số ví dụ cụ thể, tôi có truy vấn sau đây. Nó chạy trong ~ 2100ms trên cấu hình mặc định và ~ 3300ms trên cấu hình với kích thước bộ đệm tăng:
select count(*) from contest c
left outer join contestparticipant cp on c.id=cp.contestId
left outer join teammember tm on tm.contestparticipantid=cp.id
left outer join staffmember sm on cp.id=sm.contestparticipantid
left outer join person p on p.id=cp.personid
left outer join personinfo pi on pi.id=cp.personinfoid
where pi.lastname like '%b%' or pi.firstname like '%a%';
EXPLAIN (ANALYZE,BUFFERS) cho truy vấn trên:
- Bộ đệm mặc định: http://explain.depesz.com/s/xaHJ
- Bộ đệm lớn hơn: http://explain.depesz.com/s/Plk
Câu hỏi là tại sao tôi quan sát hiệu suất giảm khi tôi tăng kích thước bộ đệm? Máy chắc chắn không hết bộ nhớ. Phân bổ nếu bộ nhớ dùng chung trong HĐH là ( shmmaxvà shmall) được đặt thành các giá trị rất lớn, đó không phải là vấn đề. Tôi cũng không nhận được bất kỳ lỗi nào trong nhật ký Postgres. Tôi đang chạy autovacuum trong cấu hình mặc định nhưng tôi không hy vọng điều đó có liên quan đến nó. Tất cả các truy vấn được chạy trên cùng một máy cách nhau vài giây, chỉ với cấu hình đã thay đổi (và PG được khởi động lại).
Chỉnh sửa: Tôi chỉ tìm thấy một sự thật đặc biệt thú vị: khi tôi thực hiện thử nghiệm tương tự trên iMac giữa năm 2010 (OSX 10.7.5) của tôi với Postgres 9.2.1 và RAM 16GB, tôi không gặp phải tình trạng chậm. Đặc biệt:
set work_mem='1MB';
select ...; // running time is ~1800 ms
set work_mem='96MB';
select ...' // running time is ~1500 ms
Khi tôi thực hiện chính xác cùng một truy vấn (ở trên) với cùng một dữ liệu trên máy chủ, tôi nhận được 2100 ms với work_mem = 1MB và 3200 ms với 96 MB.
Mac có SSD nên nhanh hơn một cách dễ hiểu, nhưng nó thể hiện một hành vi mà tôi mong đợi.
Xem thêm các cuộc thảo luận tiếp theo về hiệu suất pssql .