điều chỉnh postgresql cho số lượng lớn ram

Tôi có hai máy chủ giống hệt nhau (về phần cứng), cả hai đều là cài đặt tiêu chuẩn của windows server 2008 r2, với phần mềm tối thiểu được cài đặt (về cơ bản là mã của tôi và các công cụ bắt buộc như jvm, v.v.).

Trên một máy chủ, tôi đang chạy máy chủ sql 2005, trên máy chủ thứ hai postgresql 9.1. Sự khác biệt về hiệu suất của 2 máy chủ này là đáng kinh ngạc, thật tệ cho postgresql đến nỗi tôi đang hối hận về bài phát biểu "hãy sử dụng postgresql ban đầu thay vì trả tiền cho giấy phép máy chủ sql" cho sếp của tôi. Chúng ta đang nói về sự khác biệt của 30 giây so với 15 phút cho cùng một lệnh và đó không chỉ là một lệnh này, đó là bất kỳ truy vấn hoặc lệnh nào tôi ném vào nó. Cả hai đều có khá nhiều dữ liệu giống nhau (các bản ghi được chèn theo thứ tự khác nhau) và cả hai cơ sở dữ liệu đều có cùng cấu trúc / chỉ mục, v.v.

Nhưng tôi hy vọng nó chỉ là vấn đề điều chỉnh hiệu suất. Vấn đề là, máy chủ sql sử dụng khá nhiều tất cả 32 hợp đồng ram trên máy chủ, trong khi postgresl không sử dụng gì, chắc chắn là ít hơn một hợp đồng mặc dù tôi chưa thực sự tìm ra chi tiết tốt.

Làm cách nào để tôi có được postgresql để sử dụng hơn 20 hợp đồng ram? Các máy chủ này được xây dựng riêng cho công cụ cơ sở dữ liệu này, do đó, bất kỳ ram nào không được sử dụng bởi cơ sở dữ liệu và các quy trình hỗ trợ đều bị lãng phí theo quan điểm của tôi.

Có nhiều hằng số có thể điều chỉnh, được khởi tạo thông qua postgres.conf. Những cái quan trọng nhất là:

• max_connections: số lượng phiên đồng thời
• work_mem : số lượng bộ nhớ tối đa được sử dụng cho các kết quả trung gian như bảng băm và để sắp xếp
• shared_buffers dung lượng bộ nhớ dành riêng cho không gian bộ đệm 'được ghim'.
• effective_cache_size dung lượng bộ nhớ giả định được sử dụng bởi bộ đệm LRU của HĐH.
• random_page_cost : một ước tính cho chi phí tương đối của tìm kiếm đĩa.

max_connectionskhông nên được đặt cao hơn mức cần thiết, kết nối tốn tài nguyên ngay cả khi không hoạt động; trong hầu hết các trường hợp, một kết nối sẽ dành nhiều thời gian chờ đợi bên trong hơn là chờ đợi bên ngoài. (với mức giá tương tranh) Một công thức quy tắc tốt là "số lượng trục chính + số lượng bộ xử lý + X"

work_memlà khó khăn: có thể được áp dụng cho mọi truy vấn con, do đó, một truy vấn có 5 HASHJOINScó thể tốn 5 * work_mem. Và đối với các trường hợp xấu nhất, bạn cũng nên nghĩ đến việc nhiều phiên tiêu thụ số tiền này (một lần nữa là một lý do để giữ max_connectionsở mức thấp).

shared_buffersđược (IMHO) đánh giá quá cao. Thông thường nên cài đặt khoảng 1/4 ... 1/2 tất cả bộ nhớ "miễn phí" có sẵn, nhưng tôi có xu hướng giữ nó ở mức thấp và đặt effective_cache_sizethành tất cả bộ nhớ "miễn phí" có sẵn.

random_page_costlà chi phí cho tìm kiếm + đọc trên đĩa. Nó tương đối với sequential_disk_cost, là 1. Mặc định (4) cho random_page_costđược đặt quá cao cho các máy hiện đại và lưu trữ mạng, thông thường nó có thể được hạ xuống từ 2 đến 1.x. Đối với các ổ đĩa SSD, bạn thậm chí đặt nó thành 1.0, vì việc tìm kiếm gần như miễn phí trên SSD.

Cân nhắc sử dụng pgtune để giúp bạn điều chỉnh cấu hình PostgreSQL. Từ PGFoundry:

pgtune lấy postgresql.conf mặc định wimpy và mở rộng máy chủ cơ sở dữ liệu mạnh như phần cứng mà nó đang được triển khai trên

Cấu hình mặc định của PostgreSQL rất bảo thủ và công cụ đó nhằm giúp giải quyết tình huống chính xác này. Các tài liệu là một đọc nhẹ và sử dụng công cụ là khá đơn giản.

Hãy nhớ rằng không cần phải sử dụng các đề xuất chính xác của pgtune. Chơi với các cài đặt của nó và xem các thay đổi kết quả đối với tệp conf sẽ cho bạn hiểu rõ hơn về cấu hình của PostgreQuery và cách điều chỉnh thủ công.

Nếu mọi truy vấn hoặc lệnh đang chạy chậm, tôi nghi ngờ rằng:

• bạn kết nối với cơ sở dữ liệu cho mọi truy vấn bạn chạy;
• bạn đã cấu hình một số loại phương thức xác thực, không hoạt động và nó tạm dừng các truy vấn của bạn cho đến khi phương thức xác thực cụ thể này hết thời gian.

Bạn có thể vui lòng cho chúng tôi biết cần bao nhiêu thời gian để chạy một truy vấn như thế select version()nào không? Nếu nên ngay lập tức (0,16ms trên máy trạm của tôi).

Nếu MỌI truy vấn là chậm hơn nhiều thì một cái gì đó là sai lầm khủng khiếp với máy chủ hoặc một cái gì đó. Theo kinh nghiệm của tôi, mỗi db có một vài điều tốt hơn so với những thứ khác, nhưng pssql thông minh hiệu năng dễ dàng ở cùng một lĩnh vực với máy chủ mssql.

Vì vậy, những gì hệ điều hành bạn đang chạy pssql trên? Phần cứng gì? Bạn đã thay đổi cài đặt nào? Dữ liệu của bạn lớn như thế nào? Ví dụ về truy vấn kém và đầu ra của phân tích giải thích (Chạy truy vấn của bạn như thế này:

giải thích phân tích chọn ... phần còn lại của truy vấn ở đây ...;

Đăng kết quả đầu ra lên http://explain.depesz.com/ và đăng liên kết tại đây.