PostgreSQL tối đa hóa hiệu năng SSD


19

Tôi sẽ có một cơ sở dữ liệu PostgreQuery 9.3 khổng lồ với nhiều bảng với hơn 100 triệu mục trên mỗi bảng. Cơ sở dữ liệu này về cơ bản sẽ ở chế độ chỉ đọc (một khi tôi điền vào tất cả các bảng cần thiết và xây dựng các chỉ mục không còn thao tác ghi trên DB) và truy cập người dùng đơn (chạy và đánh giá nhiều truy vấn từ localhost), vì DB sẽ được sử dụng Chỉ cho mục đích nghiên cứu. Các truy vấn sẽ luôn sử dụng THAM GIA trên các trường DB nguyên.

Tôi có thể sẽ mua một ổ SSD (256-512GB) cho mục đích này. Tôi chưa từng sử dụng SSD cho DB trước đây, vậy tôi có sợ điều gì không? Tôi có thể đặt toàn bộ DB trên SSD hay chỉ các chỉ mục? Có lời khuyên / hướng dẫn cụ thể nào cần thiết để điều chỉnh PostgreSQL cho SSD không? Lưu ý rằng tôi có một máy trạm tốt với i7 và 32Gb RAM, vì vậy có lẽ bạn cũng có thể cung cấp một số lời khuyên ở đó.

Câu trả lời:


16

Vì vậy, có gì tôi nên sợ?

Không có bản sao lưu. Giống như bất kỳ thiết bị lưu trữ, nó có thể chết. Giữ bản sao lưu.

Nếu việc tải dữ liệu sẽ mất nhiều thời gian, tôi sẽ sao lưu db chỉ đọc một khi tôi đã thực hiện tải dữ liệu, bằng cách dừng nó và sao chép nó. Theo cách đó, nếu có sự cố xảy ra, việc tạo lại sau này sẽ dễ dàng hơn.

Tôi có thể đặt toàn bộ DB trên SSD hay chỉ các chỉ mục?

Nếu nó phù hợp, lưu trữ toàn bộ DB.

Nếu không, hãy đặt một vùng bảng trên SSD và sử dụng nó để lưu trữ các chỉ mục và càng nhiều bảng được yêu cầu nhiều sẽ phù hợp.

Có lời khuyên / hướng dẫn cụ thể nào cần thiết để điều chỉnh PostgreSQL cho SSD không?

Hầu hết các lợi ích của SSD là cho tải ghi OLTP. Ưu điểm chính cho tải chỉ đọc là tìm kiếm nhanh, và slardiere đã che đậy điều đó.

Bạn có thể muốn thiết lập effective_io_concurrency = 5hoặc một cái gì đó để phản ánh thực tế rằng SSD có thể thực hiện các thao tác đọc ngẫu nhiên nhanh, nhiều đường ống ... nhưng nó chỉ ảnh hưởng đến việc quét chỉ mục bitmap và trong thực tế random_page_costđã kết hợp điều đó.

Đối với tải chỉ đọc, nó không tạo ra sự khác biệt.

Đối với tải dữ liệu ban đầu, xem:

Lưu ý rằng tôi có một máy trạm tốt với i7 và 32Gb RAM, vì vậy có lẽ bạn cũng có thể cung cấp một số lời khuyên ở đó.

Đặt lớn maintenance_work_memcho tải dữ liệu. Tôi sẽ sử dụng ít nhất 8GB.

Đặt một lớn work_memcho công việc truy vấn. Kích thước phù hợp phụ thuộc một chút vào độ phức tạp của truy vấn. Bắt đầu với 500MBvà đi lên từ đó.

Tăng số lượng của bạn checkpoint_segments(ồ ạt) cho tải dữ liệu ban đầu.

Hãy nhớ tắt VM overcommit! (xem hướng dẫn sử dụng PostgreSQL: http://www.postgresql.org/docs/civerse/static/kernel-resource.html )


22

Về SSD, lời khuyên chính là hạ 'Random_page_cost' xuống 1 (bằng với 'seq_page_cost') trong postgresql.conf, ngoài các cài đặt thông thường khác.


Có lẽ cả hai giá trị phải nhỏ hơn 1.0, theo postgresql.org/docs/11/ trên : "Bạn có thể tăng hoặc giảm cả hai giá trị với nhau để thay đổi mức độ quan trọng của chi phí I / O của đĩa so với chi phí CPU, được mô tả bởi các thông số sau ".
Kirill Bulygin
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.