8.2. Parámetros de redes optimizadas
El ajuste de rendimiento suele realizarse en un modo de prevaciado. A menudo, ajustamos variables conocidas antes de ejecutar la aplicación o implementar un sistema. Si los sondeos de ajuste no son efectivos, tratamos de ajustar otras variables. La lógica detrás de este pensamiento es que de forma predeterminada, el sistema no está funcionando en un nivel óptimo de rendimiento; como tal, pensamos que debemos ajustar el sistema como corresponde. En algunos casos lo hacemos mediante conjeturas.
Como se mencionó anteriormente, la pila de redes es principalmente auto-optimizadora. Además, para un ajuste de red efectivo se requiere un entendimiento profundo no solamente de la forma como funciona la red, sino también de los requerimientos de recursos de red. La configuración de rendimiento de red incorrecta, puede conducir a un rendimiento degradado.
Por ejemplo considere el Problema bufferfloat . Al aumentar el valor de cola del búfer, las conexiones TCP que tienen ventanas de congestión más grandes que el enlace se permitirían (debido al alto valor de búfer). Sin embargo, dichas conexiones también tienen amplios valores RTT, puesto que los marcos consumen mucho tiempo en cola. A su vez, produce una salida subóptima, ya que sería imposible detectar la congestión.
Cuando se trata del rendimiento de redes, es aconsejable mantener los parámetros predeterminados a menos que se haga evidente un problema de rendimiento particular. Problemas como tal, incluyen pérdida de marco, reducción significativa de rendimiento y similares. Aún así, la mejor solución suele ser la que resulta de un estudio meticuloso del problema, en lugar de simplemente ajustar los parámetros a lo alto (aumentando las longitudes de cola y búfer y reduciendo latencia de interrupciones, etc).
Las siguientes herramientas le servirán para diagnosticar correctamente el problema de rendimiento de red:
- netstat
- Una herramienta de línea de comandos que imprime conexiones de redes, tablas de rutas, estadísticas de interfaz, conexiones de máscara y membresías multidifusión. Recupera la información sobre el subsistema de redes del sistema de archivos
/proc/net/
. Dichos archivos incluyen:/proc/net/dev
(información de dispositivos)/proc/net/tcp
(Información de socket TCP)/proc/net/unix
(Informaciónn de sockete de dominio Unix)
Para obtener mayor información sobrenetstat
y sus archivos mencionados en/proc/net/
, consulte la página de manualnetstat
:man netstat
. - dropwatch
- Una herramienta que monitoriza los paquetes eliminados por el kernel. Para mayor información, consulte la página de manual
dropwatch
:man dropwatch
. - ip
- Una herramienta para administrar y monitorizar rutas, dispositivos, y políticas túneles y rutas de políticas . Para obtener mayor información, consulte la página de manual de
ip
:man ip
. - ethtool
- Una herramienta para desplegar y cambiar los parámetros NIC. Para obtener mayor información, consulte la página de manual
ethtool
:man ethtool
. - /proc/net/snmp
- Un archivo que muestra datos ASCII necesarios para las bases de información de administración de IP, ICMP, TCP, y UDP para un agente
snmp
. También despliega estadísticas de UDP-lite en tiempo real
La Guía para principiantes de SystemTap contiene varias muestras de scripts que puede utilizar para perfilar y monitorizar el rendimiento de redes. Esta guía está disponible en http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
Después de recolectar los datos relevantes sobre el problema de rendimiento de redes, podrá formular una teoría — y, posiblemente, una solución. [5] Por ejemplo, un aumento en errores de entrada UDP en
/proc/net/snmp
indica que uno o más conectores de colas de recepción se llena cuando la pila de redes intenta poner en cola nuevos marcos dentro de un socket de aplicación.
Esto indica que los paquetes están trancados en por lo menos una cola de socket, es decir que la cola del socket drena muy lentamente los paquetes o que el volumen de paquetes es demasiado grande para dicha cola de socket. Si se trata de esta última, entonces verifique la pérdida de datos en los registros de aplicación intensiva de redes, para resolverlo, deberá optimizar o reconfigurar la aplicación infractora.
Tamaño de búfer de recepción de socket
Los tamaños de búfer de recepción y envío de socket se ajustan de forma dinámica, por lo tanto, muy pocas veces necesitará modificarlos de forma manual. Si se requiere un mayor análisis, tal como el presentado en el ejemplo de red SystemTap,
sk_stream_wait_memory.stp
sugiere que la tasa de drenaje de cola de socket sea demasiado baja, para que luego usted pueda aumentar la profundidad de cola del socket de la aplicación. Para hacerlo, aumente el tamaño de los búferes utilizados por conectores, mediante la configuración de alguno de los siguientes valores:
- rmem_default
- Un parámetro de kernel que controla el tamaño predeterminado de búferes de recepción utilizado por conectores. Para configurarlo, ejecute el siguiente comando:
sysctl -w net.core.rmem_default=N
RemplaceN
por el tamaño en bytes del búfer deseado. Para determinar el valor para este parámetro de kernel, vea/proc/sys/net/core/rmem_default
. Tenga en cuenta que el valor dermem_default
no debería ser mayor quermem_max
(/proc/sys/net/core/rmem_max
); en caso de serlo, aumente el valor dermem_max
. - SO_RCVBUF
- Una opción de conexión que controla el tamaño máximo de un búfer de recepción de socket, en bytes. Para obtener mayor información sobre
SO_RCVBUF
, consulte la página de manual:man 7 socket
.Para configurarSO_RCVBUF
, use la herramientasetsockopt
. Puede recuperar el valor actual deSO_RCVBUF
congetsockopt
. Para obtener mayor información sobre el uso de estas dos herramientas, consulte la página de manual desetsockopt
:man setsockopt
.
[5]
Sección 8.3, “Visión general de recepción de paquetes” contiene una visión general de viaje de paquetes, que ayudarán a localizar y trazar áreas propensas a cuellos de botellas.