¿Por qué me niegan la conexión después de 1024 conexiones?

Question

Estoy probando en un servidor Linux local con el servidor y el cliente en el mismo servidor. Después de aproximadamente 1024 conexiones, en mi código, donde me conecto, me niegan la conexión. Al principio pensé que era el límite de fd_set_max de 1024 para seleccionar y cambiar el servidor para hacer una encuesta en lugar de seleccionar y todavía no supero este número. Mi ulimit -n se establece en 2048 y superviso el lsof en el servidor que alcanza aproximadamente 1033 (no estoy seguro de si este es el número exacto) y falla. Cualquier ayuda es muy apreciada.

Answer 1

Así que, después de un poco más de investigación ... parece que mi servidor de escucha tiene una profundidad de cola de 20. Creo que ese es el motivo. ¿Alguno de ustedes piensa que ese es el problema también?

Saludos

Answer 2

Quizás haya alcanzado su límite de proceso para los descriptores de archivos abiertos.

No estoy seguro si lo entiendo correctamente: ¿tiene el lado del servidor y el lado del cliente en el mismo proceso? Entonces usarás el doble de descriptores de archivos. Eso se acerca a lo que ves con ulimit. Si ese no es el caso, ¿podría ser el problema del lado del servidor? Tal vez el proceso del servidor se quede sin descriptores y ya no pueda aceptar más conexiones.

El accept man page menciones que debe obtener un valor de retorno:

EMFILE
El límite por proceso de descriptores de archivos abiertos se ha alcanzado.

ENFILE
Se alcanzó el límite del sistema en la cantidad total de archivos abiertos.

¿Qué código de error obtiene? Obviamente, solo puede agregar conexiones que fueron _accept_ed con éxito en seleccione o encuesta.

Sé que ya sabe cómo comprobar ulimit, pero otros no pueden:

ulimit -a 
core file size   (blocks, -c) 0 
data seg size   (kbytes, -d) unlimited 
scheduling priority    (-e) 0 
file size    (blocks, -f) unlimited 
pending signals     (-i) 40448 
max locked memory  (kbytes, -l) 32 
max memory size   (kbytes, -m) unlimited 
open files      (-n) 4096 
pipe size   (512 bytes, -p) 8 
POSIX message queues  (bytes, -q) 819200 
real-time priority    (-r) 0 
stack size    (kbytes, -s) 8192 
cpu time    (seconds, -t) unlimited 
max user processes    (-u) 40448 
virtual memory   (kbytes, -v) unlimited 
file locks      (-x) unlimited 

Answer 3

¿Hay algún peligro de que el servidor se abre un archivo de registro separado para cada conexión se acepta?

¿Qué límite superior dice el otro grupo que tiene el servidor?

Había un código en un programa que cuidé (hace unos años) que estableció el tamaño máximo de archivo en 1 MB. Fue una lástima que cuando se agregó por primera vez, aumentó el tamaño, pero el paso del tiempo y el crecimiento de los límites de archivos significaban más tarde que estaba reduciendo el tamaño. ¿Hay alguna posibilidad de que el servidor tenga un problema similar, establece la cantidad máxima de archivos abiertos en un número ridículamente alto como 1024?

Answer 4

Disculpas por preguntas principalmente triviales :)
¿Combinó el servidor cuando dice "cambiado a encuesta"? ¿El servidor se ejecuta con la misma cuenta? ¿Es un servidor fork -ing o quizás un servidor con subprocesos? ¿Obtiene errno == ECONNREFUSED después de llamar al connect() en el cliente? ¿Puedes confirmar que obtienes un RST en respuesta al SYN con tcpdump? ¿Se vuelven a utilizar los números de puerto del cliente? ¿Hay conexiones en el estado TIME_WAIT?

Answer 5

Si se está conectando más rápido de lo que su servidor llama al accept(), la cola de conexiones pendientes puede estar llena. La longitud máxima de la cola la establece el segundo argumento en listen() en el servidor, o el valor de sysctl net.core.somaxconn (normalmente 128) si es menor.

Answer 6

Su limitación es de la limitación del usuario de linux. Si no se especifica, los límites de Linux son para 1024 archivos abiertos. Para cambiar de forma permanente que editar y añadir /etc/security/limits.conf

usuario suave nofile 16535 usuario duro nofile 16535

o desde la consola tratar

ulimit -n 16535

Saludos

Answer 7

vi el comentario que hizo con la estrecha declaración (sock_fd) en un error rutina de control.

¿Está cerrando explícitamente los sockets después de su uso? Close() o shutdown().

Supongo que no. ¿En realidad tienes más de 1024 conexiones activas simultáneas? Tendría que tener pthreads involucrados para poder hacer esto. ¿Es eso correcto?

Answer 8

Tuve los mismos síntomas. Incluso después de aumentar ulimit -n aún no podía manejar más de 1024 conexiones entrantes ...

Mi problema fue que utilicé select, que no puede manejar socket-FDs por encima de 1024. Así que cuando aumente mi límite mi problema en realidad cambiado !!! (que no me di cuenta al principio ...)

Así que para ayudar a cualquier persona con problemas similares:

Si desea más de 1024 toma lo que tiene que

• aumento su límite para FDs abierta (ulimit -n)
• y es posible que no utilice seleccione() (utilizar sondeo() en su lugar)