Mayor número máximo permitido de archivos abiertos en Linux

10

¿Existe un límite (técnico o práctico) para el tamaño que puede configurar el número máximo de archivos abiertos en Linux? ¿Hay algunos efectos adversos si lo configura en un número muy grande (digamos 1-100M)?

Estoy pensando en el uso del servidor aquí, no en los sistemas integrados. Los programas que utilizan grandes cantidades de archivos abiertos pueden, por supuesto, consumir memoria y ser lentos, pero estoy interesado en los efectos adversos si el límite se configura mucho más de lo necesario (por ejemplo, memoria consumida solo por la configuración).

— Sampo
fuente

En teoría, podría calcular cuántos descriptores de archivos podría manejar su sistema en función de la memoria disponible y la afirmación de que cada fd consume 1K de memoria: serverfault.com/questions/330795/…

— Alastair McCormack

10

Sospecho que la razón principal del límite es evitar el consumo excesivo de memoria (cada descriptor de archivo abierto usa memoria del núcleo). También sirve como protección contra aplicaciones con errores que filtran descriptores de archivos y consumen recursos del sistema.

Pero dado lo absurdamente que muchos sistemas modernos de RAM han comparado con los sistemas de hace 10 años, creo que los valores predeterminados de hoy son bastante bajos.

En 2011, el límite rígido predeterminado para los descriptores de archivos en Linux aumentó de 1024 a 4096 .

Algunos programas (por ejemplo, MongoDB) usan muchos más descriptores de archivos que el límite predeterminado. La gente de MongoDB recomienda elevar este límite a 64,000 . He usado rlimit_nofile300,000 para ciertas aplicaciones.

Siempre que mantenga el límite flexible en el valor predeterminado (1024), probablemente sea bastante seguro aumentar el límite rígido. Los programas tienen que llamar setrlimit()para aumentar su límite por encima del límite flexible, y todavía están limitados por el límite rígido.

Vea también algunas preguntas relacionadas:

— AB
fuente

66

Sin embargo, esto no ha respondido realmente a la pregunta, que preguntaba si había un límite técnico o práctico sobre qué tan alto se puede establecer el límite estricto . La hay, pero esta respuesta no la menciona en absoluto.

— JdeBP

Me resulta imposible elevar el límite más allá de aproximadamente 1 millón. Creo que podría estar codificado en el núcleo, porque a pesar de cambiar muchas configuraciones, no puedo subir más allá de esto. superuser.com/questions/1468436/…

— Pavel Komarov

3

El impacto normalmente no sería observable, pero el módulo de E / S del núcleo tendrá que ocuparse de todos los descriptores de archivos abiertos y también podrían tener un impacto en la eficiencia de la memoria caché.

Dichos límites tienen la ventaja de proteger al usuario de sus propios errores (o de terceros). Por ejemplo, si ejecuta un pequeño programa o script que se bifurca indefinidamente, eventualmente se bloqueará en uno de los ulimits y, por lo tanto, evitará una congelación de la computadora más intensa (posiblemente irrecuperable).

A menos que tenga razones precisas para aumentar cualquiera de esos límites, debe evitarlo y dormir mejor.

— Julie Pelletier
fuente

2

Está técnicamente limitado al valor máximo de largo sin signo (C Lang), es decir, 4,294,967,295

Referencia: fs.harchivo

/* 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
fuente

2

¿Tienes alguna referencia para esto?

— Tim

También que es el valor máximo de 32 bits firmada número entero de 32 bits sin signo valor máximo número entero es 4294967295.

— Sampo

Tienes razón, Sampo. Mi error.

— Leonard T

0

Creo que su preocupación es comprensible, pero lo más probable es que Linux no consuma mucha memoria para los descriptores de archivos configurados (pero no utilizados) :)

No recuerdo ese problema en mi carrera profesional durante los últimos 10 años.

Saludos.

— Tim Connor
fuente

0

Silencio tarde, pero esto debería ayudar a todos los demás a obtener la respuesta a esta pregunta. El límite práctico para el número de archivos abiertos en Linux también se puede contar utilizando el número máximo de descriptor de archivo que puede abrir un proceso.

He visto que se cambian los límites de un sistema a otro. Desde la página de manual de getlimit puede ver que RLIMIT_NOFILE-1especifica los límites internamente.

Para verificar el valor RLIMIT_NOFILE puede usar la siguiente declaración para obtener una tupla

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

La tupla devuelve resultados como (Soflimit, hardlimit). Para mí, en varios sistemas, los resultados son los siguientes

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

Nota: 9223372036854775807 este número simplemente significa infinito. Siempre alcanzará otros límites de recursos antes de llegar a esto. Si tiene que modificar el límite rígido en un sistema más allá de lo que es, tendrá que modificar los parámetros del kernel.

— Ankit Kulkarni
fuente