Największa dozwolona maksymalna liczba otwartych plików w systemie Linux

10

Czy istnieje (techniczny lub praktyczny) limit, na ile można skonfigurować maksymalną liczbę otwartych plików w systemie Linux? Czy są jakieś negatywne skutki, jeśli skonfigurujesz go na bardzo dużą liczbę (powiedzmy 1-100M)?

Myślę, że tutaj jest użycie serwera, a nie systemów wbudowanych. Programy wykorzystujące ogromne ilości otwartych plików mogą oczywiście zjadać pamięć i być wolne, ale interesują mnie niekorzystne efekty, jeśli limit jest skonfigurowany znacznie większy niż to konieczne (np. Pamięć zużywana przez samą konfigurację).

— Sampo
źródło

Teoretycznie można obliczyć, ile deskryptorów plików może obsłużyć system w oparciu o dostępną pamięć i stwierdzenie, że każdy fd zużywa 1K pamięci: serverfault.com/questions/330795/…

— Alastair McCormack

10

Podejrzewam, że głównym powodem tego limitu jest uniknięcie nadmiernego zużycia pamięci (każdy otwarty deskryptor pliku używa pamięci jądra). Służy również jako zabezpieczenie przed błędnymi aplikacjami wyciekającymi deskryptory plików i zużywającymi zasoby systemowe.

Biorąc jednak pod uwagę, jak absurdalnie dużo pamięci RAM mają współczesne systemy w porównaniu z systemami sprzed 10 lat, myślę, że domyślne wartości są dziś dość niskie.

W 2011 r. Domyślny twardy limit deskryptorów plików w systemie Linux został zwiększony z 1024 do 4096 .

Niektóre oprogramowanie (np. MongoDB) wykorzystuje o wiele więcej deskryptorów plików niż domyślny limit. Ludzie MongoDB zalecają podniesienie tego limitu do 64 000 . Użyłem rlimit_nofile300 000 dla niektórych aplikacji.

Dopóki utrzymujesz miękki limit na domyślnym poziomie (1024), prawdopodobnie dość bezpieczne jest zwiększenie twardego limitu. Programy muszą setrlimit()sprawdzać, aby podnieść swój limit powyżej limitu miękkiego i nadal są ograniczone limitem twardym.

Zobacz także kilka powiązanych pytań:

— AB
źródło

6

To jednak tak naprawdę nie odpowiada na pytanie, które zadaje pytanie, czy istnieje techniczny lub praktyczny limit tego, jak wysoko można ustawić twardy limit . Jest, ale ta odpowiedź w ogóle o tym nie wspomina.

— JdeBP

Nie mogę podnieść limitu powyżej około 1 miliona. Myślę, że może być zakodowany na stałe w jądrze, ponieważ pomimo zmiany wielu konfiguracji nie mogę wyjść poza to. superuser.com/questions/1468436/...

— Pavel Komarov

3

Wpływ normalnie nie byłby możliwy do zaobserwowania, ale moduł IO jądra będzie musiał zająć się wszystkimi otwartymi deskryptorami plików i może również mieć wpływ na wydajność pamięci podręcznej.

Takie limity mają tę zaletę, że chronią użytkownika przed własnymi błędami (lub stronami trzecimi). Na przykład, jeśli uruchomisz mały program lub skrypt, który rozwidla się w nieskończoność, ostatecznie zablokuje się na jednym z nich ulimiti tym samym zapobiegnie bardziej intensywnemu (być może niemożliwemu do odzyskania) zawieszeniu się komputera.

O ile nie masz dokładnych powodów, aby zwiększyć którykolwiek z tych limitów, powinieneś go unikać i lepiej spać.

— Julie Pelletier
źródło

2

Jest to technicznie ograniczone do maksymalnej wartości niepodpisanego długiego (C Lang), tj. 4 294 967 295

Odniesienie: fs.hplik

/* 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 */
};

— Leonard T.
źródło

2

Czy masz na to jakieś referencje?

— Tim

Również to maksymalna wartość dla 32-bitowej podpisanej całkowitej, 32-bitowa liczba całkowita bez znaku wartości max to 4294967295.

— Sampo,

Masz rację, Sampo. Mój błąd.

— Leonard T

0

Myślę, że twoje obawy są zrozumiałe, ale najprawdopodobniej Linux nie zużyje dużo pamięci dla skonfigurowanych (ale nieużywanych deskryptorów plików) :)

Nie pamiętam takiego problemu w mojej karierze zawodowej przez ostatnie 10 lat.

Pozdrowienia.

— Tim Connor
źródło

0

Cicho późno, ale powinno to pomóc wszystkim innym uzyskać odpowiedź na to pytanie. Praktyczny limit liczby otwartych plików w systemie Linux można również policzyć przy użyciu maksymalnej liczby deskryptorów plików, które proces może otworzyć.

Widziałem zmiany limitów z systemu na system. Na stronie podręcznika użytkownika getlimit można zobaczyć, która RLIMIT_NOFILE-1określa limity wewnętrznie.

Aby sprawdzić wartość RLIMIT_NOFILE, możesz użyć poniższej instrukcji, aby uzyskać krotkę

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

Krotka zwraca wyniki jako (Soflimit, hardlimit). Dla mnie działa na wielu systemach wyniki są jak poniżej

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

Uwaga: 9223372036854775807 liczba ta oznacza po prostu nieskończoność. Zawsze osiągniesz inne limity zasobów, zanim to osiągniesz. Jeśli zmodyfikujesz hardlimit w systemie ponad to, czym on jest, będziesz musiał zmodyfikować parametry jądra.

— Ankit Kulkarni
źródło