Đầu tiên, luôn sử dụng phiên bản PostgreSQL mới nhất. Các cải tiến về hiệu suất luôn đến, vì vậy có thể bạn đang lãng phí thời gian của mình nếu đang điều chỉnh phiên bản cũ. Ví dụ:PostgreSQL 9.2 cải thiện đáng kể tốc độ của TRUNCATE và tất nhiên thêm các bản quét chỉ lập chỉ mục. Ngay cả những bản phát hành nhỏ cũng phải luôn được tuân theo; xem chính sách phiên bản.
Không nên
Đ KHÔNG đặt một vùng bảng trên đĩa RAM hoặc bộ lưu trữ không bền khác.
Nếu bạn mất một vùng bảng, toàn bộ cơ sở dữ liệu có thể bị hỏng và khó sử dụng nếu không có công việc quan trọng. Điều này có rất ít lợi ích so với việc chỉ sử dụng UNLOGGED bảng và vẫn có nhiều RAM cho bộ nhớ cache.
Nếu bạn thực sự muốn một hệ thống dựa trên đĩa ram, hãy initdb một cụm hoàn toàn mới trên đĩa ram bởi initdb nhập một phiên bản PostgreSQL mới trên đĩa ram, vì vậy bạn có một phiên bản PostgreSQL dùng một lần hoàn toàn.
Cấu hình máy chủ PostgreSQL
Khi thử nghiệm, bạn có thể định cấu hình máy chủ của mình để hoạt động không bền nhưng nhanh hơn.
Đây là một trong những cách sử dụng được chấp nhận duy nhất cho fsync=off cài đặt trong PostgreSQL. Cài đặt này cho phép PostgreSQL không bận tâm đến việc ghi theo thứ tự hoặc bất kỳ thứ gì trong số những thứ khó chịu khác về bảo vệ toàn vẹn dữ liệu và an toàn khi gặp sự cố, cho phép nó hoàn toàn thùng rác dữ liệu của bạn nếu bạn bị mất điện hoặc gặp sự cố hệ điều hành.
Không cần phải nói, bạn không bao giờ được bật fsync=off trong sản xuất trừ khi bạn đang sử dụng Pg làm cơ sở dữ liệu tạm thời cho dữ liệu mà bạn có thể tạo lại từ nơi khác. Nếu và chỉ khi bạn tắt fsync thì cũng có thể tắt full_page_writes tắt, vì nó không còn hoạt động tốt nữa. Lưu ý rằng fsync=off và full_page_writes nộp đơn tại cụm cấp, vì vậy chúng ảnh hưởng đến tất cả cơ sở dữ liệu trong phiên bản PostgreSQL của bạn.
Để sử dụng trong sản xuất, bạn có thể sử dụng synchronous_commit=off và đặt commit_delay , vì bạn sẽ nhận được nhiều lợi ích giống như fsync=off mà không có nguy cơ tham nhũng dữ liệu khổng lồ. Bạn có một cửa sổ nhỏ về việc mất dữ liệu gần đây nếu bạn bật cam kết không đồng bộ - nhưng chỉ có vậy.
Nếu bạn có tùy chọn thay đổi một chút DDL, bạn cũng có thể sử dụng UNLOGGED các bảng trong Pg 9.1+ để tránh hoàn toàn việc ghi nhật ký WAL và tăng tốc độ thực với chi phí là các bảng sẽ bị xóa nếu máy chủ gặp sự cố. Không có tùy chọn cấu hình nào để mở khóa tất cả các bảng, nó phải được đặt trong quá trình CREATE TABLE . Ngoài việc tốt cho việc kiểm tra, điều này rất hữu ích nếu bạn có các bảng chứa đầy dữ liệu được tạo hoặc không quan trọng trong cơ sở dữ liệu có chứa những thứ bạn cần để đảm bảo an toàn.
Kiểm tra nhật ký của bạn và xem liệu bạn có nhận được cảnh báo về quá nhiều điểm kiểm tra hay không. Nếu đúng như vậy, bạn nên tăng thêm các phân đoạn điểm kiểm tra của mình. Bạn cũng có thể muốn điều chỉnh checkpoint_completion_target của mình để viết trơn tru.
Điều chỉnh shared_buffers để phù hợp với khối lượng công việc của bạn. Điều này phụ thuộc vào hệ điều hành, phụ thuộc vào những gì khác đang xảy ra với máy của bạn và yêu cầu một số thử nghiệm và lỗi. Các giá trị mặc định là cực kỳ thận trọng. Bạn có thể cần tăng giới hạn bộ nhớ dùng chung tối đa của hệ điều hành nếu bạn tăng shared_buffers trên PostgreSQL 9.2 trở xuống; 9.3 trở lên đã thay đổi cách họ sử dụng bộ nhớ dùng chung để tránh điều đó.
Nếu bạn chỉ sử dụng một vài kết nối thực hiện nhiều công việc, hãy tăng work_mem để cung cấp cho họ nhiều RAM hơn để chơi các loại, v.v. Hãy coi chừng work_mem quá cao cài đặt có thể gây ra sự cố hết bộ nhớ vì nó theo kiểu sắp xếp không phải trên mỗi kết nối nên một truy vấn có thể có nhiều kiểu lồng nhau. Bạn chỉ thực sự phải tăng work_mem nếu bạn có thể thấy các loại tràn ra đĩa trong EXPLAIN hoặc ghi lại bằng log_temp_files cài đặt (được khuyến nghị), nhưng giá trị cao hơn cũng có thể cho phép Pg chọn các kế hoạch thông minh hơn.
Như đã nói bởi một người đăng khác ở đây, thật khôn ngoan nếu đặt xlog và các bảng / chỉ mục chính trên các ổ cứng riêng biệt nếu có thể. Các phân vùng riêng biệt là khá vô nghĩa, bạn thực sự muốn có các ổ đĩa riêng biệt. Sự tách biệt này ít có lợi hơn nhiều nếu bạn đang chạy với fsync=off và hầu như không có nếu bạn đang sử dụng UNLOGGED bảng.
Cuối cùng, điều chỉnh các truy vấn của bạn. Đảm bảo rằng random_page_cost của bạn và seq_page_cost phản ánh hiệu suất hệ thống của bạn, đảm bảo effective_cache_size của bạn đúng, v.v. Sử dụng EXPLAIN (BUFFERS, ANALYZE) để kiểm tra các kế hoạch truy vấn riêng lẻ và biến auto_explain trên để báo cáo tất cả các truy vấn chậm. Bạn thường có thể cải thiện đáng kể hiệu suất truy vấn chỉ bằng cách tạo chỉ mục thích hợp hoặc điều chỉnh các thông số chi phí.
AFAIK không có cách nào để đặt toàn bộ cơ sở dữ liệu hoặc cụm là UNLOGGED . Thật là thú vị nếu có thể làm như vậy. Cân nhắc hỏi về danh sách gửi thư PostgreSQL.
Điều chỉnh hệ điều hành máy chủ
Bạn cũng có thể thực hiện một số điều chỉnh ở cấp hệ điều hành. Điều chính bạn có thể muốn làm là thuyết phục hệ điều hành không xả quá nhiều ghi vào đĩa, vì bạn thực sự không quan tâm khi nào / nếu chúng chuyển nó vào đĩa.
Trong Linux, bạn có thể kiểm soát điều này bằng dirty_* của hệ thống con bộ nhớ ảo cài đặt, như dirty_writeback_centisecs .
Vấn đề duy nhất khi điều chỉnh cài đặt ghi lại quá chậm là việc một số chương trình khác xả ra có thể khiến tất cả các bộ đệm tích lũy của PostgreSQL cũng bị xóa, gây ra sự cố lớn trong khi mọi thứ bị chặn khi ghi. Bạn có thể giảm bớt điều này bằng cách chạy PostgreSQL trên một hệ thống tệp khác, nhưng một số lỗi có thể là cấp thiết bị hoặc cấp toàn bộ máy chủ lưu trữ không phải cấp hệ thống tệp, vì vậy bạn không thể dựa vào đó.
Việc điều chỉnh này thực sự đòi hỏi bạn phải thử với các cài đặt để xem những gì phù hợp nhất với khối lượng công việc của bạn.
Trên các hạt nhân mới hơn, bạn có thể muốn đảm bảo rằng vm.zone_reclaim_mode được đặt thành 0, vì nó có thể gây ra các vấn đề hiệu suất nghiêm trọng với hệ thống NUMA (hầu hết các hệ thống hiện nay) do tương tác với cách PostgreSQL quản lý shared_buffers .
Truy vấn và điều chỉnh khối lượng công việc
Đây là những điều DO yêu cầu thay đổi mã; chúng có thể không phù hợp với bạn. Một số điều bạn có thể áp dụng.
Nếu bạn không phân chia công việc thành các giao dịch lớn hơn, hãy bắt đầu. Rất nhiều giao dịch nhỏ rất tốn kém, vì vậy bạn nên thực hiện theo lô bất cứ khi nào có thể và thực tế để làm như vậy. Nếu bạn đang sử dụng cam kết không đồng bộ, điều này ít quan trọng hơn, nhưng vẫn rất được khuyến khích.
Bất cứ khi nào có thể, hãy sử dụng các bảng tạm thời. Chúng không tạo ra lưu lượng truy cập WAL, vì vậy chúng nhanh hơn rất nhiều cho việc chèn và cập nhật. Đôi khi, việc chuyển một loạt dữ liệu vào một bảng tạm thời, thao tác nó theo cách bạn cần, sau đó thực hiện INSERT INTO ... SELECT ... để sao chép nó vào bảng cuối cùng. Lưu ý rằng các bảng tạm thời là mỗi phiên; nếu phiên của bạn kết thúc hoặc bạn mất kết nối thì bảng tạm thời sẽ biến mất và không kết nối nào khác có thể xem nội dung của (các) bảng tạm thời của phiên.
Nếu bạn đang sử dụng PostgreSQL 9.1 hoặc mới hơn, bạn có thể sử dụng UNLOGGED bảng cho dữ liệu mà bạn có thể để mất, chẳng hạn như trạng thái phiên. Chúng được hiển thị trên các phiên khác nhau và được lưu giữ giữa các kết nối. Chúng sẽ bị cắt bớt nếu máy chủ tắt không sạch để chúng không thể được sử dụng cho bất kỳ thứ gì bạn không thể tạo lại, nhưng chúng tuyệt vời cho bộ nhớ đệm, dạng xem cụ thể hóa, bảng trạng thái, v.v.
Nói chung, đừng DELETE FROM blah; . Sử dụng TRUNCATE TABLE blah; thay thế; sẽ nhanh hơn rất nhiều khi bạn đổ tất cả các hàng trong một bảng. Cắt bớt nhiều bảng trong một TRUNCATE gọi nếu bạn có thể. Có một lưu ý nếu bạn đang thực hiện nhiều TRUNCATES của các bảng nhỏ lặp đi lặp lại, tuy nhiên; xem:Tốc độ cắt bỏ Postgresql
Nếu bạn không có chỉ mục trên khóa ngoại, hãy DELETE liên quan đến các khóa chính được tham chiếu bởi các khóa ngoại đó sẽ chậm kinh khủng. Đảm bảo tạo các chỉ mục như vậy nếu bạn muốn DELETE từ (các) bảng được tham chiếu. Chỉ mục không bắt buộc đối với TRUNCATE .
Không tạo chỉ mục bạn không cần. Mỗi chỉ số có một chi phí duy trì. Cố gắng sử dụng một tập hợp chỉ mục tối thiểu và để quét chỉ mục bitmap kết hợp chúng thay vì duy trì quá nhiều chỉ mục nhiều cột khổng lồ, đắt tiền. Ở những nơi bắt buộc phải có chỉ mục, hãy cố gắng điền vào bảng trước, sau đó tạo chỉ mục ở cuối.
Phần cứng
Có đủ RAM để chứa toàn bộ cơ sở dữ liệu là một chiến thắng lớn nếu bạn có thể quản lý nó.
Nếu bạn không có đủ RAM, bộ nhớ càng nhanh càng tốt. Ngay cả một ổ SSD giá rẻ cũng tạo ra sự khác biệt lớn so với gỉ sét. Tuy nhiên, đừng tin tưởng vào những ổ SSD giá rẻ để sản xuất, chúng thường không an toàn và có thể ăn dữ liệu của bạn.
Học tập
Cuốn sách của Greg Smith, Hiệu suất cao PostgreSQL 9.0 vẫn có liên quan mặc dù đề cập đến một phiên bản cũ hơn một chút. Nó phải là một tài liệu tham khảo hữu ích.
Tham gia danh sách gửi thư chung PostgreSQL và theo dõi nó.
Đọc:
- Điều chỉnh máy chủ PostgreSQL của bạn - PostgreSQL wiki
- Số lượng kết nối cơ sở dữ liệu - PostgreSQL wiki
