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

Пропадают пакеты

 , ,


0

1

Пропадают пакеты 1%, время задержки колбасит от 88 до 155 ms. Теряются на конечной машине с Debian. По tcpdump ничего подозрительного нет. Куда смотреть, как диагностировать?

★★★★
← Несколько версий PHP на одном сервере
Ansible пропускает task'и →

Ответ на: комментарий от gobot

Ну, банально кабель/конектор на целесность(визуально осмотреть), переобжать. В иделе тыкнуть вместо дебиан что то другое и проверить будет ли так же или нет.

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

88 до 155 ms - это с соседней машины или из интернетов ?

Для гигабит-езернета это полный 3.14.

Можно посмотреть «ethtool -S ethX | grep error».

Потом смотрим что происходит на коммутаторе, к которому поключен компутер.

PS 1% потерь для tcp практически незаметен.

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

Нет, через 14 узлов. Какой 3.14, пингую с удаленного компа, пишет время=88мс

ethtool -S enp4s0 | grep error
     rx_errors: 86
     tx_errors: 0
     rx_length_errors: 86
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_missed_errors: 564127789
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 86
     rx_align_errors: 0
     rx_csum_offload_errors: 4461
     uncorr_ecc_errors: 0
     corr_ecc_errors: 0


К коммутатору не имею доступа. 1% очень заметен, даже в ssh

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

Написал в супорт... но там ответа ждать два дня, к тому же проблема эта появляется периодически, не всегда

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

Нет, через 14 узлов.

Проверяй поочерёдно до каждого узла. ping, traceroute, mtr

Здесь что угодно может быть. Соответсвенно и суппорт тебе ничего не ответит.

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

А что проверять? Запустил MTR, на моей машине 3% потерь, на промежуточных по 1

% Sent Recv
..
1 3225 3222
...
1 3233 3232
...
3 2916 2835 моя машина


Запустил ещё вот что
tcpdump -n port not 22
163076193 packets captured
167887506 packets received by filter
4811183 packets dropped by kernel
3163893 packets dropped by interface

Это что говорит, что 4811183 пакетов ядро дропнуло? Что значат эти цифры и почему дропов столько?

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

Нет, через 14 узлов. Какой 3.14, пингую с удаленного компа, пишет время=88мс

гм. на 14 хопах может быть все что угодно...

rx_missed_errors - это дропы входящих пакетов из-за нехватки буферов. Нужно тюнить систему, как минимум RPS.

а что говорит grep enp4s0 /proc/interrupts ?

tcpdump -n port not 22
163076193 packets captured
167887506 packets received by filter
4811183 packets dropped by kernel
3163893 packets dropped by interface

Это за какое время ?

А трафик там сколько мегабит/с ?

tcpdump с выводом на консоль на таких скоростях вреден.

vel ★★★★★
()
Ответ на: комментарий от vel 
grep enp4s0 /proc/interrupts
 28:      25885       3397       2441        840      22499       7443 1853878386       1292   PCI-MSI 2097152-edge      enp4s0-rx-0
 29:      22690       3526       2495 3662786534      18611       7034       2615       1553   PCI-MSI 2097153-edge      enp4s0-tx-0
 30:          1          0          0          0          0     353228          1          0   PCI-MSI 2097154-edge      enp4s0



Время не засекал, ну может час. Потом по ctrl+c убил

Вот точный вывод:

tcpdump -w capture -c 1000000 port not 22
tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size 262144 bytes
1000000 packets captured
1002757 packets received by filter
2718 packets dropped by kernel
3205 packets dropped by interface


Трафик в момент замера был 150-200 mbps out

Нужно тюнить систему, как минимум RPS

Это в /etc/sysctl? Можно пример того что тюнить?

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

Это в /etc/sysctl? Можно пример того что тюнить?

Что-то типа 'echo F0 >/sys/class/net/XXXX/queues/rx-0/rps_cpus'

Но, возможно и «ethtool -G» поможет.

100-200Мбит/с это не очень много. Вопрос в pps.

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

Если какие то лимиты и были превышены, но в логах ничего нет, это нормально? Как вообще понять что превышено? 

ethtool -G enp4s0
no ring parameters changed, aborting


Сейчас все нормально... четкий пинг 88мс без потерь...

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

не знаю, написал в супорт. Да вряд ли, провайдер крупный в Германии. К тому же на моем сервере они теряются судя по MTR

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

man ethtool на тему "-G"

Посмотри на текущие настройки через «ethtool -g enp4s0»

Увеличь число буферов для приема.

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

А точно ли в буферах дело? Или тупо увеличить и посмотреть как будет?.. Трафик то не сильно большой, бывало и 500mbsp на этом же сервере. Или может быть флуд какой нибудь, как определить причину точную из-за чего дропаются пакеты? Видел тулзу dropwatch, которая якобы мониторит дропы на уровне ядра, но там с установкой заиуты какие то, нужно ядро перекомпилировать чтобы включить этот мониторинг... и вообще не знаю нужна ли мне эта прога или не туда копаю )

ethtool -g enp4s0
Ring parameters for enp4s0:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256

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

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

Видел тулзу dropwatch, которая якобы мониторит дропы на уровне ядра, но там с установкой заиуты какие то, нужно ядро перекомпилировать чтобы включить этот мониторинг

Все что отбросила карта есть в статистике карты, а то, что отбрасывает ядро есть в счетчиках /proc/net/{snmp,snmp6,dev}

Еще iptables/conntrack может дропать.

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

Кстати в iptables 9000 правил. Может из-за этого? Хотя на другом сервере тоже столько же, но там скорость на порядок меньше идет

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

Забил в zabbix pps, максимальное значение было 145\68kpps(out\in). Ещё заметил что исходящий трафик не поднимается выше 200mbps(хотя раньше было 500 и пики до 1gbps). Колбасить ping начинает именно когда скорость приближается к 200mbps...

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

С третьей машины попингуй и потрассеруй эти обе машины. На какую то одну валятся пакеты или на обе?

burato ★★★★★
()

Скачал тестовый файл 24гига с сервера,скорость поднялась до 500mbps, но стало все отваливаться, задержки увеличились, потери пакетов

ifconfig показывает какие то огромные потери

ifconfig
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        RX packets 4787066868  bytes 1428217381646 (1.2 TiB)
        RX errors 89  dropped 566139463  overruns 0  frame 89
        TX packets 7637664932  bytes 8713377703001 (7.9 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf200000-df220000


dropped 566139463 это же очень много? На нормальном сервере эта цифра около 300 за 113 days uptime.
Провайдер говорит что все норм у него.

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

9000 правил - это много!

Запускаем «mpstat -P 6 5», где 6 - ядро которое обрабатывает прерывание rx-0 (28irq) и смотрим колонку %soft. Если там появляется что-то > 90%, значит нужно раскидывать обработку входящих пакетов на несколько ядер (rps должен помогать).

Если есть куча однотипных правил, то нужно попытаться переписать с использованием ipset. Обновление таблицы правил iptables - это очень тяжелая операция.

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

Это много. Проблема не в физике.

Начни с включения rps echo 'F0' >/sys/class/net/enp4s0/queues/rx-0/rps_cpus

Убедись, что нагрузка %soft упала на ядре 6 и появилась на ядрах 4,5,7 через «mpstat -P ALL 5»

Если на карте не включен offload ( ethtool -S enp4s0 | grep offload будет нулевой), то можно попробовать включить всякие offload на сетевой карте

«ethtool -K enp4s0 sg on tso on gso on gro on»

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

softirq сильно увеличился(в среднем сейчас 15%) на серверах где много правил iptables

mpstat -P 6 5
CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:       6    0.50    0.00    1.28    3.45    0.00    5.84    0.00    0.00    0.00   88.94


Но я сбросил iptables -F и ничего не изменилось. Потери пакетов начинаются когда скорость загрузки канала доходит до 200mbps(на 1 сервере) и 300(на втором). Оба эти сервера находятся у разных провайдеров и такие ограничений раньше не наблюдалось. Скорость тупо не поднимается. Такое ощущение что кто то досит

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

5.84% это вообще смешно. 

Linux 4.4.142 (ls-gw-r2)        19.09.2018      _x86_64_        (8 CPU)

20:04:09     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
20:04:14       4    0.00    0.00    0.00    0.00    0.60   44.20    0.00    0.00   55.20
20:04:19       4    0.00    0.00    0.00    0.00    0.80   43.29    0.00    0.00   55.91
это отсутствие проблем при трафике 90kpps/90+450Мбит с 15 kint/s (зеркалированный трафик)

А если ДоС, то те 9000 правил - не они ли становятся проблемой? Точнее то, как эти 9000 правил добавляются ?

Другой момент - ты написал что трафик 145\68kpps(out\in), а это уже повод задуматься над более тонкой настройке сетевого стека.

Интересно, что у тебя говорит «mpstat -I SUM 5» ? Из него нужно вычитать частоту таймера*число_ядер

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

Сделай простой тест - добавление 9000 однотипных правил в цепочку и замерь время.

Запусти iptables -N X ; time for i in `seq 1 90`; do for j in `seq 1 100`; do iptables -A X -s 10.1.$i.$j; done; echo -n

это более 30 секунд!

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

Отключал файрвол, не помогало. Разве 145\68kpps это много? Всегда скорость была 500-700mbps и нормально все работало, проблемы эти начались 3 дня назад только

10:28:10 PM  CPU    intr/s
10:28:15 PM  all   2249.80
10:28:20 PM  all   2243.00
10:28:25 PM  all   2203.00
10:28:30 PM  all   2240.00
10:28:35 PM  all   2281.20
10:28:40 PM  all   2267.80
10:28:45 PM  all   2237.80
10:28:50 PM  all   2114.40
10:28:55 PM  all   2112.20
10:29:00 PM  all   2332.60
10:29:05 PM  all   2204.60
10:29:10 PM  all   2333.60
10:29:15 PM  all   2377.40

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

Не в этом дело, правила уже давно не обновляются на этом сервере. А вообще да, удаляются и добавляются довольно долго, если их много... Но проц сейчас не нагружен, где то на 10-20%

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

На старых ядрах этот процесс очень тяжелый с кучей локов.

Если проблемы начались недавно, то тогда это похоже на дос/ддос, а при нем conntrack обычно разростается и может давать побочные эффекты. Есть смысл мониторить «sysctl net.netfilter.nf_conntrack_count»

Для проверки можно временно отключть iptables и conntrack 

iptables -t raw -I PREROUTING -j CT --notrack
iptables -t raw -I OUTPUT -j CT --notrack
conntrack -F

А еще совсем недавно (летом) был найден в ядре баг tcp-шный. Если не ошибаюсь, то для минимизации его воздействия рекомендовали

sysctl -w net.ipv4.ipfrag_low_thresh=196608
sysctl -w net.ipv4.ipfrag_high_thresh=262144

Ну или апгрейд ядра.

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

сделал 

iptables -t raw -I PREROUTING -j CT --notrack
iptables -t raw -I OUTPUT -j CT --notrack

не помогло
conntrack -F
conntrack: command not found


протестировал через iperf
iperf -c x.x.x.x  -t 200000 -P 65 -w 1MB -b 5000000 -u

Как только трафик переваливает за 300mbps начинаются дикие потери пакетов 30%. На сервере пропускная способность 1Gpbs, раньше обычный трафик был 500-700mbps без проблем. Куда смотреть?

MTR показывает что пакеты пропадают на конечном узле (50%), пингую с сервера шлюз, там тоже около 38% потерь

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

rx_missed: 0

ethtool -S enp2s0
NIC statistics:
     tx_packets: 3536356
     rx_packets: 269164
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 127658
     broadcast: 141503
     multicast: 3
     tx_aborted: 0
     tx_underrun: 0


Запустил в 10 потоков, тоже самое
iperf -P 10 -b 35000000 -w 1MB -u -t 700000

Именно после 300mbsp идет потери. Если 295 будет, то нормально. Хотел увеличить размер буфера, но пишет что не поддерживает
ethtool -G enp2s0 rx 4096
Cannot get device ring settings: Operation not supported

gobot ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Несколько версий PHP на одном сервере
Admin
Ansible пропускает task'и →