Tối ưu hóa ext4 để luôn hoạt động đầy đủ

Ứng dụng của chúng tôi ghi dữ liệu vào đĩa dưới dạng bộ đệm vòng lớn (30 đến 150TB); ghi tập tin mới trong khi xóa tập tin cũ. Như vậy, theo định nghĩa, đĩa luôn "gần đầy".

Các nhà văn quá trình tạo tập tin khác nhau với tốc độ đầu vào ròng khoảng 100-150 Mbits / s. Các tệp dữ liệu là hỗn hợp của các tệp 'dữ liệu' 1GB và một số tệp dữ liệu meta nhỏ hơn. (Tốc độ đầu vào không đổi, nhưng lưu ý các tập tin mới chỉ được tạo một lần trong hai phút).

Có một quy trình deleter riêng biệt sẽ xóa các tệp "cũ nhất" sau mỗi 30 giây. Nó tiếp tục xóa cho đến khi nó đạt tới 15GB không gian trống trên đĩa.

Vì vậy, trong hoạt động ổn định, tất cả các phân vùng dữ liệu chỉ có 15 GB dung lượng trống.

Về câu hỏi SO này liên quan đến sự cố hệ thống tập tin, DepressionDaniel đã nhận xét:

Đồng bộ hóa treo chỉ có nghĩa là hệ thống tập tin đang làm việc chăm chỉ để lưu các hoạt động mới nhất một cách nhất quán. Nó chắc chắn là cố gắng xáo trộn dữ liệu xung quanh đĩa trong thời gian đó. Tôi không biết chi tiết, nhưng tôi khá chắc chắn nếu hệ thống tập tin của bạn bị phân mảnh nhiều, ext4 sẽ cố gắng làm điều gì đó về điều đó. Và điều đó không thể tốt hơn nếu hệ thống tập tin đã gần đầy 100%. Cách hợp lý duy nhất để sử dụng một hệ thống tệp với gần 100% dung lượng là khởi tạo tĩnh nó với một số tệp và sau đó ghi đè lên các tệp tương tự đó (để tránh phân mảnh). Có lẽ hoạt động tốt nhất với ext2 / 3.

Ext4 là một lựa chọn tồi cho ứng dụng này? Vì chúng tôi đang chạy trực tiếp, điều chỉnh nào có thể được thực hiện cho ext4 để tránh phân mảnh, làm chậm hoặc hạn chế hiệu suất khác? Thay đổi từ ext4 sẽ khá khó khăn ...

(và viết lại các tệp được tạo tĩnh có nghĩa là viết lại toàn bộ ứng dụng)

Cảm ơn!

EDIT tôi

Máy chủ có 50 đến 100 TB đĩa được đính kèm (24 ổ đĩa). Bộ điều khiển Areca RAID quản lý 24 ổ đĩa dưới dạng bộ đột kích RAID-6.

Từ đó chúng tôi chia thành nhiều phân vùng / tập, với mỗi tập là 5 đến 10TB. Vì vậy, kích thước của bất kỳ một khối lượng là không lớn.

Quá trình "nhà văn" tìm thấy tập đầu tiên với không gian "đủ" và ghi một tập tin ở đó. Sau khi tập tin được viết, quá trình được lặp lại.

Đối với một máy hoàn toàn mới, khối lượng được lấp đầy theo thứ tự. Nếu tất cả các ổ đĩa là "đầy đủ" thì quá trình "deleter" bắt đầu xóa các tệp cũ nhất cho đến khi có đủ dung lượng "đủ".

Trong một thời gian dài, do tác động của các quá trình khác, chuỗi thời gian của các tệp sẽ được phân phối ngẫu nhiên trên tất cả các khối.

EDIT II

Chạy fsckcho thấy sự phân mảnh rất thấp: 1 - 2%. Tuy nhiên, trong khi chờ đợi, truy cập hệ thống tập tin chậm đã được bắt nguồn từ các cuộc gọi hệ thống khác nhau như fclose(), fwrite(), ftello()vv tham gia một thời gian rất dài để thực hiện (5 đến 60 giây!).

Cho đến nay không có giải pháp cho vấn đề này. Xem thêm chi tiết tại câu hỏi SO này: Làm thế nào để gỡ lỗi rất chậm (200 giây) fwrite () / ftello () / fclose ()?

Tôi đã vô hiệu hóa sysstatvà raid-checkđể xem nếu có cải thiện.

Về nguyên tắc, tôi không thấy lý do tại sao ghi vòng đệm nghiêm ngặt sẽ đặt ra bất kỳ thách thức nào về phân mảnh. Có vẻ như nó sẽ đơn giản. Các trích dẫn âm thanh với tôi như nó dựa trên lời khuyên từ khối lượng công việc viết chung hơn. Nhưng nhìn vào câu hỏi SO được liên kết tôi thấy bạn có một vấn đề thực sự ...

Vì bạn lo ngại về sự phân mảnh, bạn nên xem xét làm thế nào để đo lường nó! e4defragtồn tại Nó chỉ có hai lựa chọn. -cchỉ hiển thị trạng thái hiện tại và không phân mảnh. -vhiển thị số liệu thống kê trên mỗi tệp. Tất cả các kết hợp tùy chọn là hợp lệ (bao gồm không có tùy chọn). Mặc dù nó không cung cấp bất kỳ phương pháp rõ ràng nào để hạn chế tác động hiệu suất trên hệ thống đang chạy, nhưng e4defraghỗ trợ chạy trên các tệp riêng lẻ, do đó bạn có thể tự giới hạn tỷ lệ.

(XFS cũng có một công cụ chống phân mảnh, mặc dù tôi chưa sử dụng nó.)

e2freefragcó thể hiển thị phân mảnh không gian miễn phí. Nếu bạn sử dụng bộ lập lịch IO CFQ, thì bạn có thể chạy nó với mức ưu tiên IO giảm bằng cách sử dụng ionice.

Câu trích dẫn đoán sai, câu trả lời của Stephen Kitt là chính xác. ext4 không thực hiện bất kỳ phân mảnh tự động. Nó không cố gắng "xáo trộn" dữ liệu đã được viết.

Loại bỏ quan niệm sai lầm kỳ lạ này không có lý do để đề xuất "ext2 / ext3". Ngoài bất cứ điều gì khác, mã ext3 không tồn tại trong các nhân hiện tại. Mã ext4 được sử dụng để gắn kết ext3. ext3 là tập con của ext4. Đặc biệt, khi bạn đang tạo các tệp tương đối lớn, có vẻ như thật ngớ ngẩn khi không sử dụng phạm vi và đó là một tính năng dành riêng cho ext4.

Tôi tin rằng "treo" thường được liên kết với tạp chí. Xem ví dụ bình luận từ (hệ thống tập tin đang thực hiện) bcachefs -

Độ trễ đuôi đã là nguyên nhân của người dùng ext4 trong nhiều năm - sự phụ thuộc trong mã nhật ký và các nơi khác có thể dẫn đến độ trễ hơn 30 giây cho các hoạt động đơn giản (ví dụ: không liên kết) trên khối lượng công việc đa luồng. Không ai có thể biết làm thế nào để sửa chúng.

Trong bcachefs, lý do duy nhất khiến một luồng xử lý trên IO là vì nó được yêu cầu rõ ràng (một hoạt động đọc không được chú ý hoặc hoạt động fsync) hoặc cạn kiệt tài nguyên - dừng hoàn toàn. Các khóa sẽ chặn các hoạt động tiền cảnh không bao giờ được giữ trong khi thực hiện IO. Mặc dù bcachefs không phải là một hệ thống tập tin thời gian thực ngày nay (nó thiếu ví dụ như lập lịch thời gian thực cho IO), nhưng rất có thể hình dung có thể là một ngày.

Đừng yêu cầu tôi diễn giải mức độ sử dụng XFS có thể tránh được vấn đề trên. Tôi không biết. Nhưng nếu bạn đang xem xét thử nghiệm thiết lập hệ thống tập tin thay thế, XFS là điều đầu tiên tôi sẽ thử.

Tôi đang vật lộn để tìm nhiều thông tin về tác động của việc vô hiệu hóa nhật ký trên ext4. Ít nhất nó dường như không phải là một trong những lựa chọn phổ biến được xem xét khi điều chỉnh hiệu suất.

Tôi không chắc tại sao bạn lại sử dụng sys_sync (). Nó thường tốt hơn nên tránh (xem ví dụ ở đây ). Tôi không chắc điều đó thực sự giải thích vấn đề của bạn, nhưng có vẻ như một điều đáng tiếc đã xảy ra khi cố gắng thu hẹp điều này.

Đây là một cách tiếp cận khác, tuy nhiên nó có phần liên quan.

Tạo nhiều phân vùng nhỏ hơn, giả sử 10 hoặc 20 trong số chúng. LVM2 có thể có ích trong kịch bản này. Sau đó sử dụng các phân vùng theo kiểu vòng đệm như sau:

Một trong các phân vùng sẽ luôn là phân vùng 'hoạt động', nơi dữ liệu mới được ghi vào cho đến khi nó hoàn toàn đầy đủ hoặc gần như vậy. Bạn không cần phải rời khỏi bất kỳ khoảng không. Khi phân vùng hoạt động đã đầy hoặc không có đủ dung lượng trống để chứa khối dữ liệu tiếp theo, hãy chuyển sang phân vùng tiếp theo để trở thành phân vùng hoạt động.

Quá trình deleter của bạn sẽ luôn đảm bảo rằng có ít nhất một phân vùng hoàn toàn trống có sẵn. Nếu không có cái nào - và đây là phần quan trọng - nó sẽ chỉ định dạng lại phân vùng cũ nhất, tạo ra một hệ thống tệp mới. Phân vùng mới này sau đó sẽ có thể nhận dữ liệu mới với mức tối thiểu để không bị phân mảnh.