Shulou(Shulou.com)05/31 Report--

How to solve the problem of location server data discarding packets, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

When data packets are lost on a server, they must be for some reason. How do we analyze why packets are lost.

Here's what we want to know:

A packet enters your computer's network stack (RX) (for example, on port 8000). Is lost before the application corresponding to port 8000 is received.

Send a packet (TX). It was lost before it was sent out of your machine.

This article does not focus on "packets are lost during network transmission, let's diagnose with traceroute / count TCP retransmissions" (although this is also important)!

How do I know if the packet is discarded?

I asked a question on Twitter and got a very useful answer: "look at netstat-I!" This is the result of running on my laptop:

Bork@kiwi~ > sudo netstat-i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg docker0 1500 00 000 0 BMU enp0s25 1500 0 1235101 0 242 0 745760 00 0 BMRU lo 65536 0 21558 00 0 21558 0 0 0 LRU nlmon0 3776 0 551262 0 0 0 ORU

It seems that some received (RX) packets have been lost on enp0s25 (my wireless network card). But no TX packets are missing.

I was also told that running ethtool-S would help, but my ethtool didn't have the-S option.

How do you know why the packet was dropped?

Through Google search, I found a cool tool called dropwatch. There is no off-the-shelf Ubuntu installation package, but you can download it through github:

Https//github.com/pavel-odintsov/drop_watch

Here are the instructions I can compile:

Sudo apt-get install-y libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev git clone https://github.com/pavel-odintsov/drop_watch cd drop_watch/src vim Makefile # comment out the-Werror argument to gcc make

Here is the output! It tells me which kernel function loses the packet. Cool!

Sudo. / dropwatch-l kas Initalizing kallsyms db dropwatch > start Enabling monitoring... Kernel monitoring activated. Issue Ctrl-C to stop monitoring 1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad) 10 drops at tcp_v4_rcv+80 (0xffffffff8179a620) 1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7) 4 drops at unix_release_sock+20e (0xffffffff817dc94e) 1 drops at igmp_rcv+e1 (0xffffffff817b4c41) 1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

Monitoring dropped packets with perf

There is another cool way to debug what happens.

Thomas graf told me that you can use perf to monitor kfree_skb events, which will tell you when to drop packets (where the kernel stack occurs):

This is the answer to sudo perf record-g-a-e skb:kfree_skb sudo perf script's question on how to solve the problem of data discarding packets on location servers. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.