Conecté directamente dos crossover PowerEdge 6950 (usando líneas rectas) en dos adaptadores PCIe diferentes.
Obtengo un enlace gigabit en cada una de estas líneas (1000 MBit, full duplex, control de flujo en ambas direcciones).
Ahora estoy tratando de vincular estas interfaces en bond0 usando el algoritmo rr en ambos lados (quiero obtener 2000 MBit para una sola sesión IP).
Cuando probé el rendimiento transfiriendo / dev / zero a / dev / null usando dd bs = 1M y netcat en modo tcp, obtuve un rendimiento de 70 MB / s, no, como se esperaba más de 150 MB / s.
Cuando uso las líneas individuales obtengo aproximadamente 98 MB / s en cada línea, si uso una dirección diferente para cada línea. Cuando uso las líneas simples obtengo 70 MB / sy 90 MB / s en la línea, si el tráfico va en la "misma" dirección.
Después de leer el archivo readme (/usr/src/linux/Documentation/networking/bonding.txt) encontré que la siguiente sección es útil: (13.1.1 Selección del modo de enlace MT para topología de interruptor único)
balance-rr: este modo es el único modo que permitirá que una sola conexión TCP / IP distribuya el tráfico a través de múltiples interfaces. Por lo tanto, es el único modo que permitirá que una sola transmisión TCP / IP utilice el rendimiento de más de una interfaz. Sin embargo, esto tiene un costo: el trazado de bandas a menudo da como resultado que los sistemas pares reciban paquetes fuera de servicio, lo que hace que el sistema de control de congestión de TCP / IP se active, a menudo retransmitiendo segmentos.
It is possible to adjust TCP/IP's congestion limits by altering the net.ipv4.tcp_reordering sysctl parameter. The usual default value is 3, and the maximum useful value is 127. For a four interface balance-rr bond, expect that a single TCP/IP stream will utilize no more than approximately 2.3 interface's worth of throughput, even after adjusting tcp_reordering. Note that this out of order delivery occurs when both the sending and receiving systems are utilizing a multiple interface bond. Consider a configuration in which a balance-rr bond feeds into a single higher capacity network channel (e.g., multiple 100Mb/sec ethernets feeding a single gigabit ethernet via an etherchannel capable switch). In this configuration, traffic sent from the multiple 100Mb devices to a destination connected to the gigabit device will not see packets out of order. However, traffic sent from the gigabit device to the multiple 100Mb devices may or may not see traffic out of order, depending upon the balance policy of the switch. Many switches do not support any modes that stripe traffic (instead choosing a port based upon IP or MAC level addresses); for those devices, traffic flowing from the gigabit device to the many 100Mb devices will only utilize one interface.
Ahora cambié ese parámetro en ambos servidores conectados en todas las líneas (4) de 3 a 127.
Después de volver a vincularme, obtengo unos 100 MB / s, pero aún no más.
Alguna idea de por qué?
Actualización: Detalles de hardware de lspci -v
:
24:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at dfe80000 (32-bit, non-prefetchable) [size=128K]
Memory at dfea0000 (32-bit, non-prefetchable) [size=128K]
I/O ports at dcc0 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
Capabilities: [e0] Express Endpoint, MSI 00
Kernel driver in use: e1000
Kernel modules: e1000
Actualizar resultados finales:
8589934592 bytes (8,6 GB) copiados, 35.8489 segundos, 240 MB / s
Cambié muchas opciones de tcp / ip y de controlador de bajo nivel. Esto incluye la ampliación de los buffers de red. Esta es la razón por la que dd
ahora muestra números superiores a 200 MB / s: dd termina mientras todavía hay salida en espera de ser transferida (en buffers de envío).
Actualización 05/08/2011: configuración que se cambió para lograr el objetivo ( /etc/sysctl.conf ):
# See http://www-didc.lbl.gov/TCP-tuning/linux.html
# raise TCP max buffer size to 16 MB. default: 131071
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# raise autotuninmg TCP buffer limits
# min, default and max number of bytes to use
# Defaults:
#net.ipv4.tcp_rmem = 4096 87380 174760
#net.ipv4.tcp_wmem = 4096 16384 131072
# Tuning:
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Default: Backlog 300
net.core.netdev_max_backlog = 2500
#
# Oracle-DB settings:
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
kernel.shmmax = 2147659776
kernel.sem = 1250 256000 100 1024
net.core.rmem_default = 262144
net.core.wmem_default = 262144
#
# Tuning for network-bonding according to bonding.txt:
net.ipv4.tcp_reordering=127
Configuraciones especiales para el dispositivo de enlace (SLES: / etc / sysconfig / network / ifcfg-bond0 ):
MTU='9216'
LINK_OPTIONS='txqueuelen 10000'
Tenga en cuenta que establecer la mayor MTU posible fue la clave de la solución.
Ajuste de las memorias intermedias rx / tx de las tarjetas de red involucradas:
/usr/sbin/ethtool -G eth2 rx 2048 tx 2048
/usr/sbin/ethtool -G eth4 rx 2048 tx 2048
nuttcp
. Pruebe conexiones individuales o múltiples conexiones fácilmente.
/proc/net/bonding/bond0
para verificar que realmente se está configurando en balance-rr ? ¿Vio la nota n que la documentación que pegó sobre un enlace de 4 interfaces solo le proporciona un rendimiento de 2.3 interfaces? Teniendo en cuenta esa nota, parece muy poco probable que se acerque a los 2000mb / s que desea.