- 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 ...
Orphaned socket dropped
Desde hace varios días, observo en una máquina con gran carga de tráfico, unos mensajes en el HN(Hardware Node) relativos a los socket. Se puede ver fácilmente haciendo un grep en el messages:
1 | <strong># cat /var/log/messages | grep 'socket'</strong> |
1 2 3 | [...] <strong>Apr 20 20:46:32 hn248 kernel: Orphaned socket dropped (156,624 in CT248)</strong> [...] |
Este error se produce en el punto crítico, de más carga de transferencia en la máquina en cuestión. La mayor parte del tiempo el comportamiento del hardware y el kernel VZ es excelente. Sin embargo, estos problemas puntuales afectan al servicio tan necesario en esos momentos críticos, los de más demanda, los que pueden hacer que tu producto funcione mejor o peor, y que pueden hacer tu vida más fácil o un infierno(bueno ahí me he pasado).
Haciendo una búsqueda en google, yo al menos, no encontré mucha información. Por ello me dirigí a los que realmente saben de esto, los del foro de OpenVZ. Ahí encontré las pistas clave para intentar mitigar este problema e intentar que no vuelva a ocurrir.
Hay 3 casos en los que se puede percibir este problema:
- 1)El número de sockets huérfanos en una VE es >= 1/4 * (numtcpsock.barrier)
- 2)El número de sockets huérfanos en una VE es > (sysctl net.ipv4.tcp_max_orphans)
- 3)Condiciones de memoria más especiales
Vamos a repasar los dos primeros casos en función de los parámetros establecidos a la VE problemática.
1 | <strong># cat /etc/conf/249042.conf</strong> |
=> NUMTCPSOCK=”1600:1600″
1 | <strong>#sysctl -a | grep 'max_orphans'</strong> |
=> net.ipv4.tcp_max_orphans = 32768
Es decir, en algún momento nuestra máquina ha excedido el límite de sockets huérfanos configurado en el sysctl o bien, en algún momento el número de sockets habilitados se acercó o sobrepasó los 400(en nuestro caso). Entonces, en cualquiera de los dos casos el sistema empieza a descartar paquetes. El gran problema es que esto no se muestra en el ¡/proc/user_beancounters!. Sólo un vistazo al dmesg o al log de mensajes del syslog puede dar con el.
No hemos encontrado indicaciones sobre como o en que forma aumentar el número de sockets huérfanos permitidos pero, en todo caso, se trataría de ajustar el valor siempre con moderación y no a lo bruto, porque tocar el sysctl puede hacer realidad el refrán de “peor el remedio que la enfermedad”. En otro post contaré como me fue y que parámetros ajusté para intentar resolver este problema.
Para más información: Foros OpenVZ
Pêrsonalmente mas que buscar la manera de aumentar la otlerancia a tcp_orphans, buscaria la manera de no tener tcp_orphans. Vamso que me tiraria por aumentar el numtcpsock.barrier