Linux File IO - Đa luồng hiệu năng - ghi vào các tập tin khác nhau

Question

Tôi hiện đang làm việc trên ứng dụng ghi âm, tìm nạp tới 8 luồng âm thanh từ mạng và lưu dữ liệu vào đĩa (đơn giản;)). Ngay bây giờ, mỗi luồng được xử lý bởi một luồng -> cùng một luồng cũng thực hiện công việc lưu trên đĩa.

Điều đó có nghĩa là tôi có 8 chủ đề khác nhau thực hiện ghi trên cùng một đĩa, mỗi chủ đề vào một tệp khác.

Bạn có nghĩ rằng sẽ có sự gia tăng hiệu suất đĩa nếu tất cả các công việc viết sẽ được thực hiện bởi một luồng chung (có thể ghi dữ liệu vào các tệp cụ thể)?

OS là Linux nhúng, các "đĩa" là một thẻ CF, ứng dụng được viết bằng C.

Cám ơn ý tưởng của bạn Nick

Answer 1

Câu trả lời ngắn gọn: Cho rằng bạn đang ghi vào đĩa Flash, tôi sẽ không mong đợi số lượng chủ đề tạo ra sự khác biệt nhiều theo cách này hay cách khác. Nhưng nếu nó đã tạo ra sự khác biệt, tôi mong đợi nhiều luồng sẽ nhanh hơn một luồng đơn, không chậm hơn.

Câu trả lời dài hơn:

Tôi đã viết một chương trình tương tự như bạn mô tả khoảng 6 năm trước - nó chạy trên một thẻ PowerPC Linux nhúng và đọc/viết nhiều tập tin âm thanh đồng thời đến/từ một SCSI cứng lái xe. Ban đầu tôi đã viết nó với một chủ đề duy nhất làm I/O, bởi vì tôi nghĩ rằng sẽ cung cấp thông lượng tốt nhất, nhưng hóa ra đó không phải là trường hợp.

Cụ thể, khi nhiều luồng đọc/ghi cùng một lúc, lớp SCSI nhận biết tất cả các yêu cầu đang chờ xử lý từ tất cả các luồng khác nhau và có thể sắp xếp lại các yêu cầu I/O như tìm kiếm đầu ổ đĩa đã được giảm thiểu. Trong kịch bản single-thread-IO, mặt khác, lớp SCSI chỉ biết về yêu cầu I/O xuất hiện "tiếp theo" và do đó không thể thực hiện tối ưu hóa đó. Điều đó có nghĩa là du lịch thêm cho đầu ổ đĩa trong nhiều trường hợp, và do đó thông lượng thấp hơn. Tất nhiên, ứng dụng của bạn không sử dụng SCSI hoặc ổ xoay với đầu cần tìm kiếm, do đó có thể không phải là vấn đề với bạn - nhưng có thể có các tối ưu khác mà lớp hệ thống/phần cứng có thể thực hiện nếu nó nhận thức được nhiều yêu cầu I/O đồng thời. Cách thực sự duy nhất để tìm ra là thử các mô hình khác nhau và đo lường kết quả.

Đề xuất của tôi sẽ là tách rời I/O đĩa khỏi mạng I/O bằng cách di chuyển I/O đĩa vào một nhóm luồng. Sau đó bạn có thể thay đổi kích thước tối đa của I/O-thread-pool của bạn từ 1 đến N, và cho mỗi kích thước đo hiệu suất của hệ thống. Điều đó sẽ cung cấp cho bạn ý tưởng rõ ràng về những gì hoạt động tốt nhất trên phần cứng cụ thể của bạn, mà không yêu cầu bạn viết lại mã nhiều lần.

Answer 2

Nếu nó nhúng linux, tôi đoán bạn máy chỉ có một bộ xử lý/lõi. Trong trường hợp này, các chủ đề sẽ không cải thiện hiệu năng I/O. Tất nhiên hệ thống con khối linux hoạt động tốt trong môi trường đồng thời, nhưng trong trường hợp của bạn (nếu tôi đoán về số lõi là đúng) không thể có một tình huống khi một số chủ đề làm điều gì đó cùng một lúc.

Nếu dự đoán của tôi sai và bạn có nhiều hơn 1 lõi, thì tôi khuyên bạn nên đánh giá I/O đĩa chuẩn. Viết một chương trình ghi nhiều dữ liệu từ các luồng khác nhau và một chương trình khác thực hiện giống như chỉ từ một luồng. Kết quả sẽ cho bạn thấy mọi thứ bạn muốn biết.

Answer 3

Tôi nghĩ rằng không có sự khác biệt lớn giữa giải pháp đa luồng và đơn lẻ trong trường hợp của bạn, nhưng trong trường hợp đa luồng, bạn có thể đồng bộ hóa giữa các chuỗi nhận và không có chuỗi nào có thể ảnh hưởng đến các luồng khác trong trường hợp chặn trong một số cuộc gọi hệ thống.
Tôi đã làm điều tương tự trên hệ thống nhúng, vấn đề là sử dụng cpu cao khi hạt nhân thả nhiều trang bị lưu vào bộ nhớ cache, quá trình hạt nhân pdflush mất tất cả thời gian cpu trong thời điểm đó và nếu bạn nhận luồng qua udp để nó có thể bị bỏ qua vì CPU đang bận khi luồng udp đến, vì vậy tôi đã giải quyết vấn đề đó bằng cách gọi fdatasync() mỗi khi một số lượng dữ liệu không lớn nhận được.