Làm thế nào để số lượng thư mục con tác động đến hiệu suất đọc / ghi trên Linux?

Tôi đã có một ổ đĩa được định dạng EXT3 trên máy chủ Linux CentOS. Đây là ổ dữ liệu ứng dụng web và chứa một thư mục cho mọi tài khoản người dùng (có 25.000 người dùng). Mỗi thư mục chứa các tệp mà người dùng đã tải lên. Nhìn chung, ổ đĩa này có khoảng 250GB dữ liệu trên đó.

Việc cấu trúc ổ đĩa với tất cả các thư mục này có ảnh hưởng đến hiệu suất đọc / ghi của ổ đĩa không? Nó có ảnh hưởng đến một số khía cạnh hiệu suất khác mà tôi không biết?

Có bất cứ điều gì vốn đã sai hoặc xấu với cấu trúc mọi thứ theo cách này? Có lẽ chỉ là sự lựa chọn sai của hệ thống tập tin?

Gần đây tôi đã thử hợp nhất hai ổ dữ liệu và nhận ra rằng EXT3 bị giới hạn ở 32.000 thư mục con. Điều này khiến tôi tự hỏi tại sao. Có vẻ ngớ ngẩn khi tôi xây dựng nó theo cách này, xem xét mỗi tệp có một id duy nhất tương ứng với một id trong cơ sở dữ liệu. Than ôi ...

Điều này rất dễ dàng để kiểm tra các tùy chọn cho chính bạn, trong môi trường của bạn và so sánh kết quả. Có, có một tác động tiêu cực đến hiệu suất khi số lượng thư mục tăng lên. Có, các hệ thống tập tin khác có thể giúp vượt qua những rào cản đó hoặc giảm tác động.

Hệ thống tập tin XFS tốt hơn cho loại cấu trúc thư mục này. ext4 có lẽ là tốt hiện nay. Truy cập và hoạt động trên thư mục sẽ chỉ chậm lại khi số lượng thư mục con và tệp tăng lên. Điều này rất rõ ràng trong ext3 và không nhiều trên XFS.

Câu trả lời không đơn giản như sự lựa chọn của hệ thống tập tin. Các hệ thống tập tin Sane đã dừng sử dụng danh sách tuyến tính cho các thư mục từ lâu, có nghĩa là số lượng mục trong thư mục không ảnh hưởng đến thời gian truy cập tệp ....

ngoại trừ khi nó làm.

Trong thực tế, mỗi hoạt động vẫn nhanh và hiệu quả cho dù số lượng mục nhập, nhưng một số nhiệm vụ liên quan đến số lượng hoạt động ngày càng tăng. Rõ ràng, làm một việc đơn giản lsmất nhiều thời gian và bạn không thấy điều gì cho đến khi tất cả các nút được đọc và sắp xếp. Làm ls -U(chưa được sắp xếp) giúp một chút vì bạn có thể thấy nó không chết, nhưng không làm giảm thời gian nhận thức. Ít rõ ràng hơn là bất kỳ sự mở rộng ký tự đại diện nào cũng phải kiểm tra từng tên tệp và dường như trong hầu hết các trường hợp, toàn bộ inode cũng phải được đọc.

Nói tóm lại: nếu bạn có thể chắc chắn tích cực rằng sẽ không có ứng dụng nào (bao gồm cả quyền truy cập shell) sẽ sử dụng bất kỳ ký tự đại diện nào, thì bạn có thể nhận được các thư mục lớn mà không phải hối hận. Nhưng nếu có thể có một số ký tự đại diện ẩn trong mã, tốt hơn là giữ các thư mục dưới một nghìn mục mỗi mục.

chỉnh sửa :

Tất cả các hệ thống tệp hiện đại đều sử dụng cấu trúc dữ liệu tốt cho các thư mục lớn, do đó, một thao tác duy nhất phải tìm inode của một tệp cụ thể sẽ khá nhanh ngay cả trên các thư mục có tiếng.

Nhưng, hầu hết các ứng dụng không chỉ hoạt động đơn lẻ. Hầu hết trong số họ sẽ làm một thư mục đầy đủ hoặc khớp ký tự đại diện. Đó là chậm không có vấn đề gì, bởi vì chúng liên quan đến việc đọc tất cả các mục.

Ví dụ: giả sử bạn có một thư mục có một triệu tệp được gọi là 'foo-000000.txt' đến 'foo-999999.txt' và một 'natalieportman.jpeg'. Đây sẽ là nhanh chóng:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

những điều này sẽ thất bại, nhưng cũng thất bại nhanh chóng:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

những điều này sẽ chậm, ngay cả khi chúng trả về rất ít kết quả; ngay cả những người thất bại, thất bại sau khi quét tất cả các mục:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Trước tiên hãy đảm bảo rằng phân vùng ext3 có dir_indexcờ được đặt.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Nếu nó bị thiếu, bạn có thể kích hoạt nó. Bạn cần ngắt kết nối hệ thống tập tin, sau đó chạy:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Sau đó gắn kết hệ thống tập tin.

Nó không có gì khác biệt cho đến khi bạn đạt tới giới hạn 32.000 tên cho mỗi giới hạn thư mục. Nâng cấp lên ext4 có thể khắc phục điều đó, cũng như các lợi ích khác mà ext4 có.

Càng có nhiều mục (tệp và thư mục) trong một thư mục, việc truy cập sẽ chậm hơn. Điều này đúng với mọi hệ thống tập tin, mặc dù một số tồi tệ hơn các hệ thống khác.

Một giải pháp tốt hơn là tạo một hệ thống phân cấp thư mục, như thế này:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

Và nếu bạn vẫn cần hiệu suất tốt hơn, bạn có thể mở rộng nhiều cấp độ:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

Hầu hết các hệ thống thư sử dụng thủ thuật này với các tệp xếp hàng thư của họ.

Ngoài ra, tôi đã thấy rằng với một số hệ thống tập tin, chỉ cần có trong quá khứ nhiều mục trong một thư mục sẽ làm cho việc truy cập thư mục đó bị chậm. Thực hiện ls -ldtrên thư mục để xem kích thước của mục nhập thư mục. Nếu đó là vài MB trở lên và thư mục tương đối trống, thì bạn có thể đang có hiệu suất kém. Đổi tên thư mục theo cách khác, tạo một thư mục mới có cùng tên và quyền và quyền sở hữu, sau đó di chuyển nội dung của thư mục cũ của bạn sang thư mục mới. Tôi đã sử dụng thủ thuật này nhiều lần để tăng tốc đáng kể các máy chủ thư đã bị hệ thống tập tin làm chậm.

Gần đây tôi đã phát triển một máy chủ lưu trữ cần thiết để tạo ra hàng chục triệu tệp và hàng trăm ngàn thư mục. Tôi đã so sánh XFS với ext4 và reiserfs. Tôi thấy rằng trong trường hợp của tôi, ext4 nhanh hơn một chút so với XFS. Reiser rất thú vị nhưng có những hạn chế nên đã bị loại bỏ. Tôi cũng thấy ext4 nhanh hơn đáng kể so với ext3.

Khi bạn nhận được nhiều tệp trên mỗi thư mục, thời gian mở tệp bắt đầu bị ảnh hưởng. Tệp I / O không. Thời gian xóa tập tin cũng bị. Tuy nhiên, nó không quá chậm trên ext4. Nó khá đáng chú ý trong ext3 mặc dù. XFS và ext4 khá nhanh về điều này.

Khi tôi nhìn vào XFS lần cuối và đang cân nhắc những lợi thế và bất lợi của việc sử dụng XFS so với ext4, tôi đã tìm thấy các báo cáo về mất dữ liệu với XFS. Tôi không chắc đây vẫn là một vấn đề hoặc nếu nó đã từng xảy ra, nhưng nó khiến tôi đủ lo lắng để lèo lái. Vì ext4 là fs mặc định trong Ubuntu, nó đã thắng dễ dàng hơn XFS.

Vì vậy, ngoài đề xuất của tylerl sẽ giúp ích từ góc độ quản lý, tôi đề nghị bạn có thể nâng cấp lên ext4. Giới hạn cho mỗi thư mục là 64000 mục với ext4

Một lợi ích khác là thời gian fsck nhanh hơn đáng kể. Tôi chưa bao giờ có bất kỳ vấn đề với tham nhũng.

Điều thú vị về ext4 là bạn có thể gắn một khối lượng ext3 vào ext4 để dùng thử. Xem: Di chuyển một hệ thống trực tiếp từ hệ thống tập tin ext3 sang ext4

Một trích dẫn từ liên kết đó:

Nếu bạn không bị ảnh hưởng bởi những hạn chế của ext3 và không sẵn sàng chấp nhận rủi ro, điều đó có thể không đáng. Mặt khác, khi hoàn thành thành công quy trình di chuyển, hệ thống của bạn có thể thực hiện nhanh hơn, trải nghiệm kiểm tra hệ thống tệp rút ngắn và tăng độ tin cậy mà không có hiệu ứng xấu.

Vì vậy, hãy tiếp tục và thử nó. Đề nghị bạn sao lưu trước.

Có một điều chắc chắn sẽ là một số hậu quả của việc làm này. Cái chính sẽ là đọc / ghi IO. Ngoài ra, đó chỉ là một cách xử lý dữ liệu rất đáng sợ (ở quy mô đó).

Trước đây, tôi đã sử dụng XFS để vượt qua giới hạn của Ext3 thành công.

Danh sách đầu tiên của nội dung hệ thống tệp sẽ mất một lúc cho đến khi hệ thống đọc tất cả thông tin thư mục / tệp. Các hoạt động bổ sung sẽ nhanh hơn vì kernel hiện có thông tin được lưu trữ.

Tôi đã thấy các quản trị viên chạy 'find / somepath 2> & 1> / dev / null' trong cron thường xuyên để giữ cho bộ đệm hoạt động, dẫn đến hiệu suất tốt hơn.

Tôi có một số câu hỏi và một số phát hiện tắc nghẽn có thể.

Đầu tiên, đây là hệ thống CentOS 5 hay 6? Bởi vì trong 6, chúng tôi có một công cụ đáng kinh ngạc gọi là blktrace, lý tưởng để đo lường tác động trong loại tình huống này.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Sau đó, chúng ta có thể phân tích đầu ra bằng btt và nhận được nút thắt ở đâu, ứng dụng, hệ thống tập tin, bộ lập lịch, lưu trữ - tại đó thành phần mà IO dành phần lớn thời gian.

Bây giờ, về mặt lý thuyết đến câu hỏi của bạn, rõ ràng nó sẽ tăng số lượng các nút và khi bạn tiếp tục tạo hoặc truy cập các tệp hoặc thư mục mới hoặc hiện có trong các thư mục, thời gian truy cập sẽ tăng lên. Hạt nhân phải đi qua một hệ thống phân cấp hệ thống tập tin rộng lớn hơn và do đó, không nghi ngờ gì là một chi phí chung.

Một điểm khác cần lưu ý là khi bạn tăng số lượng thư mục, việc sử dụng bộ nhớ cache inode và nha khoa sẽ tăng lên tiêu thụ nhiều RAM hơn. Điều này xuất hiện dưới bộ nhớ sàn, vì vậy nếu máy chủ của bạn sắp hết bộ nhớ, đó là một điểm suy nghĩ khác.

Nói về một ví dụ trong thế giới thực, gần đây tôi đã thấy rằng trên một ext3 fs được lồng rất cao, lần đầu tiên tạo ra một thư mục con mất khoảng 20 giây trong khi trên ext4 thì mất khoảng 4 giây. Đó là bởi vì cách phân bổ khối được cấu trúc trong các hệ thống tập tin khác nhau. Nếu bạn sử dụng XFS hoặc ext4, không cần phải nói rằng bạn sẽ tăng hiệu suất, tuy nhiên có thể là tối thiểu.

Vì vậy, nếu bạn chỉ hỏi về sự lựa chọn đúng đắn của hệ thống tập tin, ext3 là một chút lỗi thời. Đó là tất cả những gì tôi có thể cung cấp mà không cần thêm dữ liệu và điểm chuẩn.

Đây không phải là một tùy chọn trên CentOS 5 và không chắc chắn đó là một tùy chọn trên CentOS 6, nhưng tôi có cảm giác rằng giải pháp dựa trên cây B hoặc cây B * tức là BTRFS sẽ cung cấp hiệu quả phù hợp, nếu không nói là hiệu quả tốt hơn đáng kể kịch bản, nếu chỉ một người có thể giao phó nó với dữ liệu quý giá của một người có lương tâm rõ ràng (tôi vẫn sẽ không).

Nhưng nếu bạn có đủ khả năng, bạn có thể kiểm tra nó.