Trong phần nhận xét của một trong những blog của chúng tôi, một độc giả đã hỏi về tác động của wsrep_slave_threads đối với hiệu suất I / O và khả năng mở rộng của Galera Cluster. Vào thời điểm đó, chúng tôi không thể dễ dàng trả lời câu hỏi đó và sao lưu nó với nhiều dữ liệu hơn, nhưng cuối cùng chúng tôi đã cố gắng thiết lập môi trường và chạy một số thử nghiệm.
Người đọc của chúng tôi đã chỉ ra các điểm chuẩn cho thấy rằng việc tăng wsrep_slave_threads không có bất kỳ tác động nào đến hiệu suất của cụm Galera.
Để giải thích tác động của cài đặt đó, chúng tôi thiết lập một cụm nhỏ gồm ba nút (m5d.xlarge). Điều này cho phép chúng tôi sử dụng SSD nvme được đính kèm trực tiếp cho thư mục dữ liệu MySQL. Bằng cách làm này, chúng tôi đã giảm thiểu khả năng bộ nhớ trở thành nút thắt cổ chai trong quá trình thiết lập của chúng tôi.
Chúng tôi thiết lập vùng đệm InnoDB thành 8GB và làm lại nhật ký thành hai tệp, mỗi tệp 1GB. Chúng tôi cũng tăng innodb_io_capacity lên 2000 và innodb_io_capacity_max lên 10000. Điều này cũng nhằm đảm bảo rằng cả hai cài đặt đó đều không ảnh hưởng đến hiệu suất của chúng tôi.
Toàn bộ vấn đề với những điểm chuẩn như vậy là có rất nhiều điểm nghẽn khiến bạn phải loại bỏ từng điểm một. Chỉ sau khi thực hiện một số điều chỉnh cấu hình và sau khi đảm bảo rằng phần cứng sẽ không có vấn đề, người ta có thể hy vọng rằng một số giới hạn tinh vi hơn sẽ hiển thị.
Chúng tôi đã tạo ra ~ 90GB dữ liệu bằng cách sử dụng sysbench:
sysbench /usr/share/sysbench/oltp_write_only.lua --threads=16 --events=0 --time=600 --mysql-host=172.30.4.245 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=3306 --tables=28 --report-interval=1 --skip-trx=off --table-size=10000000 --db-ps-mode=disable --mysql-db=sbtest_large prepareSau đó, điểm chuẩn đã được thực hiện. Chúng tôi đã thử nghiệm hai cài đặt:wsrep_slave_threads =1 và wsrep_slave_threads =16. Phần cứng không đủ mạnh để được hưởng lợi từ việc tăng biến này hơn nữa. Cũng xin lưu ý rằng chúng tôi đã không thực hiện đo điểm chuẩn chi tiết để xác định xem liệu wsrep_slave_threads có nên được đặt thành 16, 8 hoặc có thể là 4 để có hiệu suất tốt nhất hay không. Chúng tôi quan tâm đến việc xem liệu chúng tôi có thể cho thấy tác động đến cụm không. Và có, tác động đã được nhìn thấy rõ ràng. Đối với người mới bắt đầu, một số đồ thị kiểm soát luồng.
Trong khi chạy với wsrep_slave_threads =1, trung bình, các nút đã bị tạm dừng do kiểm soát luồng ~ 64% thời gian.
Trong khi chạy với wsrep_slave_threads =16, trung bình, các nút đã bị tạm dừng do kiểm soát luồng ~ 20% thời gian.
Bạn cũng có thể so sánh sự khác biệt trên một biểu đồ. Sự sụt giảm ở cuối phần đầu tiên là lần thử chạy đầu tiên với wsrep_slave_threads =16. Máy chủ hết dung lượng đĩa cho nhật ký nhị phân và chúng tôi phải chạy lại điểm chuẩn đó một lần nữa sau đó.
Điều này đã dịch như thế nào về mặt hiệu suất? Sự khác biệt có thể nhìn thấy mặc dù chắc chắn không phải là ngoạn mục.
Đầu tiên, biểu đồ truy vấn trên giây. Trước hết, bạn có thể nhận thấy rằng trong cả hai trường hợp, kết quả đều ở khắp nơi. Điều này chủ yếu liên quan đến hiệu suất không ổn định của bộ nhớ I / O và điều khiển luồng khởi động ngẫu nhiên. Bạn vẫn có thể thấy rằng hiệu suất của kết quả "đỏ" (wsrep_slave_threads =1) thấp hơn khá nhiều so với kết quả "xanh" ( wsrep_slave_threads =16).
Hình ảnh khá tương tự là khi chúng ta nhìn vào độ trễ. Bạn có thể xem thêm (và thường là sâu hơn) gian hàng để chạy với wsrep_slave_thread =1.
Sự khác biệt thậm chí còn rõ ràng hơn khi chúng tôi tính toán độ trễ trung bình trên tất cả các lần chạy và bạn có thể thấy rằng độ trễ của wsrep_slave_thread =1 cao hơn 27% so với độ trễ với 16 luồng phụ, rõ ràng là không tốt vì chúng tôi muốn độ trễ thấp hơn , không cao hơn.
Sự khác biệt về thông lượng cũng có thể nhìn thấy, khoảng 11% cải thiện khi chúng tôi thêm nhiều wsrep_slave_threads.
Như bạn có thể thấy, tác động là ở đó. Nó hoàn toàn không phải là 16 lần (ngay cả khi đó là cách chúng tôi tăng số lượng chủ đề nô lệ trong Galera) nhưng nó chắc chắn đủ nổi bật để chúng tôi không thể phân loại nó chỉ là một bất thường thống kê.
Hãy nhớ rằng trong trường hợp của chúng tôi, chúng tôi đã sử dụng các nút khá nhỏ. Sự khác biệt thậm chí còn đáng kể hơn nếu chúng ta đang nói về các phiên bản lớn chạy trên khối lượng EBS với hàng nghìn IOPS được cung cấp.
Sau đó, chúng tôi sẽ có thể chạy sysbench mạnh mẽ hơn, với số lượng hoạt động đồng thời cao hơn. Điều này sẽ cải thiện khả năng song song của các bộ ghi, cải thiện mức độ thu được từ đa luồng hơn nữa. Ngoài ra, phần cứng nhanh hơn có nghĩa là Galera sẽ có thể sử dụng 16 luồng đó theo cách hiệu quả hơn.
Khi chạy các thử nghiệm như thế này, bạn phải lưu ý rằng bạn cần đẩy thiết lập của mình gần như đến giới hạn của nó. Sao chép đơn luồng có thể xử lý khá nhiều tải và bạn cần chạy nhiều lưu lượng truy cập để thực sự làm cho nó không đủ hiệu suất để xử lý tác vụ.
Chúng tôi hy vọng bài đăng trên blog này cung cấp cho bạn thông tin chi tiết hơn về khả năng của Galera Cluster trong việc áp dụng song song các tập viết và các yếu tố hạn chế xung quanh nó.
