Mô tả tập tin mở tối đa thực tế (ulimit -n) cho một hệ thống âm lượng lớn

Gần đây chúng tôi đã bắt đầu tải thử nghiệm ứng dụng của mình và nhận thấy rằng nó đã hết phần mô tả tệp sau khoảng 24 giờ.

Chúng tôi đang chạy RHEL 5 trên Dell 1955:

CPU: 2 x Dual Core 2.66GHz 4MB 5150/3333FSB RAM: 8GB RAM HDD: 2 x 160GB 2.5 "Ổ cứng SATA

Tôi đã kiểm tra giới hạn mô tả tệp và nó được đặt ở 1024. Xem xét rằng ứng dụng của chúng tôi có khả năng có khoảng 1000 kết nối đến cũng như 1000 kết nối gửi đi, điều này có vẻ khá thấp. Không đề cập đến bất kỳ tập tin thực tế cần phải được mở.

Suy nghĩ đầu tiên của tôi là chỉ cần tăng tham số ulimit -n lên một vài bậc độ lớn và sau đó chạy lại thử nghiệm nhưng tôi muốn biết bất kỳ sự phân nhánh tiềm năng nào của việc đặt biến này quá cao.

Có cách thực hành tốt nhất nào để thiết lập điều này ngoài việc tìm ra có bao nhiêu phần mô tả tệp mà phần mềm của chúng tôi có thể mở theo lý thuyết không?

Các giới hạn này xuất phát từ thời điểm nhiều người dùng "bình thường" (không phải ứng dụng) sẽ chia sẻ máy chủ và chúng tôi cần các cách để bảo vệ họ khỏi sử dụng quá nhiều tài nguyên.

Chúng rất thấp đối với các máy chủ hiệu suất cao và chúng tôi thường đặt chúng ở một số lượng rất cao. (24k hoặc hơn) Nếu bạn cần số cao hơn, bạn cũng cần thay đổi tùy chọn tối đa tệp sysctl (thường giới hạn ở mức 40k trên ubfox và 70k trên rrc).

Thiết lập ulimit:

# ulimit -n 99999

Các tệp tối đa Sysctl:

#sysctl -w fs.file-max=100000

Ngoài ra, và rất quan trọng, bạn có thể cần kiểm tra xem ứng dụng của bạn có bị rò rỉ mô tả bộ nhớ / tập tin hay không. Sử dụng lsof để xem tất cả những gì nó đã mở để xem chúng có hợp lệ hay không. Đừng cố gắng thay đổi hệ thống của bạn để khắc phục các lỗi ứng dụng.

Bạn luôn có thể

cat /proc/sys/fs/file-nr

Trong tình huống 'tải cao' để xem có bao nhiêu mô tả tệp đang được sử dụng.

Tối đa - nó chỉ phụ thuộc vào những gì bạn đang làm.

Nếu các bộ mô tả tệp là ổ cắm tcp, v.v., thì bạn có nguy cơ sử dụng một lượng lớn bộ nhớ cho bộ đệm ổ cắm và các đối tượng hạt nhân khác; bộ nhớ này sẽ không thể hoán đổi.

Nhưng nếu không, không, về nguyên tắc sẽ không có vấn đề. Tham khảo tài liệu kernel để thử tìm hiểu xem nó sẽ sử dụng bao nhiêu bộ nhớ kernel và / hoặc kiểm tra nó.

Chúng tôi chạy các máy chủ cơ sở dữ liệu với các mô tả tệp ~ 10k mở (hầu hết trên các tệp đĩa thực) mà không gặp sự cố lớn, nhưng chúng là 64 bit và có vô số ram.

Cài đặt ulimit là theo quy trình, nhưng cũng có giới hạn toàn hệ thống (theo mặc định tôi nghĩ là 32k)

Tôi không nhận thức cá nhân về bất kỳ thực hành tốt nhất. Đó là một chút chủ quan tùy thuộc vào chức năng hệ thống.

Hãy nhớ rằng 1024 bạn đang thấy là giới hạn cho mỗi người dùng và không phải là giới hạn toàn hệ thống. Xem xét có bao nhiêu ứng dụng bạn chạy trên hệ thống này. Đây có phải là người duy nhất? Là người dùng chạy ứng dụng này làm bất cứ điều gì khác? (IE bạn có con người sử dụng tài khoản này để đăng nhập và chạy các tập lệnh có khả năng chạy trốn không?)

Cho rằng hộp chỉ chạy một ứng dụng này và tài khoản đang chạy ứng dụng chỉ dành cho mục đích đó, tôi thấy không có hại gì trong việc tăng giới hạn của bạn như bạn đề xuất. Nếu đó là một nhóm phát triển nội bộ, tôi sẽ hỏi ý kiến ​​của họ. Nếu đó là từ nhà cung cấp bên thứ ba, họ có thể có các yêu cầu hoặc đề xuất cụ thể.

Đây dường như là một trong những câu hỏi được trả lời tốt nhất với "kiểm tra nó trong môi trường phát triển". Tôi nhớ những năm trước Sun đã lo lắng khi bạn gặp rắc rối với điều này, nhưng không phải là lo lắng. Giới hạn của nó tại thời điểm đó cũng là 1024, vì vậy tôi hơi ngạc nhiên khi thấy rằng bây giờ nó giống với Linux, có vẻ như nó phải cao hơn.

Tôi đã tìm thấy liên kết sau đây mang tính giáo dục khi tôi tìm kiếm câu trả lời cho câu hỏi của bạn: http://www.netadmintools.com/art295.html

Và cái này cũng có: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unliated-possible