Tôi duy trì một số dự án có mục đích trong cuộc sống là làm cho các phần thử nghiệm của PostgreSQL dễ dàng hơn. Tất cả những thứ này đều được nâng cấp khá trong tuần trước.
mở rộng luồng kiểm tra tốc độ bộ nhớ tăng lên như thế nào trên các máy chủ khi nhiều lõi hơn được sử dụng. Đó là dữ liệu hấp dẫn, đủ để bắt đầu thấy một số xu hướng thực sự. Bây giờ nó hoạt động chính xác trên các hệ thống có số lượng lớn bộ nhớ cache của CPU, vì chúng có nhiều lõi. Trước đây, có thể nó đã rất tích cực trong việc định cỡ tập hợp thử nghiệm để tránh tác động của bộ nhớ cache đến mức nó sử dụng nhiều bộ nhớ hơn mức có thể được phân bổ với thiết kế hiện tại của mã luồng. Điều đó đã được thu nhỏ lại. Nếu bạn có máy chủ lõi 48 trở lên, tôi có thể sử dụng thêm một số thử nghiệm đối với mã mới này để xem liệu cách mới mà tôi xử lý điều này có hợp lý hay không.
peg là một tập lệnh tôi đã viết để giúp dễ dàng hơn trong việc xây dựng PostgreSQL từ nguồn, thường dành cho công việc của nhà phát triển hoặc để tạm thời thử một phiên bản mới hơn trên hệ thống sản xuất. Rất dễ bị nhầm lẫn với việc chuyển đổi giữa các dự án và các nhánh git liên quan của chúng trước đây; tài liệu về lĩnh vực này được cải thiện nhiều.
pgbench-tools là công cụ kiểm tra hiệu suất của tôi, cho phép bạn xếp hàng các ngày có giá trị điểm chuẩn và sau đó có đủ công cụ phân tích để hiểu về nó. Chương trình hiện theo dõi tham số pg_stat_bgwriter.buffers_backend_fsync được giới thiệu gần đây nếu bạn có phiên bản hỗ trợ nó (hiện tại chỉ là bản dựng soure gần đây – đưa chúng ta trở lại lý do tại sao chốt lại hữu ích). Bạn cũng có thể yêu cầu nó chạy từng bài kiểm tra trong một khoảng thời gian cố định, điều này làm cho việc kiểm tra ở các giá trị kích thước / ứng dụng khách rất khác nhau trở nên dễ dàng hơn nhiều.
Theo như những gì bạn có thể làm với pgbench-tools… cho đến hôm nay, tôi đang chia sẻ các bài kiểm tra điểm chuẩn mà tôi đang thực hiện trên PostgreSQL 9.1 trên máy chủ mạnh nhất mà tôi có quyền sử dụng không giới hạn. 8 lõi, RAM 16 GB, ổ cơ sở dữ liệu RAID-0 3 đĩa, ổ WAL 1 đĩa, bộ nhớ đệm được hỗ trợ bởi pin Areca. Bạn có thể xem kết quả. Các lần chạy được tổ chức thành các nhóm thử nghiệm, mỗi nhóm đại diện cho một số loại thay đổi đối với cấu hình. Ví dụ:# 1 trong dữ liệu này chỉ đang chạy SELECT, # 2 đang chạy TPC-B-like nhưng với 8GB RAM và mã ealrier, trong khi thứ nóng là # 3, chạy TPC-B với 16GB RAM và mã đó theo dõi buffers_backend_fsyncs.
Có một số bản vá trong hàng đợi PostgreSQL 9.1 liên quan đến hiệu suất trong các khu vực được đánh dấu bởi các kết quả này – rằng Linux có thể có độ trễ cực kỳ cao trong trường hợp xấu nhất khi tải cơ sở dữ liệu nhiều ghi. Một ví dụ trung bình tốt là thử nghiệm 215:quy mô 1000, 32 khách hàng, 365 TPS., Nhưng độ trễ trong trường hợp xấu nhất là 43 giây và bạn có thể thấy các điểm chết trong biểu đồ TPS. Điều đó thật khủng khiếp và có một vài khái niệm đang trôi nổi về cách thực hiện điều đó.
Nếu bất kỳ ai đang đọc bài viết này có một máy chủ mạnh mẽ có sẵn trong vài tuần để chạy các thử nghiệm như thế này, tôi rất vui được giúp bạn tái tạo môi trường này và xem bạn thấy loại kết quả nào. Điều kỳ diệu duy nhất tôi có là một số thực hành về cách đặt tỷ lệ và tải khách hàng để bạn không mất nhiều thời gian cho các thử nghiệm không hiệu quả. Toàn bộ quy trình còn lại của tôi đều miễn phí và được lập thành tài liệu.
