Tcp Dup ACK--又是数据库的问题

凌晨4点,一个程序在查询数据库时挂起,通过gdb定位问题发生在OTL的fetch函数。抓包显示数据库响应后,应用连续收到Dup ACK,间隔遵循TCP超时策略。发现数据库主机为AIX,可能是应用发送请求,数据库响应,但部分数据丢失导致的通信异常。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近,值班的同学反映,有个程序定时会在凌晨4点的时候挂起,重启后恢复,让开发的同事

查了一下,有可能挂起的地方只有在查询数据库,后来gdb也证明了是挂在otl的fetch函数,

这个问题让我想起了之前的问题,也是同个程序,也是在查询数据库,所以就叫同事捉了个

包,一打开,比较奇怪:

image

04:17:19 向数据库发起数据,然后回了个ACK,再发了个数据,再回个ACK。紧接着就不停地重发那个ACK了。

会发重复ACK(Dup ACK)理论上是收到数据了,再会回ACK,而回重复ACK应该是收到的是乱序的包,有些

数据丢了,或者是服务器不停地重发同一个包。由于捉包的同事只捉了dst端口,所以来的数据包看不到,今晚

再捉一次,希望能看到真相。 Dup ACK的间隔分别是: 3s, 6s, 12s, 24s, 48s, 64s, 64s,64s 64s,64s,64s

2014-10-30

发现这个超时时间竟然跟TCP/IP详解的说明完全对得上,今天才发现数据库主机是AIX,原来unix的实现还是

这样,Linux做了不少改动。

从这两天发的包已经可以确认,是应用向数据发起请求,数据库收到了,回了数据,应用回了ACK,这个回得

到,接着应用再请求数据,这时数据库发了一个大包,应用只收到第一个包,回了ACK,这个ACK丢了,数据

库不停地重发那个包,应用是收到了,但回了ACK数据库一直收不到了,重发12次后,发了RST,这个RST也

没有收到。这个现象非常奇怪,现在还不知道原因为何:

image

转载于:https://my.oschina.net/mawx/blog/338291

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值