LINUX.ORG.RU
Форум — Admin  

Откуда ошибки на eth0

 


0

2

При возрастании трафика (> 200mbps) на интерфейсе растут ошибки. Что не так? надо сказать, что машина довольна слабая... Raspberry Pi (4 core), но все же, стоит 1GPBS в ней, значит должна теоретически такой трафик проглатывать? 

RX packets 793084540  bytes 512344690042 (512.3 GB)
RX errors 117445  dropped 117445  overruns 0  frame 1
TX packets 1256437452  bytes 1675880930706 (1.6 TB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

★★★★
← Роутинг в KVM/QEMU
Стена огня не пропускает →

Обработчик в ядре не успевает вычитывать приходящие пакеты. Копни в сторону Receive Packet Steering. И в целом стоит осознать, что bandwidth и pps это две разные величины

cobold ★★★★★
()

стоит 1GPBS в ней, значит должна теоретически такой трафик проглатывать?

Безотносительно конкретной машины, но эта фраза - эпическая наивность :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte 
NIC statistics:
     rx_packets: 889460896
     tx_packets: 1454760479
     rx_bytes: 553768379525
     tx_bytes: 1952654996302
     rx_errors: 172705
     tx_errors: 0
     rx_dropped: 0
     tx_dropped: 0
     multicast: 44644
     rx_64_octets: 343934014
     rx_65_127_oct: 194010140
     rx_128_255_oct: 1730188
     rx_256_511_oct: 3099079
     rx_512_1023_oct: 6076952
     rx_1024_1518_oct: 341039354
     rx_vlan_1519_1522_oct: 0
     rx_1522_2047_oct: 0
     rx_2048_4095_oct: 0
     rx_4096_9216_oct: 0
     rx_pkts: 889889727
     rx_bytes: 3408019510
     rx_multicast: 209777
     rx_broadcast: 34964296
     rx_fcs: 1
     rx_control: 0
     rx_pause: 0
     rx_unknown: 0
     rx_align: 0
     rx_outrange: 0
     rx_code: 0
     rx_carrier: 0
     rx_oversize: 0
     rx_jabber: 0
     rx_mtu_err: 0
     rx_good_pkts: 889889726
     rx_unicast: 854715653
     rx_ppp: 0
     rx_crc: 0
     tx_64_octets: 1275702
     tx_65_127_oct: 111116586
     tx_128_255_oct: 9403903
     tx_256_511_oct: 7733850
     tx_512_1023_oct: 15324000
     tx_1024_1518_oct: 1309906439
     tx_vlan_1519_1522_oct: 0
     tx_1522_2047_oct: 0
     tx_2048_4095_oct: 0
     tx_4096_9216_oct: 0
     tx_pkts: 1454760480
     tx_multicast: 398
     tx_broadcast: 8
     tx_pause: 0
     tx_control: 0
     tx_fcs_err: 0
     tx_oversize: 0
     tx_defer: 0
     tx_excess_defer: 0
     tx_single_col: 0
     tx_multi_col: 0
     tx_late_col: 0
     tx_excess_col: 0
     tx_frags: 0
     tx_total_col: 0
     tx_jabber: 0
     tx_bytes: 4271390970
     tx_good_pkts: 1454760480
     tx_unicast: 1454760074
     rx_runt_pkts: 0
     rx_runt_valid_fcs: 0
     rx_runt_inval_fcs_align: 0
     rx_runt_bytes: 0
     rbuf_ovflow_cnt: 0
     rbuf_err_cnt: 0
     mdf_err_cnt: 1560277
     alloc_rx_buff_failed: 0
     rx_dma_failed: 0
     tx_dma_failed: 0
     txq0_packets: 295476776
     txq0_bytes: 398230217023
     rxq0_bytes: 0
     rxq0_packets: 0
     rxq0_errors: 0
     rxq0_dropped: 0
     txq1_packets: 279058007
     txq1_bytes: 373218292367
     rxq1_bytes: 0
     rxq1_packets: 0
     rxq1_errors: 0
     rxq1_dropped: 0
     txq2_packets: 289010929
     txq2_bytes: 384842891074
     rxq2_bytes: 0
     rxq2_packets: 0
     rxq2_errors: 0
     rxq2_dropped: 0
     txq3_packets: 296956989
     txq3_bytes: 403019031736
     rxq3_bytes: 0
     rxq3_packets: 0
     rxq3_errors: 0
     rxq3_dropped: 0
     txq16_packets: 294257778
     txq16_bytes: 393344564102
     rxq16_bytes: 553768379525
     rxq16_packets: 889460896
     rxq16_errors: 172705
     rxq16_dropped: 0
gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Это 1.5х Cisco ASA5505 в режиме фильрации, выпущенной в 2005 и рассчитанной на 150Мбит трафика.

BOOBLIK ★★★★
()
Последнее исправление: BOOBLIK (всего исправлений: 1)
Ответ на: комментарий от gobot

172705 дропа на 889889726 пакетов - это немного, скорее наоборот. Очисти статистику и попробуй снова с постоянной нагрузкой помониторить.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Дропы то есть везде, но на этом сервере ещё и ошибки. Это нормально?

gobot ★★★★
() автор топика

Посмотри в /proc/interrupts, прерывания от сетевухи идут на все CPU? irqbalance мог «помочь» и скинуть их все на один CPU.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap 
           CPU0       CPU1       CPU2       CPU3
  1:          0          0          0          0     GICv2  25 Level     vgic
  3:  112871627  143175252  135608677  146796274     GICv2  30 Level     arch_timer
  4:          0          0          0          0     GICv2  27 Level     kvm guest vtimer
 11:   56842831          0          0          0     GICv2  65 Level     fe00b880.mailbox
 15:          0          0          0          0     GICv2 150 Level     fe204000.spi
 16:       1888          0          0          0     GICv2 125 Level     ttyS0
 17:          0          0          0          0     GICv2 149 Level     fe804000.i2c
 18:          1          0          0          0     GICv2 105 Level     fe980000.usb, fe980000.usb, dwc2_hsotg:usb3
 22:          0          0          0          0     GICv2 114 Level     DMA IRQ
 24:          0          0          0          0     GICv2 116 Level     DMA IRQ
 25:        342          0          0          0     GICv2 117 Level     DMA IRQ
 29:         46          0          0          0     GICv2  66 Level     VCHIQ doorbell
 30:   36396734          0          0          0     GICv2 158 Level     mmc1, mmc0
 31:          0          0          0          0     GICv2  48 Level     arm-pmu
 32:          0          0          0          0     GICv2  49 Level     arm-pmu
 33:          0          0          0          0     GICv2  50 Level     arm-pmu
 34:          0          0          0          0     GICv2  51 Level     arm-pmu
 36:  686453691          0          0          0     GICv2 189 Level     eth0
 37:  476205737          0          0          0     GICv2 190 Level     eth0
 43:          0          0          0          0     GICv2 175 Level     PCIe PME, aerdrv
 44:         39          0          0          0  BRCM STB PCIe MSI 524288 Edge      xhci_hcd
IPI0:  12553798   30876121   29899914   27650398       Rescheduling interrupts
IPI1:     76230      75191      74529      74356       Function call interrupts
IPI2:         0          0          0          0       CPU stop interrupts
IPI3:         0          0          0          0       CPU stop (for crash dump) interrupts
IPI4:         0          0          0          0       Timer broadcast interrupts
IPI5:  27415389   35733699   32285248   37022613       IRQ work interrupts
IPI6:         0          0          0          0       CPU wake-up interrupts



Это? Судя по всему да, на CPU0

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Нашел статью по теме https://tomcore.io/docs/articles/RaspberryPI/raspberry-pi-4b-network-performance/

Если кратко:

  • прерываний от сетевухи два, одно на приём, одно на передачу
  • контроллер прерываний GICv2 не умеет распределять одно прерывание на все CPU
  • можно разбросать эти два прерывания по разным CPU
  • можно поиграть с Packet Steering
  • можно в top посмотреть сколько CPU съедает softirq
iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Судя по этому

ethtool -l eth0
Channel parameters for eth0:
Cannot get device channel parameters
: Operation not supported


Сетевуха говно и ничего не умееет?


посмотреть сколько CPU съедает softirq

Посмотрел в zabbix: max 19% avg 6%, при максимальной загрузке проца на 86%

можно разбросать эти два прерывания по разным CPU

а как?

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 2)
Ответ на: комментарий от gobot

Посмотреть «ethtool -g eth0» и убедиться, что число буферов на приём максимально возможное.

Есть смысл посмотреть на то, сколько времени жрёт irq и softirq (mpstat -P ALL 3).
Если всё время сожрал irq, то нужно попробовать разделить прерывания на приём и передачу по разным ядрам
(echo 2 >/proc/irq/37/smp_aff).
Если softirq занимает существенное время, то раскидать его по всем ядрам за счет rps на приём (echo f >/sys/class/net/ethX/queues/rx-X/rps_cpus) и за счет xps на передачу (echo f >/sys/class/net/ethX/queues/rx-X/xps_cpus).
И это нужно сделать для всех очередей прёма/передачи.

vel ★★★★★
()
Ответ на: комментарий от vel

Посмотреть «ethtool -g eth0» и убедиться, что число буферов на приём максимально возможное

ethtool -g eth0»
Ring parameters for eth0:
Cannot get device ring settings: Operation not supported



Есть смысл посмотреть на то, сколько времени жрёт irq и softirq (mpstat -P ALL 3).

mpstat -P ALL 3
Command 'mpstat' not found, but can be installed with:

apt install sysstat

apt install mpstat
E: Unable to locate package mpstat




Если всё время сожрал irq, то нужно попробовать разделить прерывания на приём и передачу по разным ядрам

(echo 2 >/proc/irq/37/smp_aff).

cat /proc/irq/37/smp_aff
cat: /proc/irq/37/smp_aff: No such file or directory



Если softirq занимает существенное время

max 19% avg 6%. Это много?

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot 
mpstat -P ALL 3
Command 'mpstat' not found, but can be installed with:

apt install sysstat

apt install mpstat
E: Unable to locate package mpstat

Ты прикалываешься? Тебе же явно сказали, что mpstat находится в пакете sysstat. Выполни «apt install sysstat» и появится mpstat.

max 19% avg 6%. Это много?

Это вообще непонятно что. Вопрос был про irq и softirq под нагрузкой.

cat /proc/irq/37/smp_aff
cat: /proc/irq/37/smp_aff: No such file or directory

Если быть точнее, то «echo 2 >/proc/irq/37/smp_affinity»

vel ★★★★★
()
Ответ на: комментарий от vel

Это вообще непонятно что. Вопрос был про irq и softirq под нагрузкой

Это и есть softirq. mpstat тоже показывает это чисто 19% на ядре 0. 

13:00:55     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
13:00:58     all   20.05    0.00    7.85    0.43    0.00    5.97    0.00    0.00    0.00   65.70
13:00:58       0   14.84    0.00    6.71    0.00    0.00   19.79    0.00    0.00    0.00   58.66
13:00:58       1   18.31    0.00    8.14    0.00    0.00    3.73    0.00    0.00    0.00   69.83
13:00:58       2   22.90    0.00    5.39    1.01    0.00    0.34    0.00    0.00    0.00   70.37
13:00:58       3   23.91    0.00   11.11    0.67    0.00    0.67    0.00    0.00    0.00   63.64


Если быть точнее, то «echo 2 >/proc/irq/37/smp_affinity»

cat /proc/interrupts | grep eth
CPU0       CPU1       CPU2       CPU3
 36:  781171136          0          0          0     GICv2 189 Level     eth0
 37:  548751180     838027          0          0     GICv2 190 Level     eth0



Вроде появились циферки на CPU1

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Вроде появились циферки на CPU1

А что 2 и 3 простаивают? вот и утащи сетевуху туда. У тебя на 0 там дофига чего ещё, хотя сетевая, конечно, на порядок больше ест. И ещё там 4 ядра, или таки 2 с гипертредингом? Смысла уводить на второй тред того же ядра мало.

AS ★★★★★
()

В интернетах намеряли для RPi4 ~550Mbits/sec - для фулл-дуплекса и 1500-байтных пакетов

Думается, если пакеты будут мельче а траффик - неравномерный с берстами то и ~200Mbits/sec получить можно

alx777 ★★
()
Ответ на: комментарий от gobot

mpstat смотрел на загруженной сетевушке? Если да, то в данный момент у тебя нет проблем с перегрузкой CPU.

Проблема, это когда softirq + irq доходит до 80%

vel ★★★★★
()
Ответ на: комментарий от AS

На 1 и 3 CPU перекинуть 36 и 37 прерывание?

И ещё там 4 ядра, или таки 2 с гипертредингом

А хер его знает. Как узнать?

gobot ★★★★
() автор топика
Ответ на: комментарий от alx777

300 было максимум, но 250 держит вроде стабильно уже сутки пока

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

И ещё там 4 ядра, или таки 2 с гипертредингом

А хер его знает. Как узнать?

Читаем спецификацию cpu.

anc ★★★★★
()
Ответ на: комментарий от vel

Ну как загруженой, я не знаю ее предела ещё... вообще даже и на половину не нагрузилась, на четверть

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

На 1 и 3 CPU перекинуть 36 и 37 прерывание?

Главное на 0 не оставлять. Кстати, пишут, что ядра честные: Quad core Cortex-A72 (а бывает ли гипертрединг на arm - тоже вопрос)...

AS ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
← Роутинг в KVM/QEMU
Admin
Стена огня не пропускает →