Tiếp theo là Tuning Linux vào tháng trước cho Độ trễ PostgreSQL thấp, hiện đã có một đống thử nghiệm khổng lồ được thực hiện trên hai hệ thống tệp, ba bản vá và hai bộ thông số điều chỉnh hạt nhân đang chạy. Kết quả cho đến nay là một số dữ liệu mới thú vị và một số cải tiến được cam kết trong lĩnh vực này hiện có trong PostgreSQL 9.1 (tổng cộng có ba dữ liệu, hai cải tiến còn lại đang theo dõi các bản vá). Tôi sẽ nói về phương pháp thực hành được đề xuất vào tháng tới trong một buổi nói chuyện của tôi tại PostgreSQL East và tôi cũng đã gửi một số thứ trong lĩnh vực này cho May’s PGCon. Ở đây tôi cũng sẽ nói thêm một chút về những ngõ cụt, trong khi những ký ức đó vẫn còn nguyên vẹn.
Vấn đề cơ bản ở đây là cách PostgreSQL sử dụng bộ đệm của hệ điều hành khi viết cho phép tích lũy một lượng lớn dữ liệu. Kết quả khi các điểm kiểm tra cơ sở dữ liệu kết thúc có thể là sự chậm trễ lâu dài trong khi chờ dữ liệu đó được ghi. Hóa ra chương trình pgbench đi kèm với PostgreSQL thực sự tốt trong việc tạo ra vấn đề này, vì vậy đó là những gì tôi đã sử dụng cho tất cả các bài kiểm tra. Phương tiện các câu hỏi tôi đặt ra để trả lời là:
- Việc thay đổi từ hệ thống tệp ext3 cũ có thực sự cho thấy sự cải thiện hiệu suất đối với các tác vụ cơ sở dữ liệu không? Tôi đã viết vài điều về Sự trở lại của XFS trên Linux vào năm ngoái cho thấy một sự cải thiện tốt đẹp về các điểm chuẩn đơn giản. Tuy nhiên, điều đó không phải lúc nào cũng chuyển thành các cải tiến cơ sở dữ liệu.
- Các phiên bản Linux dirty_bytes và dirty_background_bytes gần đây có thực sự cải thiện độ trễ trong trường hợp xấu nhất không?
- Thay đổi cơ sở dữ liệu nào được đề xuất để cải thiện hành vi ở đây thực sự hoạt động?
Bạn có thể xem tất cả các kết quả thử nghiệm nếu bạn muốn kiểm tra dữ liệu thô. Những gì đã thay đổi cho mỗi bộ thử nghiệm được ghi lại và nếu bạn đi sâu vào một thử nghiệm riêng lẻ, bạn có thể thấy các thông số cơ sở dữ liệu được sử dụng và một số thông tin hệ điều hành cơ bản khác. Trang web đó là những gì đến từ chương trình thử nghiệm công cụ pgbench của tôi, nếu bạn muốn tự mình thử loại điều này.
Kết quả không quá ngạc nhiên, nhưng chúng rất thú vị. Tất cả các bài kiểm tra ở đây đã được thực hiện với hai kích thước cơ sở dữ liệu. Ở kích thước cơ sở dữ liệu nhỏ hơn (scale =500, cơ sở dữ liệu khoảng 8GB dễ dàng phù hợp với 16GB RAM của máy chủ), ext3 quản lý 690 giao dịch / giây, trong khi ở kích thước gấp đôi (scale =1000, cơ sở dữ liệu khoảng 16GB) thì nhiều hơn nữa tìm kiếm bị ràng buộc và chỉ được quản lý 349 TPS. XFS đã tăng hai con số đó lên 1757 TPS và 417 TPS – lần lượt tăng 255% và 19%. Thậm chí tốt hơn, độ trễ trong trường hợp xấu nhất cho một giao dịch đã giảm từ phạm vi 34 đến 56 giây (!) Xuống còn 2 đến 5 giây. Mặc dù 5 giây cũng không phải là tuyệt vời, nhưng đây là một khối lượng công việc tổng hợp được thiết kế để làm cho vấn đề này trở nên thực sự tồi tệ. Số lượng ext3 khủng khiếp đến mức bạn thực sự vẫn có khả năng gặp phải một vấn đề khó chịu ở đây, mặc dù tôi thực sự thấy hành vi trên tệp đó tốt hơn so với những gì tôi đã thấy trong các hạt nhân trước đó (điều này đã được thực hiện với 2.6.32).
Vòng 1:XFS thắng trong một trận đấu long trời lở đất. Tôi không thể giới thiệu ext3 như một hệ thống tệp khả thi trên hệ thống Linux có nhiều bộ nhớ nếu bạn định viết nhiều; nó chỉ không hoạt động trong bối cảnh đó. Máy chủ này chỉ có 16GB RAM, vì vậy bạn có thể hình dung sự cố này tồi tệ như thế nào trên một máy chủ sản xuất nghiêm trọng ở đây vào năm 2011.
Tiếp theo, dirty_bytes và dirty_background_bytes thu nhỏ. Hai điều này đã cải thiện độ trễ khá nhiều trên ext3, với chi phí làm chậm một số. Điều tồi tệ nhất trong số đó, thời gian bảo trì bị chậm lại khi chạy VACUUM, bạn không thấy trong chính kết quả kiểm tra; Tôi đã thảo luận về điều đó trong mục blog trước đó của tôi. Trên XFS, việc điều chỉnh các thông số này xuống là một thảm họa về hiệu suất. Ở quy mô cơ sở dữ liệu nhỏ hơn, hiệu suất TPS giảm 46% và trên hết là độ trễ thực sự trở nên tồi tệ hơn.
Vòng 2:Đừng mong đợi bất kỳ phép màu nào từ dirty_bytes hoặc dirty_background_bytes. Chúng dường như có một số tác dụng tích cực trong một số trường hợp, nhưng mặt trái tiềm ẩn cũng rất lớn. Đảm bảo kiểm tra cẩn thận và bao gồm VACUUM trong thử nghiệm của bạn, trước khi điều chỉnh hai điều này xuống.
Tiếp theo, tôi đã kết thúc đánh giá ba ý tưởng vá cho PostgreSQL như một phần của commitFest cuối cùng này:
- Đồng bộ hóa điểm kiểm tra lan rộng ra đĩa (fsync) gọi ra theo thời gian. Chúng tôi đã thấy một số thành công với điều đó trên một máy chủ khách bận rộn khi kết hợp với một số cải tiến xử lý về cách các hoạt động đồng bộ hóa khác được cơ sở dữ liệu lưu vào bộ nhớ cache
- Yêu cầu fsync nhỏ gọn. Ý tưởng này tách khỏi ý tưởng đầu tiên và trở thành một bản vá do Robert Haas viết. Ý tưởng là các máy khách đang cố gắng đồng bộ dữ liệu vào đĩa có thể cạnh tranh với việc ghi điểm kiểm tra. Những gì bản vá làm được là cho phép khách hàng dọn dẹp hàng đợi yêu cầu fsync nếu họ thấy nó đã đầy.
- Sắp xếp các lần ghi điểm kiểm tra. Khái niệm là nếu bạn viết mọi thứ ra theo thứ tự mà cơ sở dữ liệu tin rằng mọi thứ được lưu trữ trên đĩa, hệ điều hành có thể ghi hiệu quả hơn. Bản vá này đã xuất hiện cách đây vài năm với một số kết quả điểm chuẩn cho thấy nó hoạt động, nhưng vào thời điểm đó không ai có thể sao chép các cải tiến. Ý tưởng phù hợp với phần còn lại của tác phẩm đủ tốt để tôi đánh giá lại.
Vòng 3:Sau nhiều tuần thử tất cả những điều này, cách tiếp cận duy nhất trong bộ này cho thấy sự cải thiện ở hầu hết các kích thước khối lượng công việc là phương pháp nén fsync. Mã đồng bộ điểm kiểm tra lây lan ban đầu đã giúp một số trong lĩnh vực này, nhưng việc triển khai cụ thể hiện được cam kết cho 9.1 còn hoạt động tốt hơn. Đó là mức tăng gần như toàn diện 10% trong hầu hết các bài kiểm tra viết nặng mà tôi đã chạy. Đó là một cải tiến tuyệt vời cho PostgreSQL 9.1 và nó sẽ loại bỏ hoàn toàn một vấn đề mà chúng tôi đã thấy gây ra sự chậm lại nhiều hơn trên các hệ thống sản xuất ở đây.
Phần còn lại của các ý tưởng ở đây không nhận được đánh giá tích cực như vậy sau khi nặng điểm chuẩn, vì vậy bây giờ những thứ đó sẽ trở lại trên giá. Tôi sẽ tiếp tục thu thập dữ liệu ở đây – một số thử nghiệm ext4 là điều hợp lý tiếp theo để thử – và sau đó quay lại phát triển lần nữa. Nhận được mức tăng 10% đối với một số khối lượng công việc khó khăn chắc chắn là tốt, nhưng vẫn còn quá nhiều hành vi trong trường hợp xấu nhất ở đây để coi vấn đề đồng bộ hóa trạm kiểm soát là một chủ đề đã đóng.
