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

Теряются пакеты

 ,


0

1

На сервере (виртуальной машине) иногда начинают теряться пакеты. Примерно через 2 недели аптайма это происходит. Если перезагрузить - то всё нормально начинает работать. Куда можно смотреть? На CPU нагрузка в целом есть, но не прям перегружено. Памяти свободной много. Причём пакеты на этой неделе начали теряться в пятницу вечером, вообще не похоже, что от какой-то особой нагрузки, нагрузка идёт в рабочие дни и часы.

Пытался мониторить через ps что работает в тот момент, когда теряются пакеты - закономерности не выявил.

Вообще сервер это нода кубернетеса.

Пакеты теряются пачками примерно раз в 30-40 секунд. То работают, то теряются. Вот типичная картина:

64 bytes from 10.160.3.160: icmp_seq=1 ttl=64 time=0.343 ms
64 bytes from 10.160.3.160: icmp_seq=2 ttl=64 time=0.338 ms
64 bytes from 10.160.3.160: icmp_seq=3 ttl=64 time=0.261 ms
64 bytes from 10.160.3.160: icmp_seq=4 ttl=64 time=0.252 ms
64 bytes from 10.160.3.160: icmp_seq=5 ttl=64 time=0.265 ms
64 bytes from 10.160.3.160: icmp_seq=6 ttl=64 time=0.251 ms
...
64 bytes from 10.160.3.160: icmp_seq=24 ttl=64 time=0.241 ms
64 bytes from 10.160.3.160: icmp_seq=25 ttl=64 time=1.76 ms
64 bytes from 10.160.3.160: icmp_seq=26 ttl=64 time=0.252 ms
64 bytes from 10.160.3.160: icmp_seq=30 ttl=64 time=2318 ms
64 bytes from 10.160.3.160: icmp_seq=31 ttl=64 time=1294 ms
64 bytes from 10.160.3.160: icmp_seq=32 ttl=64 time=270 ms
64 bytes from 10.160.3.160: icmp_seq=33 ttl=64 time=0.249 ms
64 bytes from 10.160.3.160: icmp_seq=34 ttl=64 time=0.260 ms
...
64 bytes from 10.160.3.160: icmp_seq=65 ttl=64 time=0.245 ms
64 bytes from 10.160.3.160: icmp_seq=66 ttl=64 time=0.235 ms
64 bytes from 10.160.3.160: icmp_seq=67 ttl=64 time=0.234 ms
64 bytes from 10.160.3.160: icmp_seq=72 ttl=64 time=341 ms
64 bytes from 10.160.3.160: icmp_seq=73 ttl=64 time=6.38 ms
64 bytes from 10.160.3.160: icmp_seq=74 ttl=64 time=11.7 ms
64 bytes from 10.160.3.160: icmp_seq=75 ttl=64 time=12.8 ms
64 bytes from 10.160.3.160: icmp_seq=76 ttl=64 time=13.9 ms
64 bytes from 10.160.3.160: icmp_seq=77 ttl=64 time=12.8 ms
64 bytes from 10.160.3.160: icmp_seq=78 ttl=64 time=10.9 ms
64 bytes from 10.160.3.160: icmp_seq=79 ttl=64 time=0.266 ms
64 bytes from 10.160.3.160: icmp_seq=80 ttl=64 time=0.250 ms
...
64 bytes from 10.160.3.160: icmp_seq=106 ttl=64 time=0.280 ms
64 bytes from 10.160.3.160: icmp_seq=107 ttl=64 time=0.249 ms
64 bytes from 10.160.3.160: icmp_seq=111 ttl=64 time=1600 ms
64 bytes from 10.160.3.160: icmp_seq=112 ttl=64 time=576 ms
64 bytes from 10.160.3.160: icmp_seq=113 ttl=64 time=0.270 ms
64 bytes from 10.160.3.160: icmp_seq=114 ttl=64 time=0.267 ms
...
64 bytes from 10.160.3.160: icmp_seq=142 ttl=64 time=10.9 ms
64 bytes from 10.160.3.160: icmp_seq=146 ttl=64 time=811 ms
64 bytes from 10.160.3.160: icmp_seq=147 ttl=64 time=18.6 ms
64 bytes from 10.160.3.160: icmp_seq=148 ttl=64 time=11.9 ms
...
64 bytes from 10.160.3.160: icmp_seq=187 ttl=64 time=4.23 ms
64 bytes from 10.160.3.160: icmp_seq=188 ttl=64 time=0.250 ms
64 bytes from 10.160.3.160: icmp_seq=192 ttl=64 time=1051 ms
64 bytes from 10.160.3.160: icmp_seq=193 ttl=64 time=27.0 ms
64 bytes from 10.160.3.160: icmp_seq=194 ttl=64 time=13.4 ms

Иногда время отклика повышается до 10 мс. Вроде бы это от скачкообразного роста нагрузки. Периодически запускается около 20 процессов, которые потребляют весь CPU, видимо это и влияет на пинг, с этим понятно и «претензий нет». Но вот потери пакетов - это не понятно.

Через iftop смотрел - скачкообразного роста трафика в этот момент не наблюдается, сетевой интерфейс не перегружен.

Куда можно копать? Хотелось бы разобраться.

★★★★

Последнее исправление: vbr (всего исправлений: 2)
← Как правильно считать сумму размера файлов?
Как и чем узнать размер словаря ZIP-архива? →

Не пиши «на сервере», если речь про виртуалку. Для начала поставь сниффер на 10.160.3.160 и посмотри в какую сторону потери - к нему или назад. И можно ещё пинг в обратную сторону. Ну и ещё если можно поставить сниффер где-нить поближе к виртуалке то тоже не помешает.

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

Уже всё само починилось ): Буду опять ждать повторения. Вне виртуалки ничего поставить не могу, это арендовано у хостера, к железу у меня доступа нет, а от хостера ничего добиться не удалось.

Куда смотреть: если теряются исходящие пакеты? Или куда смотреть, если теряются входящие пакеты?

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

К чему это всё приведёт я заранее сказать не могу, может и оказаться что эти выяснения ничего не дадут.

А так, что ещё можно было: traceroute -I вместо пинга для 10.160.3.160. То же самое для внешнего айпи к которому у тебя есть доступ и куда можешь поставить сниффер. Ну и с внешнего своего айпи уже можно пинговать/трассировать путь к виртуалке. На самой виртуалке во время всех этих манипуляций можно тоже запустить tcpdump чтобы убедиться что пакеты не теряются где-то внутри ядра и посмотреть dmesg, нет ли ошибок нехватки буферов каких, или ещё чего информативного в это время.

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

firkax ★★★★★
()

Напомнило личный опыт, в порядке офтопика. Годами работал радиоканал на оборудовании ubiquiti, внезапно стали выпадать пакеты. Оказалось, вздулся кондер на одном из инжекторов для радиоточки. Какой я только статистики не насобирал… корреляций программных штук 10 точно выявил.

Anoxemian ★★★★★
()

Опять та же ситуация. Теперь даже ребут не помог.

Нашёл команду для статистики, так по ней вообще якобы ничего не теряется. Во дела.

ip -s link show enp3s0
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether fa:16:3e:e2:c4:ef brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped missed  mcast   
    6306239929 3806189  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    3049072720 4087049  0       0       0       0

Если все интерфейсы посмотреть (там их несколько десятков), то по некоторым единичные потери есть, но это явно не то, сколько пакетов теряется реально.

Вот выхлоп netstat -s, я тут вообще ничего не понял, но явного криминала не вижу. Попробую этот вывод помониторить.

Ip:
    Forwarding: 1
    13208950 total packets received
    9877557 forwarded
    0 incoming packets discarded
    3321831 incoming packets delivered
    13173190 requests sent out
    3 fragments failed
Icmp:
    183 ICMP messages received
    0 input ICMP message failed
    ICMP input histogram:
        destination unreachable: 11
        echo requests: 5
        echo replies: 167
    370 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 161
        echo requests: 204
        echo replies: 5
IcmpMsg:
        InType0: 167
        InType3: 11
        InType8: 5
        OutType0: 5
        OutType3: 161
        OutType8: 204
Tcp:
    283874 active connection openings
    8724 passive connection openings
    745 failed connection attempts
    797 connection resets received
    12 connections established
    3098396 segments received
    4626479 segments sent out
    9219 segments retransmitted
    16 bad segments received
    37313 resets sent
Udp:
    1630 packets received
    3 packets to unknown port received
    0 packet receive errors
    1724 packets sent
    0 receive buffer errors
    0 send buffer errors
UdpLite:
TcpExt:
    2 packets pruned from receive queue because of socket buffer overrun
    121025 TCP sockets finished time wait in fast timer
    5 time wait sockets recycled by time stamp
    5 packetes rejected in established connections because of timestamp
    22494 delayed acks sent
    6 delayed acks further delayed because of locked socket
    Quick ack mode was activated 5772 times
    1175368 packet headers predicted
    494274 acknowledgments not containing data payload received
    683938 predicted acknowledgments
    TCPSackRecovery: 23
    Detected reordering 21 times using SACK
    Detected reordering 1 times using time stamp
    4 congestion windows fully recovered without slow start
    1 congestion windows partially recovered using Hoe heuristic
    TCPDSACKUndo: 49
    467 congestion windows recovered without slow start after partial ack
    TCPLostRetransmit: 3993
    17 fast retransmits
    6 retransmits in slow start
    TCPTimeouts: 6205
    TCPLossProbes: 3325
    TCPLossProbeRecovery: 38
    TCPSackRecoveryFail: 2
    TCPBacklogCoalesce: 1206
    TCPDSACKOldSent: 5772
    TCPDSACKOfoSent: 1
    TCPDSACKRecv: 2629
    TCPDSACKOfoRecv: 1
    31934 connections reset due to unexpected data
    794 connections reset due to early user close
    TCPDSACKIgnoredOld: 1
    TCPDSACKIgnoredNoUndo: 820
    TCPSackMerged: 10
    TCPSackShiftFallback: 509
    TCPRcvCoalesce: 202563
    TCPOFOQueue: 1282
    TCPOFOMerge: 1
    TCPChallengeACK: 16
    TCPSYNChallenge: 16
    TCPSpuriousRtxHostQueues: 71
    TCPAutoCorking: 10930
    TCPSynRetrans: 132
    TCPOrigDataSent: 3218630
    TCPHystartTrainDetect: 11
    TCPHystartTrainCwnd: 278
    TCPACKSkippedChallenge: 1
    TCPKeepAlive: 2194
    TCPDelivered: 3500914
    TCPAckCompressed: 764
    TcpTimeoutRehash: 6205
    TcpDuplicateDataRehash: 3321
    TCPDSACKRecvSegs: 2631
    TCPDSACKIgnoredDubious: 1
IpExt:
    InNoRoutes: 4
    InOctets: 15114407545
    OutOctets: 31899019237
    InNoECTPkts: 18117918
    InECT0Pkts: 341
vbr ★★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от vbr

По tcpdump с одной стороны я вижу такое:

64 bytes from 10.160.3.160: icmp_seq=11 ttl=63 time=29.567 ms
64 bytes from 10.160.3.160: icmp_seq=12 ttl=63 time=28.044 ms
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
64 bytes from 10.160.3.160: icmp_seq=16 ttl=63 time=549.753 ms
64 bytes from 10.160.3.160: icmp_seq=17 ttl=63 time=27.026 ms

А на хосте я вижу такое:

12:20:43.520761 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 12, length 64
12:20:43.520804 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 12, length 64
...
12:20:44.537915 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 13, length 64
12:20:44.537944 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 13, length 64
12:20:45.524274 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 14, length 64
12:20:45.524300 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 14, length 64
12:20:46.526865 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 15, length 64
12:20:46.526887 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 15, length 64
...
12:20:47.537304 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 16, length 64
12:20:47.537345 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 16, length 64
12:20:48.535304 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 8508, seq 17, length 64
12:20:48.535345 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 8508, seq 17, length 64

Т.е. с точки зрения tcpdump запросы приходят и ответы уходят.

Но иногда вижу и такое:

12:33:27.652569 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 24636, seq 90, length 64
12:33:27.652611 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 24636, seq 90, length 64
12:33:28.784899 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 24636, seq 91, length 64
12:33:28.784936 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 24636, seq 91, length 64
12:33:34.404666 IP 10.160.0.10 > 10.160.3.160: ICMP echo request, id 24636, seq 96, length 64
12:33:34.404699 IP 10.160.3.160 > 10.160.0.10: ICMP echo reply, id 24636, seq 96, length 64

Т.е. запросы не приходят.

По всему выходит, что дело в роутере? Непонятно то, что другие (виртуальные) машины в этой же подсети с этим же (виртуальным) роутером работают на 100% стабильно и никаких потерь не испытывают.

vbr ★★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 2)
← Как правильно считать сумму размера файлов?
General
Как и чем узнать размер словаря ZIP-архива? →