[Azamat]

Всем доброго дня.

Плз подскажите, кто знает.

 

Есть сервер под Линукс, функция - НАТ, трафика порядка 6-7 гиг.

Обратил внимание, что на нем теряются по 2-4 пакета из 500. 

Со стороны "серой" сети отправляю дозированно по 500 icmp до майл.ру, вижу что на входящий интерфейс со стороны "серой" сети все 500 пакетов приходят, но с соотв. "белого" адреса в сторону майл.ру уходят на 2-4 пакета меньше. Куда они могут деться-то между двумя интерфейсами на сервере ? Как именно продиагностировать ?

Есть аналогичный сервер, сделанный клонированием с целевого - на том же трафике потерь нету.

 

Какая доп. инфа нужна, чтобы более полно раскрыть тему ?

[nuclearcat]

ethtool -S

mpstat -P ALL 1 на 2-3 секунды статистики (а вообще надо понаблюдать - нет ли всплесков)

ifconfig

 

 

[Azamat]

ethtool даёт простыню, оттуда надо какой то определенный раздел ?

ifconfig - часть со статистикой по интерфейсам ? вряд ли нужны сами ип адреса ?

[default_vlan]

Проверять потери надо не до mail.ru, а до шлюза провайдера. И вот если до шлюза провайдера будут потери, тогда и нужно вдаваться в полемику. 

Почему? Потому что:

1. я сомневаюсь, что вы представитель группы системных инженеров mail.ru и пишете сюда вместо того, чтобы воспользоваться собственным сервисом ответов;

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

 

По этой причине следует запустить 2 ping'а - первый на шлюз провайдера, а второй на mail.ru и сделать это с непосредственно сервера доступа. Далее решим как быть.

[Azamat]

На всякий случай уточню - потерю дает именно НАТ сервер, на входящий интерфейс с "серой" стороны  приходят все 500 пакетов, а в сторону внешки (в данном случае, майл.ру) уходят с "белого" адреса НАТ сервера на 2-4 пакета меньше. К вышестоящим претензиев не имеем.

[Azamat]

Просмотр существующей темы про Линукс НАТ натолкнул проверить:
 

root@HOME-NAT:~# ethtool -S eth1|grep sum
     rx_csum_offload_errors: 37117809
root@HOME-NAT:~# ethtool -S eth1|grep sum
     rx_csum_offload_errors: 37120332

 

Там же было написано, что рост ошибок может быть связан с патчкордом. Заменю-проверю.

[rm_]

Или оффлоады попробовать выключить. ethtool -K eth1 rx off tx off

А сетевые карты какие, вообще?

[nuclearcat]

Выключать стоит только tso, да и даже он на потери обычно не влияет.

rx_csum_offload_errors надо смотреть соотносительно к общему количеству пробегающих пакетов

 

[Azamat]

не помогла замена патчкорда. Менять сервер ? может что то с оперативой за 3 года в аптайме ?

 

Сетевые DA520

 

ethtool -G eth1 rx 2048
ethtool -G eth2 rx 2048
ethtool -G eth1 tx 2048
ethtool -G eth2 tx 2048
ethtool -C eth2 rx-usecs 500
ethtool -C eth1 rx-usecs 500
ethtool -A eth1 rx off tx off
ethtool -A eth2 rx off tx off
ethtool -K eth1 ntuple off
ethtool -K eth2 ntuple off
ethtool -K eth1 gro off
ethtool -K eth2 gro off

 

 

Сейчас два раза по 500 пакетов прошло без потерь, а раз - в сервере застряло 6-7%. Мистика.

 

Изменено 23 октября, 2017 пользователем Azamat

[Azamat]

Уважаемые друзья, плз подскажите еще по одной теме:

в НАТ сервере проц на 8 честных ядер, но загружены 6, два последних полностью простаивают. Х/з почему :(

 

02:12:31 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
02:12:32 AM  all    0.00    0.00    0.00    0.00    0.00   30.35    0.00    0.00   69.65
02:12:32 AM    0    0.00    0.00    0.00    0.00    0.00   39.13    0.00    0.00   60.87
02:12:32 AM    1    0.00    0.00    0.00    0.00    0.00   39.36    0.00    0.00   60.64
02:12:32 AM    2    0.00    0.00    0.00    0.00    0.00   34.78    0.00    0.00   65.22
02:12:32 AM    3    0.00    0.00    0.00    0.00    0.00   43.40    0.00    0.00   56.60
02:12:32 AM    4    0.00    0.00    0.00    0.00    0.00   42.86    0.00    0.00   57.14
02:12:32 AM    5    0.00    0.00    0.00    0.00    0.00   42.06    0.00    0.00   57.94
02:12:32 AM    6    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
02:12:32 AM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

 

  68: 2650720493          0          0          0          0          0          0      29435   PCI-MSI-edge      eth1-TxRx-0
  69:          0 2650680679          0          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-1
  70:          0          0 2656291875          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-2

 73:          0          0          0 2652343941      29087          0          0          0   PCI-MSI-edge      eth2-TxRx-0
  74:          0          0          0          0 2653065247      30610          0          0   PCI-MSI-edge      eth2-TxRx-1
  75:          0          0          0          0          0 2658333352          0          0   PCI-MSI-edge      eth2-TxRx-2
 

 

 

В dmesg о сетевой:

[    4.685799] ixgbe: Receive-Side Scaling (RSS) set to 3
[    4.685854] ixgbe: Flow Director packet buffer allocation set to 3

[    4.847829] ixgbe 0000:01:00.0: irq 68 for MSI/MSI-X
[    4.847833] ixgbe 0000:01:00.0: irq 69 for MSI/MSI-X
[    4.847836] ixgbe 0000:01:00.0: irq 70 for MSI/MSI-X
[    4.847838] ixgbe 0000:01:00.0: irq 71 for MSI/MSI-X
[    4.849246] ixgbe 0000:01:00.0: PCI Express bandwidth of 32GT/s available
[    4.849309] ixgbe 0000:01:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)

 

 

 

Как можно догрузить последние ядра прерываниями сетевой ?

 

PS

Обнаружилась строка в /etc/modprobe.d в файле ixgbe.conf

options ixgbe allow_unsupported_sfp=1,1 RSS=2,2 FdirPballoc=2,2

 

Видимо каждому гнезду сетевой RSS=2 задает по паре прерываний на тх и рх ? А ядер 8

Как то можно это дело на лету изменить ? или править и ребутить ?

 

 

 

 

Изменено 23 октября, 2017 пользователем Azamat

[vasya_petrovich]

Судя по тому, что вы скинули у Вас сетевая на 3 совмещенные очереди TxRx на каждый интерфейс.
Прерывания у вас и так раскиданы по ядрам (по 6 ядрам), так что тут все нормально.

Возможно дрова можно загрузить с параметрами RSS=4,4 ?
Тогда можно "размазать" 2 порта сетевой на все 8 ядер процессора.

Изменено 23 октября, 2017 пользователем vasya_petrovich

[vasya_petrovich]

1 час назад, Azamat сказал:

Обнаружилась строка в /etc/modprobe.d в файле ixgbe.conf

options ixgbe allow_unsupported_sfp=1,1 RSS=2,2 FdirPballoc=2,2

 

Видимо каждому гнезду сетевой RSS=2 задает по паре прерываний на тх и рх ? А ядер 8

Как то можно это дело на лету изменить ? или править и ребутить ?

Дрова в любом случае выгружать надо, а это падение интерфейсов eth.

По факту в дмесг у вас rss=3, а в конфигурационном файле 2. Подозреваю, что подправив в файле значения опций драйвера при следующем ребуте ничего не изменится.

По всей видимости надо исполнить комманду update-initramfs.

Гуру, подправьте, ежели вру где...

[kayot]

vasya_petrovich 

Скорее в .conf файле изменения вносили уже после загрузки сервера, всегда нужно искать самое просто решение :)

 

Поставить rss=4,4 и перегрузить.

[pppoetest]

У меня не заработало без апдейта initramfs

[Azamat]

a RSS=8,8 будет сильно не хорошо ? Типа по числу ядер 

[vasya_petrovich]

Я бы не стал выставлять RSS=8,8 даже если бы были разделенные очереди RX и TX.
ИМХО: Лучше выставить 4,4, и распределить прерывания на все 8 ядер.
 

[pppoetest]

Я бы ещё уточнил по поводу 8-ми ядер, если половина из них - HT, то лучше отключить их.

[Azamat]

Нет, ядра честные.

 

update-initramfs - пришлось делать.

 

Осталось порешать вопрос с мелкими потерями. Так и теряет 1-2 пакета из 500. Уже и снмп опрос выключил, думал - мало ли что. Погашу пожалуй еще демон снмп на самом сервере.

 

perf stat -a -e cache-misses,cache-references sleep 10

 Performance counter stats for 'system wide':

          27238043      cache-misses              #    5.784 % of all cache refs     [100.00%]
         470945426      cache-references                                            

      10.000608309 seconds time elapsed

 

Терпимый показатель промахов ?

 

Загрузка проца.

11:05:53 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
11:05:54 AM  all    0.00    0.00    0.00    0.00    0.00   17.65    0.00    0.00   82.35
11:05:54 AM    0    0.00    0.00    0.00    0.00    0.00   18.00    0.00    0.00   82.00
11:05:54 AM    1    0.00    0.00    0.00    0.00    0.00   17.35    0.00    0.00   82.65
11:05:54 AM    2    0.00    0.00    0.00    0.00    0.00   15.84    0.00    0.00   84.16
11:05:54 AM    3    0.00    0.00    0.00    0.00    0.00   19.05    0.00    0.00   80.95
11:05:54 AM    4    0.00    0.00    0.00    0.00    0.00   19.05    0.00    0.00   80.95
11:05:54 AM    5    0.00    0.00    0.00    0.00    0.00   17.31    0.00    0.00   82.69

 

Изменено 24 октября, 2017 пользователем Azamat

[Alex/AT]

net.core.dev_weight = 16
net.core.netdev_budget = 256
net.core.netdev_max_backlog = 16000
net.core.netdev_tstamp_prequeue = 0

Единственное что - заранее сохраните старые значения, на ряде карт можно таким выворачиванием параметров weight/budget сделать хуже.

Ну и да, если у вас большое число сессий сквозь NAT с трекингом - что у вас в net.netfilter.nf_conntrack_buckets?

[Azamat]

Сейчас так

net.core.dev_weight = 64
net.core.netdev_budget = 300
net.core.netdev_max_backlog = 1000
net.core.netdev_tstamp_prequeue = 1

net.netfilter.nf_conntrack_buckets = 2097152

Потеря пакета на исходящем интерфейсе "в мир" выглядит так: (на входящем из серой сети все 500 пакетов на трансляцию приходят без потерь)

11:14:31.393667 IP 212.Х  > 217.69.139.70: ICMP echo request, id 33361, seq 163, length 64
11:14:33.395631 IP 212.Х  > 217.69.139.70: ICMP echo request, id 33361, seq 165, length 64

 

11:15:31.453552 IP 212.Х  > 217.69.139.70: ICMP echo request, id 33361, seq 223, length 64
11:15:33.455509 IP 212.Х  > 217.69.139.70: ICMP echo request, id 33361, seq 225, length 64

 

Через 3-4 цикла по 500 пакетов проходит вообще без потерь

--- www.MAIL.ru ping statistics ---
500 packets transmitted, 500 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 53.324/53.860/58.101/0.282 ms

 

Изменено 24 октября, 2017 пользователем Azamat

[Azamat]

Обратил внимание сейчас, что возможно в момент потери сильно снизилась нагрузка на процессор с типичных за время очередного цикла пинга 18-20 до 12-10 проц, потом произошло восстановление :

 

12:53:11 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:53:12 PM  all    0.00    0.00    0.00    0.00    0.00   18.84    0.00    0.00   81.16
12:53:12 PM    0    0.00    0.00    0.00    0.00    0.00   19.19    0.00    0.00   80.81
12:53:12 PM    1    0.00    0.00    0.00    0.00    0.00   19.19    0.00    0.00   80.81
12:53:12 PM    2    0.00    0.00    0.00    0.00    0.00   18.00    0.00    0.00   82.00
12:53:12 PM    3    0.00    0.00    0.00    0.00    0.00   18.81    0.00    0.00   81.19
12:53:12 PM    4    0.00    0.00    0.00    0.00    0.00   20.19    0.00    0.00   79.81
12:53:12 PM    5    0.00    0.00    0.00    0.00    0.00   17.65    0.00    0.00   82.35

12:53:12 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:53:13 PM  all    0.17    0.00    0.00    0.00    0.00   12.75    0.00    0.00   87.09
12:53:13 PM    0    0.00    0.00    0.00    0.00    0.00   11.22    0.00    0.00   88.78
12:53:13 PM    1    0.00    0.00    0.00    0.00    0.00   12.87    0.00    0.00   87.13
12:53:13 PM    2    0.00    0.00    0.00    0.00    0.00   12.12    0.00    0.00   87.88
12:53:13 PM    3    0.00    0.00    0.00    0.00    0.00   11.88    0.00    0.00   88.12
12:53:13 PM    4    0.00    0.00    0.00    0.00    0.00   14.56    0.00    0.00   85.44
12:53:13 PM    5    0.00    0.00    0.00    0.00    0.00   13.73    0.00    0.00   86.27

12:53:13 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:53:14 PM  all    0.00    0.00    0.00    0.33    0.00   10.95    0.00    0.00   88.73
12:53:14 PM    0    0.00    0.00    0.00    2.00    0.00   10.00    0.00    0.00   88.00
12:53:14 PM    1    0.00    0.00    0.00    0.00    0.00    9.90    0.00    0.00   90.10
12:53:14 PM    2    0.00    0.00    0.00    0.00    0.00   10.00    0.00    0.00   90.00
12:53:14 PM    3    0.00    0.00    0.00    0.00    0.00   10.89    0.00    0.00   89.11
12:53:14 PM    4    0.00    0.00    0.00    0.00    0.00   12.50    0.00    0.00   87.50
12:53:14 PM    5    0.00    0.00    0.00    0.00    0.00   10.78    0.00    0.00   89.22

12:53:14 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:53:15 PM  all    0.00    0.00    0.00    0.00    0.00   20.33    0.00    0.00   79.67
12:53:15 PM    0    0.00    0.00    0.00    0.00    0.00   20.00    0.00    0.00   80.00
12:53:15 PM    1    0.00    0.00    0.00    0.00    0.00   21.57    0.00    0.00   78.43
12:53:15 PM    2    0.00    0.00    0.00    0.00    0.00   17.35    0.00    0.00   82.65
12:53:15 PM    3    0.00    0.00    0.00    0.00    0.00   21.70    0.00    0.00   78.30
12:53:15 PM    4    0.00    0.00    0.00    0.00    0.00   20.19    0.00    0.00   79.81
12:53:15 PM    5    0.00    0.00    0.00    0.00    0.00   20.75    0.00    0.00   79.25

 

Сейчас сделаю перепроверку с записью в файл

[Azamat]

В отчаянии прибил на НАТ сервере статиком арп запись вышестоящего интерфейса - и уже два цикла по 500 пакетов без потерь. Сейчас пошел цикл в 1000 пакетов. Надеюсь, будет чисто.

 

Как стандартное поведение АРП системы могло сказываться на потерях ? Неужели на так долго терялся мак вышестоящего интерфейса в момент expiry, что целый пакет успевал дропнуться ?

 

 

PS: Чисто прошел цикл в 1000 пакетов, что не было ни разу за последние неск. дней.

 

64 bytes from 217.69.139.70: icmp_seq=998 ttl=55 time=57.011 ms
64 bytes from 217.69.139.70: icmp_seq=999 ttl=55 time=57.016 ms

--- www.MAIL.ru ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss

 

Изменено 24 октября, 2017 пользователем Azamat

[nuclearcat]

Проверьте arping на вышестоящего, есть ли дропы - возможно провайдер не отвечает вовремя на arp(его роутер перегружен оными и дропает их).

[Azamat]

Вышестоящий интерфейс - это  тоже наше железо, SVI на L3 коммутаторе Cisco. Вполне подзагружен, заняты все 48 портов на 10Гб/с и пара на 40.

В башню как-то не пришла мысль, что он чего-то не могет. Судя по всему, оказца кое с чем и не может адекватно справиться.

 

Сейчас отгоняю тест на 2К пакетов, потом на ночь поставлю 10к. Надеюсь, что данный понт получилось победить с всеобщей помощью.

 

P.S.

Тест на 2К пакетов - чисто.

64 bytes from 217.69.139.70: icmp_seq=1999 ttl=55 time=57.209 ms

--- www.mail.ru ping statistics ---
2000 packets transmitted, 2000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 56.634/57.201/58.556/0.216 ms

 

Будем считать, что победа за человеком ( по имени All :) )

Изменено 24 октября, 2017 пользователем Azamat