30 votos

Optimización de Linux enrutamiento IP parámetros -- secret_interval y tcp_mem

Tuvimos un pequeño problema de conmutación por error con uno de nuestros HAProxy VMs hoy en día. Cuando se excava en ella, encontramos esto:

Jan 26 07:41:45 haproxy2 kernel: [226818.070059] __ratelimit: 10 devoluciones de llamada suprimida
Jan 26 07:41:45 haproxy2 kernel: [226818.070064] de socket de memoria
Jan 26 07:41:47 haproxy2 kernel: [226819.560048] de socket de memoria
Jan 26 07:41:49 haproxy2 kernel: [226822.030044] de socket de memoria

Que, por este enlace, al parecer, tiene que ver con el bajo nivel de la configuración predeterminada de net.ipv4.tcp_mem. Así que el aumento de ellos por 4x de sus valores por defecto (esto es Ubuntu Server, no se si el sabor de Linux):

los valores actuales son: 45984 61312 91968
los nuevos valores son: 183936 245248 367872

Después de eso, empezamos a ver un extraño mensaje de error:

Jan 26 08:18:49 haproxy1 kernel: [ 2291.579726] Ruta hash de la cadena demasiado larga!
Jan 26 08:18:49 haproxy1 kernel: [ 2291.579732] Ajustar su secret_interval!

Shh.. es un secreto!!

Este, al parecer, tiene que ver con /proc/sys/net/ipv4/route/secret_interval que el valor predeterminado es 600 y los controles periódicos de vaciado de la caché de ruta

El secret_interval indica al kernel de cómo a menudo a desaparecer TODOS los de la ruta hash entradas independientemente de cómo las nuevas/viejas que son. En nuestro medio esto es generalmente malo. La CPU va a ser ocupados en la reconstrucción de miles de entradas por en segundo lugar, cada vez que se borra la cache. Sin embargo hemos creado este se ejecute una vez al día para evitar fugas de memoria en la bahía (aunque nunca hemos tenido uno).

Mientras que somos felices para reducir esto, parece raro recomendar soltando toda la caché de ruta a intervalos regulares, en lugar de simplemente empujando a los viejos valores de la caché de ruta más rápida.

Después de algunas investigaciones, hemos encontrado /proc/sys/net/ipv4/route/gc_elasticity que parece ser una mejor opción para mantener la ruta tamaño de la tabla:

gc_elasticity puede ser mejor descrito como el promedio de profundidad de la cubeta el kernel aceptará antes de que comience la expiración en la ruta de hash de entradas. Esto ayudará a mantener el límite superior de rutas activas.

Hemos ajustado la elasticidad de 8 a 4, en la esperanza de la ruta de caché de la poda de sí mismo de forma más agresiva. El secret_interval no se siente correcto para nosotros. Pero hay un montón de opciones de configuración y es claro que son realmente el camino a seguir aquí.

  • /proc/sys/net/ipv4/route/gc_elasticity (8)
  • /proc/sys/net/ipv4/route/gc_interval (60)
  • /proc/sys/net/ipv4/route/gc_min_interval (0)
  • /proc/sys/net/ipv4/route/gc_timeout (300)
  • /proc/sys/net/ipv4/route/secret_interval (600)
  • /proc/sys/net/ipv4/route/gc_thresh (?)
  • rhash_entries (parámetro del kernel, por defecto desconocido?)

No queremos hacer el Linux de enrutamiento peor, así que estamos un poco de miedo meterse con algunos de estos ajustes.

Puede alguien aconsejar que el enrutamiento de los parámetros son los mejores para sintonizar, para un alto tráfico de HAProxy instancia?

28voto

Willy Tarreau Puntos 2913

Nunca he encontrado con este problema. Sin embargo, probablemente debería aumentar su tabla de hash de ancho con el fin de reducir su profundidad. El uso de "dmesg", podrás ver cuántas entradas que actualmente tiene:

$ dmesg | grep '^IP route'
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

Puede cambiar este valor con el kernel de arranque parámetro de línea de comandos rhash_entries. El primer intento con la mano, a continuación, añadir a su lilo.conf o grub.conf.

Por ejemplo: kernel vmlinux rhash_entries=131072

Es posible que usted tenga una muy limitada de la tabla hash, porque usted ha asignado poco de memoria a su HAProxy VM (la ruta de hash de tamaño se ajusta dependiendo de la cantidad total de RAM).

Relativa tcp_mem, tenga cuidado. Su configuración inicial me hacen pensar que se estaban ejecutando con 1 GB de RAM, 1/3 de lo que podría ser asignados a las conexiones TCP. Ahora que usted ha asignado 367872 * 4096 bytes = 1.5 GB de RAM para sockets TCP. Usted debe ser muy cuidadoso de no quedarse sin memoria. Una regla del pulgar es la asignación de 1/3 de la memoria a HAProxy y otro 1/3 de la pila TCP y el último 1/3 para el resto del sistema.

Tengo la sospecha de que su "fuera de socket de la memoria" mensaje viene de la configuración predeterminada en tcp_rmem y tcp_wmem. Por defecto, usted tiene 64 kB asignado en la salida para cada socket y 87 kB en la entrada. Esto significa un total de 300 kB de un proxy de conexión, sólo para el socket de búferes. Añadir a que el 16 o 32 kB para HAProxy, y se ve que con 1 GB de RAM sólo tendrás apoyo 3000 conexiones.

Al cambiar la configuración predeterminada de tcp_rmem y tcp_wmem (media param), usted puede obtener una gran cantidad más baja en la memoria. Puedo obtener buenos resultados con valores tan bajos como 4096 para el búfer de escritura, y 7300 o 16060 en tcp_rmem (5 o 11 segmentos TCP). Puede cambiar la configuración sin reiniciar, sin embargo, que sólo se aplicará a las nuevas conexiones.

Si usted prefiere no tocar su sysctls demasiado, la última HAProxy, 1.4-dev8, permite ajustar los parámetros de la configuración global, y por lado (cliente o servidor).

Tengo la esperanza de que esto ayude!

8voto

siddhadev Puntos 6083

El Out of socket memory error es a menudo engañosa. La mayoría de las veces, en Internet los servidores, ¿ no indica ningún problema relacionados con el funcionamiento de la memoria. Como he explicado en más detalles en un post en el blog, la razón más común es que el número de huérfanos sockets. Un huérfano de socket es un socket que no está asociado a un descriptor de archivo. En ciertas circunstancias, el kernel problema de la Out of socket memory error a pesar de que usted 2x o 4x distancia desde el límite (/proc/sys/net/ipv4/tcp_max_orphans). Esto sucede con frecuencia en Internet los servicios y es perfectamente normal. El curso de acción correcto en este caso es para afinar tcp_max_orphans a ser, al menos, 4 veces el número de huérfanos que normalmente vemos con su pico de tráfico.

No hagas caso a los consejos que recomienda optimización tcp_mem o tcp_rmem o tcp_wmem menos que realmente sepas lo que estás haciendo. Aquellos que dan un vistazo a estos consejos no suelen. Su vudú es a menudo incorrecto o inapropiado para su entorno y no va a resolver tu problema. Incluso podría empeorar las cosas.

-3voto

John Smithers Puntos 1459

Podemos ajustar algunos de estos parámetros con regularidad. Nuestro estándar de alto rendimiento, baja latencia de plataformas de comercio es:

net.ipv4.tcp_rmem = 4096 16777216 33554432
net.ipv4.tcp_wmem = 4096 16777216 33554432
net.ipv4.tcp_mem = 4096 16777216 33554432
net.núcleo.rmem_default = 16777216
net.núcleo.wmem_default = 16777216
net.núcleo.rmem_max=16777216
net.núcleo.wmem_max=16777216
net.núcleo.netdev_max_backlog = 30000
net.núcleo.netdev_max_backlog = 30000

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: