Entradas de tabla hash establecidas por TCP en Ubuntu 14.04

Entradas de tabla hash establecidas por TCP en Ubuntu 14.04

Un poco de trasfondo

Estoy ejecutando dos servidores con mucho tráfico, uno con ubuntu 12.04 (linux 3.2.0-69-generic) y otro con ubuntu 14.04 (linux 3.13.0-52-generic). Ahora estoy intentando asegurar ambos. Ambos tienen recursos de hardware muy similares (la misma cantidad de CPUS, pero el 12.04 tiene sólo 8 GB de RAM mientras que el 14.04 tiene 16 GB).

Quería habilitar el firewall ufw, pero tuve algunos problemas con la tabla nf_conntrack al llenarse. Básicamente, los paquetes se estaban cayendo.

Encontré una solución reduciendo los tiempos de espera y aumentando el tamaño de la tabla, así como la cantidad de depósitos. Eso es:

net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_max = 196608
net.netfilter.nf_conntrack_buckets = 24576

Estos valores se actualizan correctamente y sobreviven al reinicio. (Vereste blog) También veo que conntrack_count se eleva muy por encima del valor predeterminado, así que estoy seguro de que esto funciona en ambos servidores. Los valores se mantienen muy por debajo de los límites, así que estoy seguro de que está bien.

La cuestión

El servidor 12.04 funciona bien bajo carga alta, pero el 14.04 sigue descartando paquetes, lo que genera tiempos de espera en el cliente. Ahora, al iniciar el 14.04, puedo ver esta línea en kern.log:

TCP established hash table entries: 131072 (order: 8, 1048576 bytes)

Mientras que el 12.04, es:

TCP established hash table entries: 524288 (order: 11, 8388608 bytes)

Sospecho que esta puede ser la razón por la que mi servidor está descartando paquetes, ya que esta tabla puede ser demasiado pequeña con respecto a la cantidad de tráfico el 14.04.

Entonces intenté buscar una manera de establecer este tamaño y encontré el parámetro thash_entriesmira aquípara explicación). Sin embargo, no puedo configurarlo con sysctl.

Asi que aqui están mis preguntas:

  1. ¿Es esta tabla de conexión TCP realmente la fuente de mi problema? ¿O debería buscar en otro lado?
  2. Si es así, ¿cómo puedo configurarlo y hacer que sobreviva al reinicio?

Gracias de antemano por cualquier ayuda y no dudes en preguntarme si necesitas más ayuda.

PD: Soy más un desarrollador que un experto en sistemas, por lo que agradecería cualquier respuesta detallada :)

Respuesta1

Ajustar el kernel de Linux para lograr un alto rendimiento de la red es un arte basado en el equilibrio.

Aumentar la tabla de seguimiento de conexiones está bien, pero significa que potencialmente se utilizan más sockets, lo que a su vez significa que el sistema necesita más descriptores de archivos y la rueda continúa...

En su caso, comenzaría con la siguiente configuración del kernel:

net.core.somaxconn

y

fs.file-max

El primero determina la cantidad de sockets abiertos que mantendrá el núcleo. El segundo se utiliza para establecer la cantidad de descriptores de archivos usados ​​que serán admitidos por el kernel.

Luego está el trabajo pendiente de SYN que se puede modificar aún más.

net.ipv4.tcp_max_syn_backlog

Establecerá la cantidad de conexiones que pueden estar en espera de un ACK de su servidor.

net.ipv4.tcp_syncookies

Para que SYN Backlog funcione, debe habilitar las cookies TCP SYN.

Finalmente, también se pueden realizar algunos ajustes, como habilitar la reutilización de la conexión TIME_WAIT.

net.ipv4.tcp_tw_reuse

Potencialmente, esto puede reducir la cantidad de enchufes "nuevos" que se abrirían cuando reciba un pico.

Eso es sólo la punta del iceberg, mi experiencia con un sistema Linux/Unix de gran volumen es que hay que modificarlo durante un par de meses antes de obtener el equilibrio adecuado.

Asegúrese de revisar los errores /var/log/kern.logy /var/log/messagesayudar a solucionar más problemas.

Núcleo de ajuste

Guía de administración de informática de alto rendimiento

información relacionada