Pesquisa tpacket_rcv : está em af_packet.c . AF_PACKET significa tcpdump.
Parece que alguém viu um problema acionado pelo tcpdump, sem resolução: link
Mas eu desconfio sobre quedas em tpacket_rcv. Provavelmente significa saída de função através do rótulo ring_is_full . Parece que os pacotes não chegarão ao tcpdump porque seu buffer está sobrecarregado. No entanto, não acho que isso signifique que o pacote esteja (necessariamente) sendo descartado completamente; ele ainda pode alcançar o soquete UDP. Isso sugere que a sua transcrição do dropwatch não cobriu nenhuma das gotas UDP mostradas nos contadores. Eu não acho que AF_PACKET estão sendo contados como UDP cai só porque são dois soquetes de datagrama. Infelizmente, parece que esses tp_drops não são mostrados por netstat .
Eu gostaria de rodar o dropwatch e filtrar as linhas tpacket_rcv com grep -v . Apenas o suficiente para ver um aumento no seu contador de erros de recepção UDP.
Acho que rmem_max para UDP só ajudará se o aplicativo tentar aumentar os buffers de recebimento. Não há resultados reais de pesquisa para "opensips rmem". Eu tentaria aumentar rmem_default . Mas eu realmente espero que eles sejam mostrados como "receber erros de buffer" se esse fosse o problema ...
E, no entanto, eles não são erros de soma de verificação do UDP ...
Há outro sintonizador chamado netdev_max_backlog . Aparentemente, o contador de estouro correspondente é a segunda coluna de /proc/net/softnet_stat (há uma linha por cpu). Mas isso acontece antes que o pacote seja alimentado na pilha UDP, portanto, isso não deve afetar as estatísticas do UDP ...
Whelp, isso é tudo em que posso pensar agora, é um pouco misterioso: (.
EDITAR :
There is a setting in SIP proxy server related buffer size that size was small to handle high pps rate. After adjust that we are seeing good result. Drops are there, but very very low counts. – Satish