- January 2012
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- July 2007
- Makendra It's always a pleasure to hear from someone with eexrpitse....
- Rubén Ortiz Hola dependerá de varias cosas pero la respuesta sería NO. ...
- jose miguel perea Buenos días, ¿La replicación entre maestro y esclavo es i...
- Rubén Ortiz Si lo hacéis legal, con VMware el único problema son los cos...
- Angel Hola, estamos valorando implementar baremetal para crear un ...
OpenVZ – TCP: time wait bucket table overflow
En servidores de producción, de alta carga de tráfico virtualizados con OpenVZ, podemos llegar a visualizar un error como este:
1 2 | TCP: time wait bucket table overflow (CT249043) printk: 7 messages suppressed. |
Este error es sinónimo de problemas, problemas reales relacionados con el servicio que el container ofrece. Lo bueno es que es un error que podemos resolver, aún a costa de aumentar los recursos asignados a un determinado container.
Los síntomas son difíciles de apreciar, porque el servicio no deja de funcionar de repente sino que es más bien una degradación paulatina. Lo primero que hemos de hacer es un dmesg para ver que todo va bien
1 | <strong># dmesg</strong> |
o
1 | <strong>cat /var/log/messages</strong> |
Por eso, lo segundo es repasar el user_beancounters en busca de fallos
1 | <strong>/proc/user_beancounters</strong> |
Si vemos fallos en kmemsize, lo cual será muy probable, ya tenemos más pistas sobre el problema de nuestro anfitrión (y containers). Necesitamos aumentar un valor concreto del sysctl.conf, el tcp_max_tw_buckets_ub. En anteriores versiones del kernel OpenVZ, tenía un valor por defecto muy bajo. Se aplicaron cambios y se subió ese valor pero en algunos entornos, de alto tráfico, puede ser insuficiente
1 | <strong># vim /etc/sysctl.conf</strong> |
o
1 | <strong># echo 65536 > /proc/sys/net/ipv4/tcp_max_tw_buckets</strong> |
o
1 | <strong># echo 65536 > /proc/sys/net/ipv4/tcp_max_tw_buckets_ub</strong> |
donde tcp_max_tw_buckets_ub es el límite por VPS y tcp_max_tw_buckets es el límite global.
Podemos editar directamente el sysctl.conf o modificar el valor directamente sobre el parámetro en cuestión. Para aplicar los cambios
1 | <strong># sysctl -p</strong> |
y para comprobar que, se han aplicado correctamente
1 | <strong># sysctl -a | grep tw</strong> |
1 2 3 4 5 | net.ipv4.tcp_max_tw_buckets_ub = 65536 net.ipv4.tcp_max_tw_kmem_fraction = 384 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_max_tw_buckets = 180000 |
- http://forum.openvz.org/index.php?t=msg&goto=10217&
- http://bugzilla.openvz.org/show_bug.cgi?id=460
- http://forum.openvz.org/index.php?t=msg&goto=25452&
- http://forum.openvz.org/index.php?t=msg&goto=30522&
- http://forum.openvz.org/index.php?t=msg&goto=25441&
- http://forum.swsoft.com/showthread.php?t=26770&pp=15