Praktyczne maksymalne otwarte deskryptory plików (ulimit -n) dla systemu o dużej objętości

Niedawno rozpoczęliśmy testowanie aplikacji i zauważyliśmy, że po około 24 godzinach zabrakło jej deskryptorów.

Używamy RHEL 5 na Dell 1955:

Procesor: 2 x dwurdzeniowy 2,66 GHz 4 MB 5150/1333 FSB RAM: 8 GB RAM HDD: 2 x 160 GB 2,5 "dyski twarde SATA

Sprawdziłem limit deskryptora pliku i ustawiono go na 1024. Biorąc pod uwagę, że nasza aplikacja może potencjalnie mieć około 1000 połączeń przychodzących, a także 1000 połączeń wychodzących, wydaje się to dość niskie. Nie wspominając o żadnych rzeczywistych plikach, które należy otworzyć.

Moją pierwszą myślą było zwiększenie parametru ulimit -n o kilka rzędów wielkości, a następnie ponowne uruchomienie testu, ale chciałem poznać potencjalne konsekwencje ustawienia zbyt dużej wartości tej zmiennej.

Czy istnieją jakieś najlepsze praktyki w tym zakresie poza ustaleniem, ile deskryptorów plików nasze oprogramowanie może teoretycznie otworzyć?

Limity te pochodzą z czasów, gdy wielu „normalnych” użytkowników (nie aplikacji) dzieliło serwer, a my potrzebowaliśmy sposobów, aby chronić ich przed użyciem zbyt wielu zasobów.

Są bardzo niskie dla serwerów o wysokiej wydajności i generalnie ustawiamy je na bardzo wysoką liczbę. (Około 24 KB) Jeśli potrzebujesz wyższych liczb, musisz również zmienić opcję sysctl file-max (zazwyczaj ograniczona do 40 KB na Ubuntu i 70 KB na rhel).

Ustawienie ulimit:

# ulimit -n 99999

Pliki Sysctl max:

#sysctl -w fs.file-max=100000

Co bardzo ważne, może być konieczne sprawdzenie, czy w aplikacji występuje przeciek pamięci / deskryptora pliku. Użyj lsof, aby zobaczyć wszystko, co ma otwarte, aby sprawdzić, czy są poprawne, czy nie. Nie próbuj zmieniać systemu w celu obejścia błędów aplikacji.

Zawsze możesz po prostu

cat /proc/sys/fs/file-nr

Podczas sytuacji „dużego obciążenia” sprawdź, ile deskryptorów plików jest używanych.

Maksymalnie - zależy to tylko od tego, co robisz.

Jeśli deskryptory plików to gniazda tcp itp., Ryzykujesz użycie dużej ilości pamięci dla buforów gniazd i innych obiektów jądra; ta pamięć nie będzie wymienna.

Ale w przeciwnym razie nie, w zasadzie nie powinno być problemu. Przejrzyj dokumentację jądra, aby dowiedzieć się, ile pamięci jądra będzie zużywać i / lub przetestuj ją.

Obsługujemy serwery baz danych z otwartymi deskryptorami plików ~ 10k (głównie na prawdziwych plikach dyskowych) bez większego problemu, ale są one 64-bitowe i mają dużo pamięci RAM.

Ustawienie ulimit dotyczy poszczególnych procesów, ale istnieje również limit ogólnosystemowy (domyślnie 32k)

Nie jestem osobiście świadomy najlepszych praktyk. Jest to nieco subiektywne w zależności od funkcji systemu.

Pamiętaj, że 1024 to limit na użytkownika, a nie ogólnosystemowy. Zastanów się, ile aplikacji uruchamiasz w tym systemie. Czy to jedyny? Czy użytkownik, który uruchamia tę aplikację, robi coś innego? (IE, czy masz ludzi używających tego konta do logowania i uruchamiania skryptów, które mogą potencjalnie uciec?)

Biorąc pod uwagę, że w pudełku jest uruchomiona tylko jedna aplikacja, a konto, na którym działa wspomniana aplikacja, jest przeznaczone tylko do tego celu, nie widzę żadnej szkody w zwiększeniu limitu, jak sugerujesz. Jeśli jest to wewnętrzny zespół programistów, poprosiłbym o ich opinię. Jeśli pochodzi od zewnętrznego dostawcy, mogą mieć określone wymagania lub zalecenia.

Wydaje mi się, że na jedno z tych pytań najlepiej odpowiedzieć „przetestuj w środowisku programistycznym”. Pamiętam lata temu, kiedy Sun się denerwował, kiedy się z tym pogubiłeś, ale nie aż tak nerwowo. Jego limit w tym czasie wynosił również 1024, więc jestem zaskoczony, widząc, że w Linuksie jest tak samo, wydaje się, że powinien być wyższy.

Kiedy poszukałem w Google odpowiedzi na twoje pytanie, znalazłem następujący link edukacyjny: http://www.netadmintools.com/art295.html

A ten również: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible