ss -tm
shows detailed memory information about each TCP session. I found that some of the tcp sessions show sock_drop
, here is one:
ESTAB ***** some irrelevant info here ****
skmem:(r0,rb3446699,t0,tb87040,f0,w0,o0,bl0,d222)
d222
in skmem, according the the man page, is the sock_drop number.
But ip -s link
(or ifconfig
) both shows 0 packet drops
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:d9:fb:52 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
79371129016 110948258 0 0 0 0
TX: bytes packets errors dropped carrier collsns
78030205763 96204113 0 0 0 0
So here is my question: What is the difference between packet drops showed in ip -s link
and sock_drop showed in ss -tm
? What are the possible reasons that causes packet drop and sock_drop? Is sock_drop related to tcp retransmission?
The
dropped
counter inip -s
is an OS-wide counter for ethernet frames dropped by the kernel because of things like CRC + checksum errors. Also other things like failed IP fragment re-assemblies.The
d222
counter there is a per-socket counter. Tryss -pntm
to see the process that owns it. What this means is that the OS tried to deliver a packet to a userspace program and failed because the receive buffer (rb3446699
) was full. This usually suggests that the software wasn't able to read from it quickly enough. Ther0
shows that it was empty at the time you ranss
so perhaps a transient error? These per-socket drops don't show inip -s
.Increasing the
rmem_max
andrmem_default
values insysctl
can help software ride over such transient errors, but there's a trade-off in memory usage (If you serve a lot of connections) and latency.NB: If you run
nstat
you can see a list of more specific OS counters, some of which are sum totals of socket-level errors such as these for UDP and TCP.