Article ID: 118693, created on Jan 9, 2014, last review on Oct 3, 2014

  • Applies to:
  • Operations Automation
  • Panels
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor

Síntomas

En /var/log/messages en el nodo hardware aparecen los siguientes mensajes de error:

[2814258.430156] TCP: time wait bucket table overflow (CT101) 
[2814258.449661] TCP: time wait bucket table overflow (CT101) 
[2814258.450743] TCP: time wait bucket table overflow (CT101) 
[2814258.475297] TCP: time wait bucket table overflow (CT101)

¿Qué significan estos errores y cómo puedo corregirlos?

Resolución

Estos mensajes significan que los depósitos TW (sockets TCP en estado TIME_WAIT) alcanzan su límite por lo que respecta a la memoria del kernel.

Puede descubrir la cantidad actual de conexiones TIME_WAIT (tw_count) usando la utilidad netstat:

[root@vz ~]# netstat -antp | grep TIME_WAIT
tcp        0      0 127.0.0.1:8080              127.0.0.1:35550             TIME_WAIT   -
tcp        0      0 127.0.0.1:8080              127.0.0.1:35562             TIME_WAIT   -
tcp        0      0 127.0.0.1:8080              127.0.0.1:35568             TIME_WAIT   -
tcp        0      0 ::ffff:127.0.0.1:37849      ::ffff:127.0.0.1:25         TIME_WAIT   -

[root@vz ~]# netstat -antp | grep TIME_WAIT | wc -l
4

Este problema puede experimentarse en los siguientes casos:

1) El tw_count a nivel de sistema es superior al límite max_tw_buckets a nivel de sistema:

    [root@vz ~]# sysctl -a | grep tcp_max_tw_buckets
    net.ipv4.tcp_max_tw_buckets = 262144

El límite es bastante elevado, por lo que no es probable que se alcance. De todos modos, este sysctl puede aumentarse si es necesario.

2) El contador a nivel de VE es superior al límite max_tw_buckets a nivel de VE:

    [root@vz ~]# sysctl -a | grep tcp_max_tw_buckets_ub
    net.ipv4.tcp_max_tw_buckets_ub = 16536

Aumente el sysctl para resolver la incidencia.

3) En un VE, tw_buckets consume demasiada memoria y supera el límite de la fracción permitida de kmemsize.

    [root@vz ~]# vzctl exec 101 sysctl -a 2>/dev/null| grep net.ipv4.tcp_max_tw_kmem_fraction
    net.ipv4.tcp_max_tw_kmem_fraction = 384

384 significa un 38.4% del kmemsize.

En este caso, no se registrará ningún contador con errores para el contenedor, por lo que es bastante difícil realizar un seguimiento adecuado. Intente aumentar el valor del parámetro kmemsize para el contenedor y examine si vuelve a obtener los mensajes.

4) Escasez de kmemsize en un VE. En este caso deberían registrarse algunos contadores nuevos con errores para el parámetro kmemsize. Realice la comprobación correspondiente:

    [root@vz ~]# awk '$6' /proc/bc/101/resources
                kmemsize                 16587096             18132992             24299200             26429120                    126

La última columna muestra el número de veces que se ha excedido el parámetro. De alcanzarse el límite, aumente el valor del parámetro kmemsize para el contenedor.

a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 d02f9caf3e11b191a38179103495106f e8e50b42231236b82df27684e7ec0beb 5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 0dd5b9380c7d4884d77587f3eb0fa8ef 614fd0b754f34d5efe9627f2057b8642 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article
Save as PDF