Hôm nay là hạn chót cho giá phòng đặc biệt tại khách sạn đăng cai tổ chức Hội nghị PostgreSQL East 2010. Nếu bạn đang trì hoãn việc đặt chỗ tại hội nghị, kể từ ngày mai, giá phòng sẽ bắt đầu khiến bạn phải trả giá.
Buổi nói chuyện của tôi là về Đo điểm chuẩn phần cứng cơ sở dữ liệu và được lên lịch vào cuối buổi chiều ngày đầu tiên, thứ Năm ngày 25 tháng 3. Những người có thể đã xem buổi nói chuyện này trước đây, hoặc trực tiếp tại PGCon 2009 hoặc qua liên kết video có sẵn ở đó, có thể sẽ tự hỏi liệu tôi có định lôi các trang trình bày đó ra và nói lại hay không. Không phải trường hợp; trong khi triết lý chung của bài nói chuyện ("không tin tưởng ai, chạy điểm chuẩn của riêng bạn") vẫn giữ nguyên, các ví dụ và kết hợp thử nghiệm được đề xuất đã được cập nhật để phản ánh những tiến bộ phần cứng đáng giá trong một năm nữa, công việc PostgreSQL và nghiên cứu của riêng tôi trong suốt thời gian đó thời gian. Tình hình Intel và AMD nói riêng đã thay đổi khá nhiều, đòi hỏi một bộ tiêu chuẩn bộ nhớ mới để thực sự theo sát những gì đang diễn ra hiện nay.
Và PostgreSQL 9.0 đã khắc phục một sự cố lớn khiến nó không thể bình thường cung cấp kết quả chính xác trên Linux, do hồi quy hạt nhân khiến tình trạng đã quá phổ biến trở nên tồi tệ hơn nhiều:rất dễ để một ứng dụng khách pgbench duy nhất trở thành nút cổ chai khi chạy nó, thay vì hơn chính cơ sở dữ liệu. Bài đánh giá mà tôi đã thực hiện đối với pgbench đa luồng (cũng có thể là pgbench đa quy trình trên các hệ thống không hỗ trợ luồng) cho thấy tốc độ tăng nhanh> 30% ngay cả trên các hệ thống không có khả năng tương thích hạt nhân xấu trên chúng. Thử nghiệm tiếp theo cho thấy có thể dễ dàng mất 8 quy trình pgbench để có được thông lượng đầy đủ từ các bộ xử lý hiện đại thậm chí rẻ tiền trong các nhân Linux gần đây. Tôi sẽ xem xét chính xác cách mà nó kết thúc diễn ra trên các hệ thống như vậy và cách tính năng mới này giúp bạn có thể sử dụng lại pgbench làm cách chính để đo hiệu suất CPU khi chạy cơ sở dữ liệu.
Gần đây, tôi cũng đã cập nhật git repo cho pgbench-tools bổ sung hỗ trợ làm việc cho PostgreSQL 8.4 và khả năng tương thích cơ bản 9.0 và bản cập nhật tiếp theo sẽ bao gồm hỗ trợ cho tùy chọn đa luồng. cần phải làm việc. Điều này là tất cả dẫn đầu ở đâu đó. Sau khi chúng tôi có các phép đo chính xác cho hiệu suất PostgreSQL bị giới hạn bởi CPU ở phía máy chủ, một điều không thường xảy ra trong hơn hai năm nay, những phép đo đó lại trở thành một cách hữu ích để theo dõi sự hồi quy hiệu suất trong cơ sở mã PostgreSQL. Các bài kiểm tra được bao gồm sẽ cần phải mở rộng để bao gồm nhiều hơn cuối cùng, nhưng hiện tại chúng tôi đã đạt đến điểm mà pgbench có thể được sử dụng để tìm các hồi quy ảnh hưởng đến tốc độ thực thi của các câu lệnh SELECT đơn giản. Tôi biết rằng điều đó hoạt động như mong đợi, bởi vì mỗi lần tôi vô tình tạo PostgreSQL với các xác nhận về điều đó bị bắt gặp vì tôi thấy tốc độ xử lý trung bình giảm đáng kể.
Sau khi tôi đã thiết lập một số hệ thống ở đây để kiểm tra các hồi quy như vậy, câu hỏi sẽ trở thành làm thế nào để tự động hóa những gì tôi đang làm và sau đó làm điều tương tự với phạm vi kiểm tra bản dựng rộng hơn. Lý tưởng nhất là bạn có thể xem biểu đồ về hiệu suất SELECT trung bình mỗi ngày, được chia nhỏ theo phiên bản, để khi đưa ra một cam kết làm giảm nó, bạn sẽ thấy rõ ngay khi hiệu suất giảm. Đây là mục tiêu mơ ước để xây dựng một trang trại hiệu suất tương tự như buildfarm PostgreSQL. Các phần gần như tất cả với nhau bây giờ:các phần pgbench của tôi đang kết thúc, các phần mở rộng cho buildfarm để làm cho nó nói trực tiếp với git đang di chuyển (không phải là một yêu cầu, nhưng không ai làm việc trong dự án này muốn sử dụng CVS nếu chúng ta có thể tránh nó) và điều chính còn thiếu ở thời điểm này là ai đó dành thời gian để tích hợp những gì tôi đang làm vào một ứng dụng khách giống như buildfarm.
Và có vẻ như chúng tôi hiện có một nhà tài trợ doanh nghiệp sẵn sàng giúp đỡ phần công việc đó, người mà tôi sẽ ghi công khi chúng tôi hoàn thành công việc và điều đó dự kiến sẽ diễn ra vào mùa hè này. Tôi hoàn toàn mong đợi rằng sự phát triển PostgreSQL 9.1 và bản sao lưu 9.0, sẽ xảy ra với một trang trại hiệu suất sớm tại chỗ để bảo vệ chống lại sự thụt lùi hiệu suất. Nếu chúng tôi có thể backport pgbench đa luồng mới sang các phiên bản PostgreSQL cũ hơn, chúng tôi cũng có thể đưa chúng vào hỗn hợp. Tôi đã có một backport của 8.3 pgbench, có rất nhiều cải tiến, tôi duy trì chỉ để thử nghiệm các hệ thống 8.2. Với pgbench là một mô-đun đóng góp khá độc lập, bạn có thể tạo một mô-đun mới hơn khác với phần còn lại của hệ thống, miễn là nó không mong đợi các tính năng cơ sở dữ liệu mới hơn cũng tồn tại.
Nếu đó là điều bạn quan tâm, bài nói chuyện của tôi tại hội nghị sẽ vạch ra những nền tảng mà tôi mong đợi sẽ xây dựng nó. Dù vậy, hy vọng bạn có thể tham dự hội nghị và tận hưởng danh sách dài các cuộc nói chuyện được trình bày ở đó.
