Số lượng tệp mở tối đa lớn nhất được phép trong Linux

Có giới hạn (kỹ thuật hoặc thực tế) nào về mức độ lớn bạn có thể định cấu hình số lượng tệp mở tối đa trong Linux không? Có một số tác dụng phụ nếu bạn định cấu hình nó thành một số rất lớn (giả sử 1-100M)?

Tôi đang nghĩ sử dụng máy chủ ở đây, không phải hệ thống nhúng. Tất nhiên, các chương trình sử dụng số lượng lớn tệp mở có thể ăn bộ nhớ và chậm, nhưng tôi quan tâm đến các tác động bất lợi nếu giới hạn được định cấu hình lớn hơn nhiều so với mức cần thiết (ví dụ: bộ nhớ chỉ sử dụng cấu hình).

Tôi nghi ngờ lý do chính cho giới hạn là để tránh tiêu thụ bộ nhớ quá mức (mỗi mô tả tệp mở sử dụng bộ nhớ kernel). Nó cũng phục vụ như một biện pháp bảo vệ chống lại các ứng dụng lỗi rò rỉ mô tả tệp và tiêu tốn tài nguyên hệ thống.

Nhưng được đưa ra có bao nhiêu hệ thống RAM hiện đại vô lý so với các hệ thống 10 năm trước, tôi nghĩ rằng mặc định ngày nay khá thấp.

Năm 2011, giới hạn cứng mặc định cho các bộ mô tả tệp trên Linux đã tăng từ 1024 lên 4096 .

Một số phần mềm (ví dụ MongoDB) sử dụng nhiều mô tả tệp hơn giới hạn mặc định. Mọi người MongoDB khuyên bạn nên tăng giới hạn này lên 64.000 . Tôi đã sử dụng rlimit_nofile300.000 cho các ứng dụng nhất định.

Miễn là bạn giữ giới hạn mềm ở mức mặc định (1024), có thể khá an toàn để tăng giới hạn cứng. Các chương trình phải gọi setrlimit()để tăng giới hạn của họ lên trên giới hạn mềm và vẫn bị giới hạn cứng.

Xem thêm một số câu hỏi liên quan:

• /server/356962/where-are-the-default-ulimit-values-set-linux-centos
• /server/773609/how-do-ulimit-sinstall-impact-linux

Tác động thường không thể quan sát được, nhưng mô-đun IO của hạt nhân sẽ phải chăm sóc tất cả những mô tả tệp đang mở và chúng cũng có thể có tác động đến hiệu quả bộ đệm.

Các giới hạn như vậy có lợi thế là bảo vệ người dùng khỏi những sai lầm của chính họ (hoặc của bên thứ ba). Ví dụ: nếu bạn chạy một chương trình hoặc tập lệnh nhỏ vô hạn, cuối cùng nó sẽ chặn một trong các ulimits và do đó ngăn chặn sự đóng băng dữ dội hơn (có thể không thể phục hồi).

Trừ khi bạn có lý do chính xác để tăng bất kỳ giới hạn nào trong số đó, bạn nên tránh nó và ngủ ngon hơn.

Về mặt kỹ thuật, nó bị giới hạn về giá trị tối đa của dấu dài (C Lang), tức là 4.294.967.295

Tham khảo: fs.htập tin

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

Tôi nghĩ rằng mối quan tâm của bạn là dễ hiểu nhưng rất có thể Linux sẽ không tiêu tốn nhiều bộ nhớ cho cấu hình (nhưng không được sử dụng mô tả tệp) :)

Tôi không thể nhớ một vấn đề như vậy trong sự nghiệp chuyên nghiệp của tôi trong 10 năm qua.

Trân trọng.

Im lặng muộn nhưng điều này sẽ giúp mọi người khác có được câu trả lời cho câu hỏi này. Giới hạn thực tế cho số lượng tệp đang mở trong linux cũng có thể được tính bằng cách sử dụng số lượng mô tả tệp tối đa mà một quá trình có thể mở.

Tôi đã thấy giới hạn được thay đổi từ hệ thống này sang hệ thống khác. Từ trang người đàn ông getlimit, bạn có thể thấy rằng RLIMIT_NOFILE-1chỉ định các giới hạn trong nội bộ.

Để kiểm tra giá trị RLIMIT_NOFILE, bạn có thể sử dụng câu lệnh dưới đây để nhận được một tuple

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

Các tuple trả về kết quả là (Soflimit, hardlimit). Đối với tôi chạy trên nhiều hệ thống kết quả như dưới đây

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos 

Lưu ý: 9223372036854775807 con số này đơn giản có nghĩa là vô cùng. Bạn sẽ luôn đạt đến các giới hạn tài nguyên khác trước khi bạn đạt được điều này. Nếu bạn đã sửa đổi hardlimit trên một hệ thống ngoài nó là gì, bạn sẽ phải sửa đổi các thông số kernel.