У нас есть 2 сервера Red Hat, которые предназначены для тестирования скорости клиентов. Оба они используют оптоволоконные соединения 10 Гбит / с и используют каналы 10 Гбит / с. Все сетевое оборудование между этими серверами полностью поддерживает скорость 10 Гбит / с. При использовании Iperf или Iperf3 лучшее, что я могу получить, составляет около 6,67 Гбит / с. При этом один сервер находится в производстве (клиенты обращаются к нему), а другой сервер находится в сети, но не используется. (мы используем его для тестирования банкомата), я должен упомянуть, что скорость 6,67 Гбит / с также является одним из способов. Мы будем называть эти серверы A и B.
Когда сервер A действует как сервер iperf, мы получаем скорость 6,67 Гбит / с. Когда сервер A действует как клиент для сервера B, он может передавать только около 20 Мбит / с.
Что я наделал:
Пока что единственное, что я сделал, это увеличил буферы TX / RX на обоих серверах до максимума. Один был установлен на 512, другой - на 453. (только RX, TX уже был максимален), так что это похоже на оба после обновления:
Server A:
Ring parameters for em1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Server B:
Ring parameters for p1p1:
Pre-set maximums:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
Current hardware settings:
RX: 4078
RX Mini: 0
RX Jumbo: 0
TX: 4078
NICS выглядят так:
Server A:
ixgbe 0000:01:00.0: em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Serer B:
bnx2x 0000:05:00.0: p1p1: NIC Link is Up, 10000 Mbps full duplex, Flow control: ON - receive & transmit
Server A ethtool stats:
rx_errors: 0
tx_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_csum_offload_errors: 123049
Server B ethtool stats:
[0]: rx_phy_ip_err_discards: 0
[0]: rx_csum_offload_errors: 0
[1]: rx_phy_ip_err_discards: 0
[1]: rx_csum_offload_errors: 0
[2]: rx_phy_ip_err_discards: 0
[2]: rx_csum_offload_errors: 0
[3]: rx_phy_ip_err_discards: 0
[3]: rx_csum_offload_errors: 0
[4]: rx_phy_ip_err_discards: 0
[4]: rx_csum_offload_errors: 0
[5]: rx_phy_ip_err_discards: 0
[5]: rx_csum_offload_errors: 0
[6]: rx_phy_ip_err_discards: 0
[6]: rx_csum_offload_errors: 0
[7]: rx_phy_ip_err_discards: 0
[7]: rx_csum_offload_errors: 0
rx_error_bytes: 0
rx_crc_errors: 0
rx_align_errors: 0
rx_phy_ip_err_discards: 0
rx_csum_offload_errors: 0
tx_error_bytes: 0
tx_mac_errors: 0
tx_carrier_errors: 0
tx_deferred: 0
recoverable_errors: 0
unrecoverable_errors: 0
Возможная проблема: на сервере A множество ошибок rx_csum_offload_errors. Сервер A находится в производстве, и я не могу не думать, что прерывания процессора могут быть здесь основным фактором и причиной ошибок, которые я вижу.
cat / proc / interrupts с сервера A:
122: 54938283 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1- TxRx-0
123: 51653771 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-1
124: 52277181 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-2
125: 51823314 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-3
126: 57975011 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-4
127: 52333500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-5
128: 51899210 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-6
129: 61106425 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-7
130: 51774758 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-8
131: 52476407 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-9
132: 53331215 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge em1-TxRx-10
133: 52135886 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Помогло бы отключение rx-checkumming, если это может быть проблема? Также я не вижу прерываний ЦП на сервере, который не находится в производстве, что имеет смысл, поскольку его сетевой карте не требуется процессорное время.
Server A:
ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-unneeded: off
tx-checksum-ip-generic: off
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: on [fixed]
tx-checksum-sctp: on [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
loopback: off [fixed]
Помимо использования jumbo-кадров, что невозможно, потому что наше сетевое оборудование их не поддерживает, что еще я могу сделать или проверить, чтобы обеспечить оптимальную производительность TCP для моей сети 10 ГБ? 6,67 Гбит / с не который плохо, я предполагаю, учитывая, что один из серверов находится в производстве, и моя гипотеза о прерываниях процессора, которые генерирует сетевая карта. Но скорость 20 Мбит / с в обратном направлении по каналу 10 Гбит просто неприемлема. Любая помощь будет принята с благодарностью.
Характеристики сервера A: x64 24v CPU 32GB RAM RHEL 6.7
Спецификации сервера B: x64 16v CPU 16GB ram RHEL 6.7
В Linux / Intel я бы использовал следующую методологию для анализа производительности:
Оборудование:
turbostat
cpufreq-info
atop
ethtool
Ядро:
/proc/net/softirq
[2] и /proc/interrupts
[3]perf top
iptables
netstat -s
, netstat -m
, /proc/net/*
В вашем случае ваша основная проблема - это распределение прерываний по ядрам, поэтому исправление этого будет вашим лучшим средством.
PS. Не забывайте, что в подобных тестах важную роль играют версии ядра и драйверов / прошивки.
PPS. Вероятно, вы захотите установить самую новую ixgbe
драйвер от Intel [4]. Не забудьте там прочитать README и изучить каталог скриптов. В нем есть много советов, связанных с производительностью.
[0] У Intel также есть отличные документы о масштабировании производительности сети.
https://www.kernel.org/doc/Documentation/networking/scaling.txt
[1] Вы можете привязать свой процессор к определенному C-состоянию:
https://gist.github.com/SaveTheRbtz/f5e8d1ca7b55b6a7897b
[2] Вы можете проанализировать эти данные с помощью:
https://gist.github.com/SaveTheRbtz/172b2e2eb3cbd96b598d
[3] Вы можете установить сходство с:
https://gist.github.com/SaveTheRbtz/8875474
[4] https://sourceforge.net/projects/e1000/files/ixgbe%20stable/
У серверов одинаковые характеристики (марка и модель)? Вы вносили какие-либо изменения в sysctl.conf?
Вам следует включить irqbalance, потому что ваши прерывания происходят только на CPU0.
Если вы не используете настроенный профиль с EL6, вам следует выбрать тот, который близок к вашей рабочей нагрузке, в соответствии с расписанием. Вот.
Я бы попробовал отключить LRO (Large Receive Offload) ... Думаю, у вас есть один с включенным, а другой с выключенным.
Это зависит от сетевой карты / драйвера, но в целом, когда мы видим это в нашей среде, мы знаем, что пропустили один, и отключаем LRO.
Скорость 6 Гбит / с - это нормально, если вы запускаете только один экземпляр iperf, поскольку она ограничена одним ядром процессора. Два процесса одновременно должны дать ожидаемую скорость 10 Гбит / с.
Проблема с 20 Мбит / с в одном направлении выглядит как проблема несовместимости драйверов / прошивки / оборудования.
Я предлагаю вам попробовать следующие шаги по устранению неполадок:
Ваши сетевые карты имеют два порта, поэтому сначала попробуйте проверить скорость обратной петли на обоих сетевых адаптерах. Это может помочь вам локализовать проблему: на сервере A или на сервере B. 2. Замените патч-корды. 3. Попробуйте новые драйверы. 4. Обновите прошивку. 5. Смените сетевые карты)