web同事开发了一个用于接收syslog数据的服务器，不清楚web的开发方式，用来联调的发送端是我们的C模块
反馈syslog udp形式接收正常，速度正常，数量也正常，syslog tcp形式接收开始比较快后面越来越慢，并且知道接收不到后数量和发送端发送数量也对不上

查看接收端发现recvq很高，并且87616这个数字停留了很久了

10.19.17.10是服务端(接收)，10.19.17.160是客户端(发送)

查看发送端的sendq也很高

发送端堆栈的堆栈停留在最上面一层停留在系统调用send上

以上接着查看发送端的网络问题发现延迟这些都正常，并且发送端使用syslog udp发送也是没问题的，所以判断为接收端问题，接收端处理太慢导致的，如此答复web同事后。web端最后排查是他们自身的问题。原话是：“不是，有问题的这种我是通过syslog提供的包搞的，之前没问题的用的apache的包搞的”。不过咱也不懂web，只要不是我们的问题就行了，不过大概也可以判断出来是web的接收端处理逻辑有问题导致发送端发送的数据阻塞了。

总结：
这里主要是使用netstat或者ss命令中的sendq和recvq来排查问题
sendq（发送队列）和recvq（接收队列）是系统级别的队列，而非特定于某个程序的队列。它们属于TCP/IP协议栈在网络接口和应用程序之间维护的数据缓冲区。

系统级别：
这两个队列是由操作系统内核管理的，用于在网络通信过程中暂存数据。
它们的存在是为了确保数据在网络传输中的可靠性和顺序性。

与程序的关系：
虽然sendq和recvq不是直接由程序创建的，但程序确实会与之交互。
当程序通过socket发送数据时，数据会被放入sendq中等待发送。
当程序通过socket接收数据时，它会从recvq中读取数据。