close_wait问题记录

前言

有一次商户反映访问我们服务出现问题,很多超时现象,我们登陆服务器查询问题时,发现-bash: fork: retry: 资源暂时不可用,并检查了系统的tcp连接的情况,发现closewait非常多。

问题描述

现象有

  1. 商户连接不到我们的服务
  2. xshell登陆服务器报 bash: fork: retry: 资源暂时不可用
  3. 查看系统tcp连接情况,发现 closewait非常多
  4. 应用进程存活,日志正常打印。

我准备从外到内分析问题。网络-》系统-》应用。

1. 网络

商户访问不到我们服务,这牵扯到的网络测问题非常多。我联系了网络部同事,询问这个时间段是否有商户访问我司网络出现问题,网络部确定没有问题。

2. 系统

2.1 资源暂时不可用

出现 bash: fork: retry: 资源暂时不可用。我查询资料,结果如下:

可能是因为资源限制,要么是系统自己的,要么是系统的用户下。资源限制可用通过 ulimit -a 查看。ulimit -u 会打印最大用户进程数。如果超过了最大进程数,fork不能创建新的进程,就会打印上面的错误。也有可能是因为交换内存资源问题。

我就使用ulimit -u查看最大用户进程数是1024。

2.2 tcp closewait很多

tcp closewait 是在关闭连接时,服务端的一个中间状态。这里先介绍下tcp连接释放。

2.2.1 tcp 释放连接过程

tpc_close__.jpg

tpc建立连接完成,数据传输结束后,通信的双方都可以释放连接。现在A和B都处于建立连接的状态。A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把连接释放报文段首部FIN置1,其序号seq=u,它等于前面已传送过的数据最后一个字节的序号加1。这时A处于FIN-WAIT-1(终止等待1),等待B确认。注意,TPC规定,fin报文即使不携带数据,也要消耗一个序号。

B收到连接释放报文段后即发出确认,而这个报文段自己的序号是v,等于B前面已经传送过的数据最后一个字节的序号加1,然后B就进入CLOSE-WAIT状态。TCP服务器进程就应通知高层应用进程,因而从A到B这个方向的连接就释放了,这是TCP处于半关闭状态,即A已经没有数据要发送了,但是B若发送数据,A仍要接收。也就是说,从B到A这个方向的连接并未关闭。这个状态可能会持续一些时间

A收到来自B的确认后,就进入了FIN-WAIT-2(终止等待2),等待B发出的连接释放报文段。

若B已经没有要向A发送的数据,其应用程序就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假设B的序号是w(在半关闭状态B有可能发送了一些数据)。B还必须重复上次已发送过的确认号ack=u+1。这时B就进入LAST-ACK(最后确认状态),等待A的确认。

A在收到B的连接释放报文后段后,必须对此发出确认。在确认报文段中把ACK置1,确认号ack=w+1,而自己的序号是seq=u+1(根据TCP标准,前面发送过的FIN报文段要消耗一个序号)。然后进入TIME-WAIT(时间等待状态)。请注意新增的TCP连接还没有释放掉。必须经过时间等待计数器设置的时间2MSL后,A才进入CLOSED状态。时间MSL叫做最长报文段寿命,RFC793建议设为2分钟。但这完全是从工程上考虑,对于现在的网络,MSL=2分钟可能太长了。因此TCP允许不同的实现可根据具体情况使用最小的MSL值。因此从A进入TIME-WAIT状态后,要经过4分钟才能进入到CLOSED的状态,才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后,就结束了这次TCP连接。

B只要接收到了A发出的确认,就进入CLOSED状态。同样,B在撤销相应的传输控制块TCB后,就结束了这次TCP连接。我们注意到,B结束TCP连接的时间要比A早一些。

上述连接释放是四次握手,但也可以看作是两个两次握手。

2.2.2 存在大量 close-wait的原因

CLOSE-WAIT的状态是B已经知道A不在向B发送数据,因此B在合适的时间段内可以让其应用程序通知TCP释放连接。那现在的问题是B的应用程序为什么迟迟不通知TCP释放连接,是应用程序挂了,还是应用程序的资源达到临界值,不能够做出 通知TCP释放连接这个操作。回想到刚才提到了系统资源不可用,会不会是因为B的应用程序想通知TCP释放连接,但是由于没有系统资源,而无法执行这个操作。

我们查看了服务器的应用部署情况,发现该服务器部署很多应用,每个应用响应tcp请求的线程池都是100+,在业务高峰期,很有可能达到最大用户进程数1024,从而引发这一系列的问题。

应用

应用测设置的响应tcp请求的线程池都是100+,并且当时服务器部署应用很多。

解决方案

  • 增大系统用户进程数限制
  • 迁移部分不重要的应用到其他服务器,降低服务器压力

思考

  1. 为什么之前没有暴漏出来。业务高峰期,为什么会将系统资源吃满。实际的系统吞吐量和tps是多少。是不是我们业务处理能力较之前有降低。
  2. 质量监控体系中缺少压测环节。

后记

随着5g的普及,网络的速度得到巨大的提升,掌握网络知识已经是必不可少的技能之一。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,607评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,239评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,960评论 0 355
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,750评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,764评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,604评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,347评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,253评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,702评论 1 315
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,893评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,015评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,734评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,352评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,934评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,052评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,216评论 3 371
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,969评论 2 355

推荐阅读更多精彩内容