Перейти к содержимому
Калькуляторы
21 час назад, John_obn сказал:

Из-за NAT без conntrack никак.

так NAT будет на других машинах. которым не надо делать лукап по фуллвью. и которых можно поставить больше, чем кол-во аплинков (нагрузка от ната растет совсем не пропорционально кол-ву нат сессий/pps - т.е. два однопроцессорных тазика промолотят больше, чем один равнозначный двухпроцессорный).

 

21 час назад, John_obn сказал:

Что скажете по поводу AMD Epyc?

задержки памяти/межчиповых линков сравнимы с интелом, кеши вроде даже жирнее, так что думаю работать будут не хуже равноядерного интела. впрочем, я бы ставил 2 машины без NUMA вместо одной с NUMA... по потреблению - +- то же, по производительности будет лучше, по отказоустойчивости - тоже лучше если настроить правильно резерв.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 10.01.2021 в 16:42, pppoetest сказал:

Мы переехали на https://github.com/andrsharaev/xt_NAT, нагрузка упала до 10% на ядро в ЧНН(это с учётом нарезки скоростей) и трафика 6,5Гиг.

Чтобы понимать масштабы, упала до 10% со скольки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

9 часов назад, pppoetest сказал:

Перевел один из бордеров на xt_NAT, сегодня посмотрю загрузку в ЧНН. Единственное, не смог заставить работать экспорт netflow нормально. Понимаю, что ругается AppArmor на то, что модуль xt_NAT шлет по сети данные, но что нужно для этого поменять в коде xt_NAT.c , моих знаний не хватает. Такое каждую секунду в syslog льется. Пришлось оставить модуль xt_nat без опции nf_dest

Jan 12 05:00:23 heavennat kernel: [1818102.038728] WARNING: CPU: 17 PID: 0 at /build/linux-thjo1k/linux-4.4.0/security/apparmor/net.c:327 aa_sock_msg_perm+0xaf/0x150()
Jan 12 05:00:23 heavennat kernel: [1818102.038729] AppArmor WARN aa_sock_msg_perm: ((((preempt_count() & ((((1UL << (4))-1) << ((0 + 8) + 8)) | (((1UL << (8))-1) << (0 + 8)) | (((1UL <<
 (1))-1) << (((0 + 8) + 8) + 4))))))): 
Jan 12 05:00:23 heavennat kernel: [1818102.038730] Modules linked in: xt_NAT(OE) ip6table_filter xt_set ip6table_raw ip6table_mangle ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat
_ipv6 ip6_tables ip_set_hash_ip ip_set_hash_net ip_set xt_multiport iptable_filter xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_mangle xt_CT iptable_raw intel
_rapl x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_ssif input_leds kvm mei_me lpc_ich mei sb_edac shpchp edac_core ioatdma irqbypass ipmi_si ipmi_msghandler acpi_power_meter 8250
_fintek mac_hid acpi_pad tcp_htcp ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_netlink nfnetlink ipt_NETFLO
W(OE) nf_conntrack_ftp nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat nf_conntrack ip_tables x_tables 8021q garp stp mrp llc autofs4 btrfs raid10 raid456 a
sync_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ast ghash_clmulni_intel ttm aesni_intel drm_k
ms_helper aes_x86_64 lrw syscopyarea gf128mul sysfillrect glue_helper sysimgblt ablk_helper hid_generic mxm_wmi fb_sys_fops i40e(OE) igb vxlan cryptd ip6_udp_tunnel dca udp_tunnel usbhi
d drm ptp megaraid_sas hid i2c_algo_bit pps_core fjes wmi
Jan 12 05:00:23 heavennat kernel: [1818102.038775] CPU: 17 PID: 0 Comm: swapper/17 Tainted: G        W  OE   4.4.0-197-generic #229-Ubuntu
Jan 12 05:00:23 heavennat kernel: [1818102.038776] Hardware name: Supermicro SYS-6028R-TR/X10DRi, BIOS 2.1 09/13/2016
Jan 12 05:00:23 heavennat kernel: [1818102.038778]  0000000000000286 5415124cb55a2797 ffff88105f2c36e8 ffffffff8140f12b
Jan 12 05:00:23 heavennat kernel: [1818102.038780]  ffff88105f2c3730 ffffffff81d03048 ffff88105f2c3720 ffffffff810864b2
Jan 12 05:00:23 heavennat kernel: [1818102.038782]  ffff881053dde080 ffff88105f2c3868 ffffffff81d76233 0000000000000002
Jan 12 05:00:23 heavennat kernel: [1818102.038783] Call Trace:
Jan 12 05:00:23 heavennat kernel: [1818102.038784]  <IRQ>  [<ffffffff8140f12b>] dump_stack+0x6d/0x92
Jan 12 05:00:23 heavennat kernel: [1818102.038789]  [<ffffffff810864b2>] warn_slowpath_common+0x82/0xc0
Jan 12 05:00:23 heavennat kernel: [1818102.038792]  [<ffffffff8108654c>] warn_slowpath_fmt+0x5c/0x80
Jan 12 05:00:23 heavennat kernel: [1818102.038797]  [<ffffffffc03a02d2>] ? i40e_lan_xmit_frame+0x482/0x14d0 [i40e]
Jan 12 05:00:23 heavennat kernel: [1818102.038799]  [<ffffffff813b4dcf>] aa_sock_msg_perm+0xaf/0x150
Jan 12 05:00:23 heavennat kernel: [1818102.038802]  [<ffffffff813a6683>] apparmor_socket_sendmsg+0x23/0x30
Jan 12 05:00:23 heavennat kernel: [1818102.038804]  [<ffffffff8135f289>] security_socket_sendmsg+0x49/0x70
Jan 12 05:00:23 heavennat kernel: [1818102.038805]  [<ffffffff8173abba>] sock_sendmsg+0x1a/0x50
Jan 12 05:00:23 heavennat kernel: [1818102.038807]  [<ffffffff8173ad0b>] kernel_sendmsg+0x2b/0x30
Jan 12 05:00:23 heavennat kernel: [1818102.038809]  [<ffffffffc06944d5>] netflow_sendmsg.constprop.5+0x95/0x200 [xt_NAT]
Jan 12 05:00:23 heavennat kernel: [1818102.038812]  [<ffffffffc06946df>] netflow_export_pdu_v5+0x9f/0xd0 [xt_NAT]
Jan 12 05:00:23 heavennat kernel: [1818102.038814]  [<ffffffffc0694855>] netflow_export_flow_v5+0x145/0x150 [xt_NAT]
Jan 12 05:00:23 heavennat kernel: [1818102.038816]  [<ffffffffc0695858>] create_nat_session+0x4a8/0x5f0 [xt_NAT]
Jan 12 05:00:23 heavennat kernel: [1818102.038818]  [<ffffffffc06964ff>] nat_tg+0xb5f/0x13bd [xt_NAT]
Jan 12 05:00:23 heavennat kernel: [1818102.038820]  [<ffffffffc022cd81>] ipt_do_table+0x301/0x730 [ip_tables]
Jan 12 05:00:23 heavennat kernel: [1818102.038823]  [<ffffffffc04ec0c7>] iptable_filter_hook+0x27/0x56 [iptable_filter]
Jan 12 05:00:23 heavennat kernel: [1818102.038825]  [<ffffffff8178f918>] nf_iterate+0x68/0x80
Jan 12 05:00:23 heavennat kernel: [1818102.038827]  [<ffffffff8178f9a3>] nf_hook_slow+0x73/0xd0
Jan 12 05:00:23 heavennat kernel: [1818102.038829]  [<ffffffff8179920d>] ip_forward+0x47d/0x4a0
Jan 12 05:00:23 heavennat kernel: [1818102.038831]  [<ffffffff81798d20>] ? ip4_key_hashfn+0xb0/0xb0
Jan 12 05:00:23 heavennat kernel: [1818102.038832]  [<ffffffff81796d98>] ip_rcv_finish+0x98/0x330
Jan 12 05:00:23 heavennat kernel: [1818102.038834]  [<ffffffff817976e8>] ip_rcv+0x298/0x350
Jan 12 05:00:23 heavennat kernel: [1818102.038836]  [<ffffffff811fb902>] ? ___slab_alloc+0x232/0x4b0
Jan 12 05:00:23 heavennat kernel: [1818102.038838]  [<ffffffff81796d00>] ? inet_del_offload+0x40/0x40
Jan 12 05:00:23 heavennat kernel: [1818102.038840]  [<ffffffff81757cfc>] __netif_receive_skb_core+0x74c/0xab0
Jan 12 05:00:23 heavennat kernel: [1818102.038841]  [<ffffffff81748dca>] ? __build_skb+0x2a/0xe0
Jan 12 05:00:23 heavennat kernel: [1818102.038843]  [<ffffffff81758078>] __netif_receive_skb+0x18/0x60
Jan 12 05:00:23 heavennat kernel: [1818102.038845]  [<ffffffff817580f2>] netif_receive_skb_internal+0x32/0xa0
Jan 12 05:00:23 heavennat kernel: [1818102.038846]  [<ffffffff81758bd6>] napi_gro_receive+0xc6/0xf0
Jan 12 05:00:23 heavennat kernel: [1818102.038851]  [<ffffffffc039f33d>] i40e_napi_poll+0x83d/0x1240 [i40e]
Jan 12 05:00:23 heavennat kernel: [1818102.038853]  [<ffffffff817585f5>] net_rx_action+0x225/0x360
Jan 12 05:00:23 heavennat kernel: [1818102.038854]  [<ffffffff8108b509>] __do_softirq+0x109/0x2b0
Jan 12 05:00:23 heavennat kernel: [1818102.038856]  [<ffffffff8108b825>] irq_exit+0xa5/0xb0
Jan 12 05:00:23 heavennat kernel: [1818102.038858]  [<ffffffff8186d46c>] do_IRQ+0x5c/0xf0
Jan 12 05:00:23 heavennat kernel: [1818102.038860]  [<ffffffff8186a894>] common_interrupt+0xd4/0xd4
Jan 12 05:00:23 heavennat kernel: [1818102.038860]  <EOI>  [<ffffffff816f5a20>] ? poll_idle+0x40/0x80
Jan 12 05:00:23 heavennat kernel: [1818102.038864]  [<ffffffff816f5326>] cpuidle_enter_state+0xf6/0x2d0
Jan 12 05:00:23 heavennat kernel: [1818102.038865]  [<ffffffff816f5537>] cpuidle_enter+0x17/0x20
Jan 12 05:00:23 heavennat kernel: [1818102.038867]  [<ffffffff810cc0e2>] call_cpuidle+0x32/0x60
Jan 12 05:00:23 heavennat kernel: [1818102.038868]  [<ffffffff816f5519>] ? cpuidle_select+0x19/0x20
Jan 12 05:00:23 heavennat kernel: [1818102.038870]  [<ffffffff810cc3ab>] cpu_startup_entry+0x29b/0x360
Jan 12 05:00:23 heavennat kernel: [1818102.038872]  [<ffffffff81053f47>] start_secondary+0x177/0x1b0
Jan 12 05:00:23 heavennat kernel: [1818102.038874] ---[ end trace c333a897ac86ea9d ]---
Jan 12 05:00:23 heavennat kernel: [1818102.038874] ------------[ cut here ]------------

 

 

17 часов назад, NiTr0 сказал:

так NAT будет на других машинах. которым не надо делать лукап по фуллвью. и которых можно поставить больше, чем кол-во аплинков (нагрузка от ната растет совсем не пропорционально кол-ву нат сессий/pps - т.е. два однопроцессорных тазика промолотят больше, чем один равнозначный двухпроцессорный).

 

задержки памяти/межчиповых линков сравнимы с интелом, кеши вроде даже жирнее, так что думаю работать будут не хуже равноядерного интела. впрочем, я бы ставил 2 машины без NUMA вместо одной с NUMA... по потреблению - +- то же, по производительности будет лучше, по отказоустойчивости - тоже лучше если настроить правильно резерв.

Почему два однопроцессорных тазика больше промолотят, если при наличии двух процессоров и двух сетевых картах, каждая из которых будет установлена в pcie, которые идут каждый на свой проц?

 

У AMD получается цена per core интереснее, по крайней мере если сравнивать с аналогичными современными Xeon. Соответственно, в те же деньги можно выбрать AMD с бОльшим кол-вом ядер и частотой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 минут назад, John_obn сказал:

Понимаю, что ругается AppArmor на то, что модуль xt_NAT шлет по сети данные, но что нужно для этого поменять в коде xt_NAT.c , моих знаний не хватает.

Код править не надо, кмк, достаточно сконфигурировать apparmor.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, pppoetest сказал:

Код править не надо, кмк, достаточно сконфигурировать apparmor.

 

Apparmor конфигурил для его реакции на бинари. Но как сконфигурировать профиль для модуля, я что-то не нашёл. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну а что ты намеревался править в коде? Там просто отправка udp пакетов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, John_obn сказал:

Почему два однопроцессорных тазика больше промолотят, если при наличии двух процессоров и двух сетевых картах, каждая из которых будет установлена в pcie, которые идут каждый на свой проц?

1) нет затрат на доступ к памяти соседней ноды (что особенно печально если коннтрак не влазит в кеш целиком)

2) меньше трансляций на каждом тазике (лукап по коннтраку быстрее)

3) меньше ппс на каждом тазике

4) нет затрат на пересылку данных между процами на соседнюю сетевуху

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, pppoetest сказал:

Ну а что ты намеревался править в коде? Там просто отправка udp пакетов.

Я на C толком не писал, но ругань в логах я понимаю, будто модуль xt_NAT отправляет netflow в сеть как то несекурно или еще как то, как не нравится AppArmor'у.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

12 hours ago, pppoetest said:

достаточно сконфигурировать apparmor.

Правильно сконфигурированный apparmor - это выключенный apparmor.

Иначе это не администрирование сервера, а нечто подобное:

scale_1200

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, John_obn сказал:

модуль xt_NAT отправляет netflow в сеть как то несекурно или еще как то, как не нравится AppArmor'у.

Как можно отправить "несекурно" юдп пакетег?

3 часа назад, John_obn сказал:

Я на C толком не писал

Аналогично, но там не слишком заумно

 

8 минут назад, rm_ сказал:

Правильно сконфигурированный apparmor - это выключенный apparmor. 

Согласен, имхо, сабж не нужен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, rm_ сказал:

Правильно сконфигурированный apparmor - это выключенный apparmor.

Иначе это не администрирование сервера, а нечто подобное:

scale_1200

Если честно, это второй раз, когда приходится иметь дело с AppArmor. До этого на наших серверах приложений или роутеров ни разу AppArmor не мешал. Поэтому, от случая к случаю.

 

3 часа назад, pppoetest сказал:

Как можно отправить "несекурно" юдп пакетег?

Аналогично, но там не слишком заумно

 

Согласен, имхо, сабж не нужен.

Не знаю, в чем несекурность, но на той же машине работал ipt_NETFLOW и таких проблем не было. А ведь делают они одно и то же, отправляют netflow на коллектор. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Судя по графикам, переход на xt_NAT не помог никак. Либо нагрузка от NAT не на столько значительна относительно лукапа таблицы маршрутизации и приема передачи пакетов на сетевых картах, либо все вместе дают такую картину и упираются в пределы чего то.

Скажите, пожалуйста, свое мнение: ведь idle у ядер не становится меньше 18-19%, значит запас по производительности процессора есть, верно? Допускаю, что в моменты берстов idle может и в 0 уходить.

Почему все таки возникают rx_dropped в таком количестве? Может какой то тип трафика дропается, jumbo там не летают - уже проверял. Rx_dropped - судя по докам, связано с выгребанием пакетов из очередей сетевой карты. Может не успевают очереди опустошиться...но почему? ethtool -c rx-usecs tx-usecs уже давно выставлены в 0, то есть прерывания генерятся как только так сразу.

Если упирается в производительность сервера, хотелось бы понять в какой именно части. Смена conntrack на xt_NAT наводит на мысль о том, что вынос NAT на отдельный тазик может не помочь. Понимаю, что не попробуешь, не поймешь, просто дорогой тест выйдет, если причина в чем то другом.

2021-01-12_22-28-17.thumb.png.6229e91d95890cc9e0168324eb41783e.png2021-01-12_22-21-45.thumb.png.c1066bbc32c88cfaf26402543fd6e392.png2021-01-12_22-14-17.thumb.png.00b7040ad0135708bfdc9b63376eb531.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@John_obn 

_raw_spin_lock - 7%

- Предположу, что 25% бездействия в том числе из-за этого. 7% времени ваши процессоры ожидают синхронизации потоков.

 

ethtool -c rx-usecs tx-usecs уже давно выставлены в 0, то есть прерывания генерятся как только так сразу.

- Это тоже далеко не плюс, с точки зрения нагрузки. Прерывания один из худших вариантов чтения из буферов :-(. Фактически, при каждом  прерывании должно происходить переключение потоков, а это очень и очень накладно, особенно если процессор в этот момент находится не в потоке на уровне ядра. Идеально, что-бы прерываний было минимум, не случайно есть реализации драйверов сетевух с минимизацией прерываний через SoftIRQ.

 

На вопрос, почему тазик с одним ядром молотит больше, чем тазик с 32 ядрами ответ прост.

Кто быстрее прочтет одну страницу книжки? Один человек, или 32 читая кусочки текста по очереди? Очевидно, что один, т.к. пока 32 будут передавать друг другу книгу и указывать откуда читать, он ее уже давно дочитает.

 

Также и с многоядерной обработкой. Если Ваш пакет данных передается между процессами для обработки на разных ядрах, то каждый раз им надо обновить кэши страниц памяти, а это одна из самых "дорогих" операций на современных процессорах. Такие же неприятности возникают, если часть обработки пакета происходит не на уровне ядра, а на уровне приложения, как это было в старых версиях реализации PPTP.

 

З.Ы. Вот тут почитайте (первое, что нашел по теме):

http://unix-way.ru/index.php/poleznyashki-linux/119-uzkie-mesta-setevoj-podsistemy-linux-tyuning-seti-v-linux-nastrojka-proizvoditelnosti-seti-v-modeli-napi-i-s-preryvaniyami

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, John_obn сказал:

Судя по графикам, переход на xt_NAT не помог никак

коннтрак отключали? он для xt_NAT не нужен.

 

3 часа назад, John_obn сказал:

Может не успевают очереди опустошиться...но почему?

какой размер очередей? на максимум выкручен надеюсь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

9 часов назад, NiTr0 сказал:

коннтрак отключали? он для xt_NAT не нужен.

 

Весь транзитный трафик серых адресов уходил на xt_NAT, это подтверждалось мониторингом кол-ва записей conntrack, а также делал флаш таблицы conntrack. Единственное, потом появлялось порядка 30 записей, относящихся к локальному трафику бордера (bgp сессии в основном). Их не стал убирать из conntrack, подумав, что они не дают никакой нагрузки.

9 часов назад, NiTr0 сказал:

  какой размер очередей? на максимум выкручен надеюсь?

Да, иначе дропы были больше, это уже давно выставленный параметр. По мере роста трафика увеличивался до максимума.

$ ethtool -g ens6
Ring parameters for ens6:
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

 

 

11 часов назад, sdy_moscow сказал:

@John_obn 

_raw_spin_lock - 7%

- Предположу, что 25% бездействия в том числе из-за этого. 7% времени ваши процессоры ожидают синхронизации потоков.

Хмм..из-за 2 процессоров? Как бороться, кроме перехода на 1 процессор?

11 часов назад, sdy_moscow сказал:

ethtool -c rx-usecs tx-usecs уже давно выставлены в 0, то есть прерывания генерятся как только так сразу.

- Это тоже далеко не плюс, с точки зрения нагрузки. Прерывания один из худших вариантов чтения из буферов :-(. Фактически, при каждом  прерывании должно происходить переключение потоков, а это очень и очень накладно, особенно если процессор в этот момент находится не в потоке на уровне ядра. Идеально, что-бы прерываний было минимум, не случайно есть реализации драйверов сетевух с минимизацией прерываний через SoftIRQ.

Год или два назад значение было больше нуля, уже не помню сколько, и тогда начинали расти дропы, после этого довел до нуля и дропы прекратились. На сколько я понимаю, современные драйверы от intel и работают через софтовые прерывания? Или я ошибаюсь?

11 часов назад, sdy_moscow сказал:

За статью огромная благодарность, ранее на нее не натыкался, но много доков по прерываниям и работе сети изучил. Порядка 95% этого уже знал, но из этой статьи почерпнул и новое, проверю в ЧНН некоторые параметры, в частности softnet_stat. В выводе третий столбец не пустой, но и инкремент не сильно большой. Буду смотреть в момент, когда дропы будут расти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, John_obn сказал:

Хмм..из-за 2 процессоров? Как бороться, кроме перехода на 1 процессор?

Эх... если бы знать! По хорошему надо прибивать обработку пакета от момента получения до момента отправки к одному ядру (или как минимум процессору). Я так глубоко ядро линукс не копал, ограничивался smp_affinity. Ищите.

 

3 часа назад, John_obn сказал:

На сколько я понимаю, современные драйверы от intel и работают через софтовые прерывания? Или я ошибаюсь?

Как правило - Да, но что в итоге у Вас - Х.З. В свое время, например, я наблюдал, как на одних и тех же дистрибутивах, но на разных процессорах и матерях обработка и "прибитие" прерываний к ядрам (smp_affinity) работали по разному. На одних всё было ОК, на других не работало хоть убейся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 11.12.2020 в 13:26, taf_321 сказал:

Все на лету меняется. Пример с 4-ядерным процессором.

 


#!/bin/sh

P=`find /proc/irq -name 'eno1-TxRx-0' -print | sed 's@/eno1-TxRx-0@@'`                                                                                                 
echo "1" > ${P}/smp_affinity                                                                                                                                           
P=`find /proc/irq -name 'eno1-TxRx-1' -print | sed 's@/eno1-TxRx-1@@'`                                                                                                 
echo "2" > ${P}/smp_affinity                                                                                                                                           
P=`find /proc/irq -name 'eno1-TxRx-2' -print | sed 's@/eno1-TxRx-2@@'`                                                                                                 
echo "4" > ${P}/smp_affinity                                                                                                                                           
P=`find /proc/irq -name 'eno1-TxRx-3' -print | sed 's@/eno1-TxRx-3@@'`                                                                                                 
echo "8" > ${P}/smp_affinity                                                                                                                                          

 

А вот для изменения количества очередей да, ребут (или хотябы выгрузка модуля сетевухи) нужен.

Кол-во очередей можно без ребута. 

 

ethtool -L eth2 combined 6

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 13.01.2021 в 02:22, NiTr0 сказал:

коннтрак отключали? он для xt_NAT не нужен.

 

какой размер очередей? на максимум выкручен надеюсь?

Дело оказалось не в NAT. Я переводил временно NAT на BRASы, idle повышался на 10%, но дропы на ens6 никуда не уходили :(

Сегодня еще раз перенесу NAT на BRASы, но уже будем спрашивать у абонентов, стало ли лучше по ощущениям. Потому что в прошлый раз пришлось через какое то время вернуть NAT на бордеры, т.к. по магистралям трафик неоптимально раскидался и в итоге один из междугородних каналов загрузился почти в полку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может что подскажут

/proc/sys/net/core/netdev_budget

/proc/net/softnet_stat

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, dryukov сказал:

Может что подскажут

/proc/sys/net/core/netdev_budget

/proc/net/softnet_stat

 

После статьи, ссылку на которую прислал sdy_moscow, я в первую очередь на них обратил внимание, потому что это единственное, что я не крутил. netdev_budget каким бы не выставлял, а 3-я колонка в softnet_stat все равно почуть увеличивается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

В 18.01.2021 в 14:39, John_obn сказал:

Я переводил временно NAT на BRASы, idle повышался на 10%, но дропы на ens6 никуда не уходили :(

а как вы считаете эти самые дропы?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, boco сказал:

 

а как вы считаете эти самые дропы?

Счетчик rx_dropped. Его можно увидеть через ethtool -S

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 часа назад, John_obn сказал:

Счетчик rx_dropped. Его можно увидеть через ethtool -S

на эти "дропы" можно смело забить. это не потери, это отброшенные левые пакеты. https://www.suse.com/support/kb/doc/?id=000017478

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

может быть даже flow control пакеты которые не поддерживаются картой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.