Sử dụng O_DIRECT trên Linux

Nếu câu hỏi này quá định hướng lập trình viên, hãy cho tôi biết. Tôi tự hỏi liệu có người nào quen thuộc với cờ O_DIRECT cho lệnh gọi hệ thống open () trên Linux 2.6 không? Linus chê bai việc sử dụng nó, tuy nhiên việc viết tập tin hiệu suất cao dường như cho thấy việc sử dụng nó. Tôi muốn biết về bất kỳ kinh nghiệm và khuyến nghị trong thế giới thực.

Thông tin thêm: Ứng dụng mà tôi đang sử dụng sẽ duy trì bộ nhớ cache của riêng nó và khi làm như vậy đạt được tốc độ trung bình từ 5x trở lên. Khi ghi vào tệp, nội dung của bộ đệm phải được ghi ra bộ đệm của hệ thống tệp, điều này có vẻ dư thừa và là vấn đề hiệu suất.

Ok, bạn hỏi kinh nghiệm, điều này làm cho câu hỏi hơi chủ quan và lập luận, nhưng có thể vượt qua.

Linus nói rằng đề cập đến những cách sử dụng mà mọi người thường gán cho O_DIRECT và đối với những cách sử dụng đó, IMO Linus hầu như là chính xác. Ngay cả khi bạn thực hiện I / O trực tiếp, bạn không thể truyền dữ liệu đến / từ các thiết bị trực tiếp đến các câu lệnh chương trình của mình, bạn cần một bộ đệm được lấp đầy (bởi chương trình hoặc thiết bị) và chuyển qua một cuộc gọi hệ thống đến đầu kia. Ngoài ra, để làm cho nó hiệu quả, bạn sẽ không muốn đọc lại thứ gì đó bạn vừa đọc, trong trường hợp bạn cần nó một lần nữa. Vì vậy, bạn cần một số loại bộ đệm ... và chính xác là hạt nhân cung cấp mà không có O_DIRECT, bộ đệm trang! Tại sao không sử dụng? Nó cũng đi kèm với các lợi ích nếu nhiều quá trình muốn truy cập cùng một tệp đồng thời, đó sẽ là một thảm họa với O_DIRECT.

Phải nói rằng, O_DIRECT có công dụng của nó: Nếu vì một lý do nào đó, bạn cần lấy dữ liệu trực tiếp từ thiết bị khối. Nó không có gì để làm với hiệu suất.

Những người sử dụng O_DIRECT cho hiệu suất thường đến từ các hệ thống có thuật toán bộ đệm trang xấu hoặc không có cơ chế tư vấn POSIX hoặc thậm chí mọi người lặp lại một cách vô thức những gì người khác đã nói. Để tránh những vấn đề này, O_DIRECT là một giải pháp. Linux, OTOH, có triết lý là bạn nên khắc phục vấn đề thực sự tiềm ẩn và vấn đề tiềm ẩn là các hệ điều hành đã làm một công việc tồi tệ với bộ nhớ đệm trang.

Tôi đã sử dụng O_DIRECT để thực hiện đơn giản con mèo để tìm lỗi bộ nhớ trong máy của mình. Đây là một cách sử dụng hợp lệ cho O_DIRECT. Điều đó không liên quan gì đến hiệu suất.

Trên thực tế, O_DIRECT là cần thiết để tránh một trong hai

• ô nhiễm bộ đệm - đôi khi bạn biết rằng không có ý nghĩa gì trong việc lưu trữ bộ đệm, ví dụ như khi xử lý các tệp thực sự lớn, hãy nói 64 GiB khi chỉ có 2 GiB RAM. Tệp torrent 32 GiB mà người dùng quyết định xác minh dường như không phải là một ứng cử viên tốt cho bộ nhớ đệm. Nó chỉ là hoạt động bổ sung với chi phí riêng của nó. Và nó có thể khiến một số dữ liệu thực sự hữu ích bị cắt khỏi bộ đệm.
• bộ nhớ đệm kép - ví dụ: một số RDBMS (đề cập đến MySQL) cho phép xác định bộ đệm của chính nó. Cơ sở dữ liệu được cho là biết cách lưu trữ bộ đệm tốt hơn và những gì, hơn Bộ nhớ ảo của kernel không biết gì về lập kế hoạch SQL, v.v.

- đó là không tốt, như nó có vẻ. Và O_DIRECTkhông có nghĩa là nhanh hơn, thường thì không .

Lưu ý rằng việc sử dụng O_DIRECTcó thể bị lỗi trong các nhân mới hơn với các hệ thống tệp mới hơn. Xem báo cáo lỗi này cho ví dụ. Vì vậy, việc sử dụng thường không đáng ngờ, nó có thể sẽ không hoạt động trong thế hệ phân phối Linux sắp tới. Vì vậy, tôi sẽ không đặt cược hiệu suất của mã của mình vào nó, ngay cả khi bạn có thể chứng minh rằng nó có thể có lợi ích.

Nó có rất nhiều để làm với hiệu suất.

Một ví dụ thú vị là trong mongodb sử dụng công cụ mmap. O_DIRECT được sử dụng tốt nhất, như những người khác đã nêu, trong đó dữ liệu khó có thể được đọc trong một thời gian. Trong mongodb, nhật ký cơ sở dữ liệu được viết bằng O_DIRECT trong khi dữ liệu và chỉ mục ghi được xử lý bởi cơ chế bộ đệm trang (pdflush) bởi vì, mặc dù O_DIRECT cung cấp ít băng thông hơn, nhưng cũng có nghĩa là độ trễ ít hơn và do đó giảm mất dữ liệu trong trường hợp xảy ra mất điện đột xuất (hoảng loạn kernel, đĩa hoặc mất điện). Lưu ý rằng vẫn còn bộ đệm trước khi ghi O_DIRECT được cam kết lưu trữ không bay hơi, điều này chỉ làm giảm mất dữ liệu.

Một tính năng quan trọng khác của O_DIRECT là nó cung cấp nhiều quyền kiểm soát hơn đối với trình tự ghi. Một lần nữa, nó không đảm bảo thứ tự ghi (trừ khi bạn có bộ điều khiển đĩa bộ đệm không biến động và đang sử dụng bộ lập lịch fifo, nhưng chúng có các biến chứng riêng). Do đó, mặc dù mysql sử dụng O_DIRECT cho dữ liệu / chỉ mục của nó cũng như ghi nhật ký, nhưng có thể hy vọng rằng cái sau thường sẽ được cam kết trước.

Nhưng điều quan trọng cần nhớ là O_DIRECT phá vỡ sự công bằng trong phân bổ tài nguyên. Một trong những lý do khiến ứng dụng của bạn được tăng tốc là vì nó làm chậm các thứ khác.

Liên quan đến những gì @Juliano đã nói.

Hãy kiểm tra posix_fadvisexem sự cố thực sự có phải là sai đối với thuật toán bộ đệm của hệ thống tập tin cơ bản hay không, bạn có thể thử cho nó lời khuyên, bạn sẽ sử dụng hệ thống tập tin như thế nào. Đối với fs được thực hiện độc đáo, nó sẽ giúp tăng hiệu suất. (Đây là liên kết đến một chủ đề khác chạm vào những cân nhắc tương tự /programming//a/3755818/544721 )