Tối ưu hóa bộ điều phối I/O của Linux: mq-deadline, none và BFQ

Bộ lập lịch I/O của Linux quyết định thứ tự mà các yêu cầu đọc và ghi đến thiết bị lưu trữ của bạn, và lựa chọn đúng đắn phụ thuộc gần như hoàn toàn vào phần cứng của bạn. Sử dụng none cho NVMe, mq-deadline cho SSD SATA và HDD chạy các khối lượng công việc hỗn hợp, và bfq khi bạn cần ngăn một quy trình làm ảnh hưởng đến các quy trình khác. Hướng dẫn này trình bày cách thức hoạt động của ba bộ lập lịch chính, cách kết hợp một bộ lập lịch với khối lượng công việc của bạn, cũng như cách điều chỉnh và xác minh kết quả.

Nếu bạn muốn thực hành trước khi đọc, video này trình bày những kiến thức cơ bản về việc chuyển đổi và kiểm tra các bộ lập lịch từ terminal.

Sự khác biệt giữa mq-deadline, none và BFQ

Mỗi bộ lập lịch xử lý các yêu cầu theo một chiến lược khác nhau. Hiểu rõ sự khác biệt giữa chúng sẽ giúp bạn đưa ra lựa chọn có chủ đích thay vì chạy bất kỳ thứ gì mà kernel chọn khi khởi động.

mq-deadline

Bộ mq-deadline bộ điều phối đảm bảo không có yêu cầu nào phải chờ đợi vô thời hạn. Nó duy trì các hàng đợi được sắp xếp riêng biệt cho đọc và ghi, sắp xếp theo Địa chỉ Khối Logic (LBA) để giảm thời gian tìm kiếm, và áp dụng các giới hạn thời gian: 500 ms cho đọc và 5 giây cho ghi theo mặc định. Khi một yêu cầu đạt đến giới hạn thời gian, nó sẽ được đưa lên đầu hàng đợi.

Đọc được ưu tiên hơn ghi, vì đọc thường chặn ứng dụng trong khi ghi được xử lý không đồng bộ. Để ngăn chặn việc ghi bị bỏ qua hoàn toàn, bộ lập lịch xử lý một lô ghi quá hạn sau một số lần đọc nhất định. Kết quả là độ trễ thấp nhất quán, khiến nó rất phù hợp với máy chủ cơ sở dữ liệu và bất kỳ khối lượng công việc nào kết hợp giữa đọc và ghi.

không

Bộ none bộ điều phối gần như không làm gì cả. Nó chuyển các yêu cầu trực tiếp đến thiết bị theo thứ tự First-In-First-Out (FIFO), không có sắp xếp lại, hợp nhất hay ưu tiên. Điều này phù hợp với các ổ NVMe hiện đại, vốn tự quản lý hàng đợi nội bộ và có thể theo dõi hàng chục nghìn yêu cầu đang xử lý cùng lúc. Loại bỏ lớp điều phối phần mềm tạo ra đường dẫn ngắn nhất từ ứng dụng đến thiết bị, chính xác là điều mà các tác vụ NVMe có thông lượng cao mong muốn.

Vấn đề là điều này chỉ hoạt động khi phần cứng có thể tự lập lịch một cách thông minh. Trên các ổ HDD hoặc SSD SATA có hàng đợi nông, việc bỏ qua việc sắp xếp lại bằng phần mềm thường làm cho hiệu suất kém hơn, chứ không phải tốt hơn.

BFQ

BFQ (Budget Fair Queuing) ưu tiên tính công bằng. Thay vì chia thời gian, nó cấp cho mỗi tiến trình một ngân sách tính bằng sector đĩa. Các tác vụ đọc tuần tự lớn được cấp ngân sách lớn hơn để duy trì thông lượng, trong khi các tác vụ nhạy cảm với độ trễ được cấp ngân sách nhỏ hơn để được xử lý nhanh chóng, và một vòng lặp phản hồi điều chỉnh các ngân sách này trong quá trình chạy.

BFQ duy trì tính tương tác của các tác vụ ngay cả khi tải nặng, do đó việc phát video hoặc truy vấn cơ sở dữ liệu vẫn mượt mà trong khi quá trình chuyển file lớn diễn ra ở nền. Sự công bằng này tiêu tốn tài nguyên CPU. Chi phí xử lý mỗi yêu cầu của nó khoảng 1,9 microgiây, gấp ba lần so với mq-deadline, và trên lõi ARM chậm hơn, chi phí này giới hạn thông lượng ở mức thấp hơn nhiều so với mức mà cùng một trình điều phối đạt được trên chip x86 nhanh. Trên các máy chủ nơi thông lượng thô và hiệu suất CPU là quan trọng nhất, sự đánh đổi đó khó có thể biện minh.

Lựa chọn bộ điều phối phù hợp với khối lượng công việc

Hai yếu tố quyết định bộ lập lịch phù hợp: phần cứng lưu trữ và mẫu truy cập của ứng dụng. Hãy bắt đầu với phần cứng. Nếu thiết bị đã sắp xếp lại các yêu cầu, như ổ đĩa NVMe có phần mềm cơ sở tương thích, việc lập lịch bằng phần mềm chỉ gây thêm gánh nặng, do đó none thắng. Trên các ổ cứng quay (HDD), nơi thời gian tìm kiếm chiếm ưu thế, việc sắp xếp lại bằng phần mềm sẽ giảm độ trễ, do đó mq-deadline hoặc bfq là những lựa chọn tốt hơn. Ổ SSD SATA nằm ở giữa: nhanh hơn ổ HDD nhưng không có hàng đợi sâu như NVMe, đó là nơi mq-deadline phù hợp.

Cùng một logic áp dụng khi đã có thứ khác đang lập lịch cho bạn. Các máy ảo khách trên virtio-blk dựa vào máy chủ để lập lịch I/O, và các bộ điều khiển RAID phần cứng có bộ nhớ đệm ghi lại (write-back cache) tối ưu hóa thứ tự của riêng chúng. Trong cả hai trường hợp none tránh phải trả giá gấp đôi cho công việc.

Mô hình truy cập là yếu tố thứ hai. Một cơ sở dữ liệu thực hiện hàng nghìn lần đọc ngẫu nhiên 4K mỗi giây không có điểm chung nào với một tác vụ đào tạo truyền các khối tuần tự lớn từ một mảng NVMe, và chúng cần các bộ lập lịch khác nhau. Bảng dưới đây liệt kê các khối lượng công việc phổ biến làm điểm khởi đầu.

Có một ngoại lệ đáng chú ý. Ngay cả trên NVMe, nếu độ trễ đuôi tại p99 hoặc p999 là chỉ số bạn quan tâm, chẳng hạn như trong các hệ thống tài chính, mq-deadline có thể vượt trội none bằng cách áp dụng các thời hạn nghiêm ngặt và ngăn chặn các yêu cầu bị trì hoãn thỉnh thoảng.

Thay đổi và điều chỉnh các tham số của bộ lập lịch

Việc chuyển đổi bộ lập lịch và điều chỉnh các tham số của chúng đều được thực hiện thông qua sysfs, không cần khởi động lại để kiểm tra thay đổi.

Chuyển đổi bộ lập lịch đang hoạt động

Kiểm tra những gì có sẵn cho một thiết bị, trong đó giá trị trong ngoặc là giá trị đang hoạt động:

cat /sys/block/sda/queue/scheduler

Chuyển sang bộ lập lịch khác trong khi chạy. Thay đổi này có hiệu lực ngay lập tức nhưng không tồn tại sau khi khởi động lại:

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Nếu bfq không được liệt kê, hãy tải mô-đun trước:

sudo modprobe bfq

Để làm cho lựa chọn này trở nên vĩnh viễn, hãy sử dụng quy tắc udev thay vì tham số kernel cũ elevator= , vốn không còn thay đổi bộ lập lịch trên RHEL 9 và các phiên bản tương tự. Quy tắc này đặt mq-deadline cho tất cả các đĩa SCSI không quay trong /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Tải lại và áp dụng mà không cần khởi động lại:

sudo udevadm control --reload-rules && sudo udevadm trigger

Trên các hệ thống dựa trên RHEL, các cấu hình TuneD thực hiện công việc tương tự thông qua các cấu hình toàn hệ thống thay vì các quy tắc cho từng thiết bị.

Các tham số đáng điều chỉnh

Mỗi bộ lập lịch hiển thị các thông số có thể điều chỉnh của mình trong /sys/block/<device>/queue/iosched/. Đối với mq-deadline, thời hạn là các công cụ điều chỉnh chính. Các cơ sở dữ liệu nhạy cảm với độ trễ trên ổ SSD SATA sẽ được lợi từ các thời hạn ngắn hơn:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Đối với bfq trên các hệ thống có thông lượng cao, việc vô hiệu hóa các thuật toán heuristic về độ trễ sẽ tăng thông lượng:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Đối với dịch vụ lưu trữ chia sẻ, BFQ kết hợp tốt với cgroups v2. Việc gán io.weight giá trị cho phép bạn cấp cho một quy trình cơ sở dữ liệu gấp mười lần phần chia sẻ I/O so với một tác vụ sao lưu, ví dụ, để công việc nền không làm gián đoạn lưu lượng tương tác. Dù bạn thay đổi gì, chi phí cao hơn cho mỗi yêu cầu của BFQ sẽ tích lũy trên các hệ thống bị giới hạn bởi CPU và có IOPS cao, vì vậy hãy chạy thử nghiệm hiệu năng trước khi triển khai.

Kiểm tra hiệu suất sau khi điều chỉnh

Luôn ghi lại dữ liệu cơ sở trước khi thực hiện bất kỳ thay đổi nào. Nếu không có dữ liệu này, bạn sẽ không thể biết liệu việc điều chỉnh có mang lại hiệu quả hay không.

fio là công cụ tiêu chuẩn cho việc này. Nó tái tạo các mẫu tải công việc cụ thể thông qua kích thước khối, độ sâu hàng đợi và cài đặt động cơ I/O. Luôn sử dụng tùy chọn --direct=1 để bỏ qua bộ đệm trang và đo lường bộ lập lịch và thiết bị trực tiếp thay vì các lần đọc được lưu trong bộ đệm. Phù hợp hóa bài kiểm tra với tải công việc thực tế:

Chạy cùng một bài kiểm tra trên iodepth các giá trị từ 1 đến 256 để tìm điểm bão hòa của thiết bị, mức độ mà tại đó IOPS ngừng tăng và độ trễ tăng đột biến. Để giám sát trực tiếp sau khi thay đổi, iostat -x 1 báo cáo các chỉ số quan trọng: r_await và w_await đối với độ trễ hoàn thành đọc và ghi, aqu-sz đối với độ sâu hàng đợi trung bình, và %util đối với mức sử dụng thiết bị. Khi %util nằm gần 100%, phần cứng là giới hạn và không có thay đổi nào về trình điều phối có thể giúp được.

Để tách chi phí phần mềm khỏi chi phí phần cứng, hãy chạy blktrace với btt. Nó chia độ trễ thành Q2D, thời gian dành cho hàng đợi phần mềm, và D2C, thời gian thiết bị cần để xử lý yêu cầu. Nếu Q2D chiếm ưu thế, bộ lập lịch là điểm nghẽn của bạn. Nếu D2C chiếm ưu thế, thì phần cứng là điểm nghẽn.

Một điều cần lưu ý khi đọc kết quả: việc lựa chọn bộ lập lịch chủ yếu ảnh hưởng đến phần đuôi của phân phối độ trễ, chứ không phải giá trị trung vị. Chuyển từ none sang mq-deadline trên NVMe có thể làm tăng độ trễ trung bình lên vài microgiây trong khi giảm độ trễ p99 và p999 xuống một nửa. Đối với các dịch vụ hướng đến người dùng bị ràng buộc bởi SLA, sự đánh đổi đó hầu như luôn đáng giá, đó là lý do tại sao việc đo lường độ trễ đuôi, chứ không phải thông lượng trung bình, mới là mục đích của bài tập này.

Chọn bộ lập lịch phù hợp

Tối ưu hóa bộ lập lịch là việc điều chỉnh thuật toán cho phù hợp với phần cứng và mô hình truy cập, sau đó chứng minh bằng các phép đo. Tóm tắt:

• NVMe: sử dụng none và để phần mềm cơ sở thực hiện việc xếp hàng.
• Ổ SSD SATA và ổ cứng HDD với I/O hỗn hợp: sử dụng mq-deadline để có độ trễ dự đoán được.
• Máy chủ chia sẻ hoặc đa người dùng: sử dụng bfq để ngăn một tác vụ làm cạn kiệt tài nguyên của các tác vụ còn lại.
• Theo dõi độ trễ đuôi, không phải độ trễ trung bình: các thay đổi của bộ lập lịch xuất hiện tại p99 và p999, vì vậy đó là những gì cần đo lường.
• Làm cho nó trở nên bền vững: sử dụng quy tắc udev hoặc TuneD, tuyệt đối không dùng tham số elevator= .

Để tận dụng tối đa bất kỳ bộ lập lịch nào, trước tiên cần có phần cứng đủ mạnh. Nếu bạn cần các máy chủ được hỗ trợ bởi NVMe, được thiết kế cho các khối lượng công việc có thông lượng cao và độ trễ thấp, hãy khám phá các tùy chọn VPS của FDC.