Azamat Posted October 22, 2017 Posted October 22, 2017 Всем доброго дня. Плз подскажите, кто знает. Есть сервер под Линукс, функция - НАТ, трафика порядка 6-7 гиг. Обратил внимание, что на нем теряются по 2-4 пакета из 500. Со стороны "серой" сети отправляю дозированно по 500 icmp до майл.ру, вижу что на входящий интерфейс со стороны "серой" сети все 500 пакетов приходят, но с соотв. "белого" адреса в сторону майл.ру уходят на 2-4 пакета меньше. Куда они могут деться-то между двумя интерфейсами на сервере ? Как именно продиагностировать ? Есть аналогичный сервер, сделанный клонированием с целевого - на том же трафике потерь нету. Какая доп. инфа нужна, чтобы более полно раскрыть тему ? Вставить ник Quote
nuclearcat Posted October 22, 2017 Posted October 22, 2017 ethtool -S mpstat -P ALL 1 на 2-3 секунды статистики (а вообще надо понаблюдать - нет ли всплесков) ifconfig Вставить ник Quote
Azamat Posted October 22, 2017 Author Posted October 22, 2017 ethtool даёт простыню, оттуда надо какой то определенный раздел ? ifconfig - часть со статистикой по интерфейсам ? вряд ли нужны сами ип адреса ? Вставить ник Quote
default_vlan Posted October 22, 2017 Posted October 22, 2017 Проверять потери надо не до mail.ru, а до шлюза провайдера. И вот если до шлюза провайдера будут потери, тогда и нужно вдаваться в полемику. Почему? Потому что: 1. я сомневаюсь, что вы представитель группы системных инженеров mail.ru и пишете сюда вместо того, чтобы воспользоваться собственным сервисом ответов; 2. по пути следования от вашего внешнего IP до шлюза провайдера меньше устройств, чем до конечного ресурса, за их работу отвечаете не вы ни ваш провайдер. По этой причине следует запустить 2 ping'а - первый на шлюз провайдера, а второй на mail.ru и сделать это с непосредственно сервера доступа. Далее решим как быть. Вставить ник Quote
Azamat Posted October 23, 2017 Author Posted October 23, 2017 На всякий случай уточню - потерю дает именно НАТ сервер, на входящий интерфейс с "серой" стороны приходят все 500 пакетов, а в сторону внешки (в данном случае, майл.ру) уходят с "белого" адреса НАТ сервера на 2-4 пакета меньше. К вышестоящим претензиев не имеем. Вставить ник Quote
Azamat Posted October 23, 2017 Author Posted October 23, 2017 Просмотр существующей темы про Линукс НАТ натолкнул проверить: 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 Там же было написано, что рост ошибок может быть связан с патчкордом. Заменю-проверю. Вставить ник Quote
rm_ Posted October 23, 2017 Posted October 23, 2017 Или оффлоады попробовать выключить. ethtool -K eth1 rx off tx off А сетевые карты какие, вообще? Вставить ник Quote
nuclearcat Posted October 23, 2017 Posted October 23, 2017 Выключать стоит только tso, да и даже он на потери обычно не влияет. rx_csum_offload_errors надо смотреть соотносительно к общему количеству пробегающих пакетов Вставить ник Quote
Azamat Posted October 23, 2017 Author Posted October 23, 2017 (edited) не помогла замена патчкорда. Менять сервер ? может что то с оперативой за 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%. Мистика. Edited October 23, 2017 by Azamat Вставить ник Quote
Azamat Posted October 23, 2017 Author Posted October 23, 2017 (edited) Уважаемые друзья, плз подскажите еще по одной теме: в НАТ сервере проц на 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 Как то можно это дело на лету изменить ? или править и ребутить ? Edited October 23, 2017 by Azamat Вставить ник Quote
vasya_petrovich Posted October 23, 2017 Posted October 23, 2017 (edited) Судя по тому, что вы скинули у Вас сетевая на 3 совмещенные очереди TxRx на каждый интерфейс. Прерывания у вас и так раскиданы по ядрам (по 6 ядрам), так что тут все нормально. Возможно дрова можно загрузить с параметрами RSS=4,4 ? Тогда можно "размазать" 2 порта сетевой на все 8 ядер процессора. Edited October 23, 2017 by vasya_petrovich Вставить ник Quote
vasya_petrovich Posted October 23, 2017 Posted October 23, 2017 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. Гуру, подправьте, ежели вру где... Вставить ник Quote
kayot Posted October 23, 2017 Posted October 23, 2017 vasya_petrovich Скорее в .conf файле изменения вносили уже после загрузки сервера, всегда нужно искать самое просто решение :) Поставить rss=4,4 и перегрузить. Вставить ник Quote
pppoetest Posted October 23, 2017 Posted October 23, 2017 У меня не заработало без апдейта initramfs Вставить ник Quote
Azamat Posted October 23, 2017 Author Posted October 23, 2017 a RSS=8,8 будет сильно не хорошо ? Типа по числу ядер Вставить ник Quote
vasya_petrovich Posted October 24, 2017 Posted October 24, 2017 Я бы не стал выставлять RSS=8,8 даже если бы были разделенные очереди RX и TX. ИМХО: Лучше выставить 4,4, и распределить прерывания на все 8 ядер. Вставить ник Quote
pppoetest Posted October 24, 2017 Posted October 24, 2017 Я бы ещё уточнил по поводу 8-ми ядер, если половина из них - HT, то лучше отключить их. Вставить ник Quote
Azamat Posted October 24, 2017 Author Posted October 24, 2017 (edited) Нет, ядра честные. 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 Edited October 24, 2017 by Azamat Вставить ник Quote
Alex/AT Posted October 24, 2017 Posted October 24, 2017 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? Вставить ник Quote
Azamat Posted October 24, 2017 Author Posted October 24, 2017 (edited) Сейчас так 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 Edited October 24, 2017 by Azamat Вставить ник Quote
Azamat Posted October 24, 2017 Author Posted October 24, 2017 Обратил внимание сейчас, что возможно в момент потери сильно снизилась нагрузка на процессор с типичных за время очередного цикла пинга 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 Сейчас сделаю перепроверку с записью в файл Вставить ник Quote
Azamat Posted October 24, 2017 Author Posted October 24, 2017 (edited) В отчаянии прибил на НАТ сервере статиком арп запись вышестоящего интерфейса - и уже два цикла по 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 Edited October 24, 2017 by Azamat Вставить ник Quote
nuclearcat Posted October 24, 2017 Posted October 24, 2017 Проверьте arping на вышестоящего, есть ли дропы - возможно провайдер не отвечает вовремя на arp(его роутер перегружен оными и дропает их). Вставить ник Quote
Azamat Posted October 24, 2017 Author Posted October 24, 2017 (edited) Вышестоящий интерфейс - это тоже наше железо, 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 :) ) Edited October 24, 2017 by Azamat Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.