做网站的代码难吗,数字化营销,wordpress自定义页面跳转,免费申请手机网站最近接连听说一台线上服务器总是不响应客户端请求。 登录服务器后查询iis状态#xff0c;发现应用程序池状态变为已停止。 按经验想#xff0c;重启后应该就ok#xff0c;第一次遇到也确实起了作用#xff0c;当时完全没在意#xff0c;以为是其他人无意把服务关闭了而已。…最近接连听说一台线上服务器总是不响应客户端请求。 登录服务器后查询iis状态发现应用程序池状态变为已停止。 按经验想重启后应该就ok第一次遇到也确实起了作用当时完全没在意以为是其他人无意把服务关闭了而已。 但是之后几天几乎每天都出现问题应用程序池再次成为 已停止 状态。这个情况显然有问题。于是开始排查设置。 线上环境很简单iis API应用数据库在内网上没有反向代理。 出问题的应用程序池承载了一个基础数据API查询量极小数据量也极小只是因为同事做实现时提过查询很麻烦所以我让他同时也检查代码的查询是否过于繁琐产生超出设置上限的资源占用。 但根据同事检查结果这个情况不存在数据库查询响应非常快服务器的资源监控上看相关进程也没有出现明显的资源飙升。因此判断服务端代码应该没有问题。 经验路线在这里就走不通了只能尝试在设置上找原因。 iis对应用程序池的设置里最可能影响服务的是回收策略的设置。为了避免影响其他服务部署时设置了这个api的专用内存上限到1GB。当然既然代码检查没有问题测试运行也没发现资源飙升的情况回收的专用内存上限应该不会轻易触发。但是还是检查了设置毕竟从前有同事设置时把1GB给成了100M除了登录之外执行不了任何请求。 最终想到用netstat检查端口情况。起初的怀疑是端口被其他进程无意占用导致问题。 启动netstat后让测试发了几次请求顺利看到进程出现在列表且没有端口冲突对端地址经查证是来自app。当然也注意到服务器状态是一堆 Close_Wait. 当然我经验少Close_Wait还真是第一次见。不过既然状态不是Established这个应该就是问题的原因了。开始查资料学习Close_Wait状态是什么情况。 对于 服务器的连接状态而言一般有三种比较常见的 Established、 Time_Wait、Close_Wait。 从别人博客上扒了一张原理图 通过原理图我们知道了CLOSE_WAIT是被动关闭的状态。什么意思呢比如客户端发了个请求正常情况下是会收到服务器响应一个状态的即Response。当客户端读取了这个返回后会主动告诉服务器收到了关闭连接。 由于是客户端发起关闭连接的请求在TCP协议下双方需要通过四个包的互发完成双向确认工作才能最终关闭这个连接。 客户端要求关闭此时客户端状态为 FIN_WAIT_1同时向服务器发送了 FIN 包服务器状态变更为CLOSE_WAIT 当然服务器需要对收到FIN包向客户端确认于是服务器向客户端发送了 ACK 包客户端因此变更状态为FIN_WAIT_2 服务器处理了这个确认后再次主动向客户端发送FIN包同时自己状态变更为LAST_ACK收到来自服务器FIN包的客户端也将自己状态变更为TIME_WAIT 最后一步客户端会对来自服务器的FIN包回复确认服务器收到该ACK包后将自己状态置为CLOSED如此整个关闭过程结束。 简单说就是客户端 -》 服务器我要关闭服务器回复OK并开始处理后续服务器后续处理好后再告诉客户端我可以关闭了客户端确认服务端关闭。 所以出现CLOSE_WAIT状态的原因是服务器一端因故没有向客户端发出FIN包即服务端的LAST_ACK -- FIN --客户端这步没能执行。 因此看到CLOSE_WAIT状态后那么可以确定服务器没有执行后续动作即调用socket.Close()。 举一反三即谁被动关闭则谁的连接释放代码有问题。 但是socket.Close()的调用应当是由web服务器自己完成呀所以问题还没确定。写api的同事轻描淡写提了一下说代码没关闭链接但越想越不对。到底什么原因导致没有进行socket.Close(),还需要具体从代码入手。 不过虽然没有真正搞明白我们遇到的原因但是原理清楚了排查的时候还顺手看到客户端的代码存在的问题。后续搞清楚了再更。 【1212更新】 终于有空来继续查这个问题了。 前次排查的时候在没有完全理顺这个原理的情况下认为是客户端Android上一段关于登陆请求的超时处理问题。我是被几篇HttpClient的文章干扰了。在那几篇文章里作者说是因为调用HttpClient组件后没有对请求资源进行释放即Response.Body.Dispose(),因此造成了CLOSE_WAIT状态。 但作者没说清楚。就像前文分析的一样服务端出现CLOSE_WAIT根本问题一定是服务端的代码有问题。当然既然排故就顺便一说。在同事的请求部分代码上设置了Timeout时间并且做了不太安全的异常处理 1 ...
2 Response res client.newCall(request).execute();
3 if(res.isSuccessful()){
4 return res.body().string();
5 }
6 else{
7 throw new IOException(Unexpected code res);
8 }
9 ... 并且这段代码在一组try catch 内部且仅catch了IOException 【我没细看OKClient的文档不清楚是否有其他的Ex可能性】 这段代码的问题在于一定要使用try catch进行流程控制并不合理。此外response会带有服务端返回的标准Http 状态因此此处对非200状态的处理过于粗糙浪费性能。 所以在服务端出现大量CLOSE_WAIT后这里应该收到大量的500状态非200只需要正常输出信息并做相应操作即可。 【像Try catch这样的代码更好的使用方式是用于做应对不可预料的错误而不是逻辑分支控制。大多数的错误应当由正常的检验代码进行处理。】 但是这部分代码最多给客户端造成问题不会导致服务端出错。 因此我们转回看服务端问题。 因为出问题的只有Login操作于是在清楚问题的原理后同事为Login操作加上了超时的判定。所以我的余下分析只能在修改后的代码上进行。 public void TLogin(string username, string pwd,out string resultJson){using (RtuHmiEntities db new RtuHmiEntities()){var user db.Base_Users.Where(x x.UserCode username x.Password pwd).ToList();if (user.Count() 0){resultJson user.ToJSON();return;}var siteList db.SiteTable.Select(x new { ID x.Id, Name x.SiteName }).ToList();var dtuList db.DtuTable.Where(x x.SiteId null).Select(x new { ID x.ID, Name x.DtuName }).ToList();var regularboxList db.PressBoxTable.Select(x new { ID x.Id, Name x.BoxName }).ToList();var valveList db.ValveChamber.Select(x new { ID x.Id, Name x.Name }).ToList();var result new{Stations siteList,BusinessUsers dtuList,Regularboxes regularboxList,Valverooms valveList};resultJson result.ToJSON(); }} 当然仔细看了登陆操作的业务代码后我们能发现一些问题。在这个项目上登陆后需要初始化一些列表类的信息给客户端。这里的操作当然没什么问题。因为同事在参与这个项目时不止一次向我抱怨数据库设计有问题查询很繁琐。但是我没有在这个项目上所以没有具体关注数据库设计的缺陷。 不过从这段代码看前端需要接受4组信息分别是 Stations、 BusinessUsers、 RegularBoxes、 Valverooms数据库给了四张表。这里采用Linq进行查询操作。一般说来问题不大。实际上这段代码里查表的部分实际的执行也没有任何明显性能不足的情况。硬挑的话第一个分支里对空集合转Json反倒会产生不必要的损失。即便如此在正常情况下请求执行时间在200ms以内。 既然代码在测试下并没有什么问题那原因在哪呢 回想了一下IIS有一项设置是回收策略的。因为原先遇到过因为回收没有自己定义几个旧版的很占资源的API还没更新的时候就在回收周期内把服务器资源吃满了导致其他api无法运行。所以后来会根据测试时的资源情况为线上服务器设置这个回收值。当然对于一个不怎么复杂的查询类API而言并不需要多大的资源。于是第一次设置计划给200M的专用内存。不过显然因为某一两个数据量比较大的API在短时内重复请求造成了回收此时登陆测试碰巧遭遇了释放于是就造成了上述 服务端被动关闭连接且没有继续向客户端返回FIN包的状态最终产生了几条CLOSE_WAIT。 回想一下大家遇到的CLOSE_WAIT基本上都是大量出现而我们遇到的情况只有少量的几条远没达到客户端测试的请求数量。排查下来看也确实是调试的时候遇到的小概率问题。不过不清楚原理的话排查起来还是很没头绪的。论理论的必要性。在大多数时候不需要那么精通理论能做到80分但是想做到99分甚至更高就是拼对理论的理解深度了。 【Finally解决方案】 实际上我们为这个问题修正了三个地方。 第一是对客户端代码上做了修改改进非200请求的反馈方式。 第二是将iis的回收策略修改提高了专用内存的上限降低回收时间间隔【看来从实际出发这样做更有效】 第三依然对服务端代码进行了修改对部分请求增加了超时的处理至于发现的不太利于性能的代码也会在重构时改进。 当然对这个问题贡献比较大的是前两条。毕竟出现的主要情况还是服务端被动关闭。 这个问题我当然还没研究的太深。如果有错误请务必指出。 相关资料 http://blog.csdn.net/shootyou/article/details/6622226 http://mp.weixin.qq.com/s?__bizMzI4MjA4ODU0Ngmid402163560idx1sn5269044286ce1d142cca1b5fed3efab13rdMzA3MDU4NTYzMwscene6#rd 感谢以上优秀的技术文章。转载于:https://www.cnblogs.com/DannielZhang/p/8000496.html
