CPU使用率终于正常了——记一次订餐系统事故处理

引子

　　 通过漫长的等待，儿子终于出生了。欣喜之余，就是各类手足无措，顾此失彼了。由于不懂，内心老是慌慌的，有点小毛病，巴不得一步就到医院。

　　 婆媳育儿观念的差别，让心乱如麻的我，又成了风箱里的老鼠，两个不服软的女人都在考验个人智慧，虽是极力从中斡旋，仍是免不了爆发了一场婆媳冲突。

　　 仍是智慧少了，估计四大名著还得再读一遍（唬一下人应该仍是能够的:-D）。

　　 不过话说回来了，虽然苦点，累点（固然了，主要仍是媳妇和妈累，媳妇放弃工做，放弃辣椒，放弃方便面，也蛮拼了，我也就打打酱油），但抱着娃，看他那惹人爱的脸，时不是还会 喔喔冲你回应，偶尔还会咧嘴微笑...,啥苦，累，烦劳统统都没有了。

　　 至今已两月有余，总算是平稳了，各个操做都熟练了，婆媳有了她们的相处模式，也亏得二位都是深明大义的人，虽也要不时开解，矛盾常有，冲突不在。也蛮好了。

　　 啰嗦了两句，咱言归正传--记录一次订单系统CPU使用率太高处理。

 

　　 ——————————开场完毕，回归主题——————————

 

事故回放

　　当时的状况是那个样子的：

　　1，正值饭点，客户电话说系统慢，几乎没法完成订单调度，有时还显示内存不足。当时内心的第一个声音就是，服务器配置过低了，远程一看，2核4G内存，cpu平均60%以上，内存70%以上，果真是配置低了，word哥厉害了，

不用看就知道了，果断让用户增长了配置，嘿，你别说增长了配置果真，快了很多，立竿见影，钱还真是万能。而后，欣欣然吃饭去了。

　　2，过了半月，又值饭点，客户电话又说最近系统慢，再让客户增长配置吧，也不合适，为了不打脸，我又盲目的临时增长了服务器带宽，可是然并卵。我已经知道我必需要为本身当初的草率还债了。

      这些年，只知埋头写程序，这方面的东西几乎没有积累。然已经兵临城下，会不会都得上，即便前路是如一重山，两重山，山高天远仍是山。 　　

　　　

确认带宽

　　咱们打开一个网站慢，咱们首先想到的是服务器带宽问题，可是如何确认服务器的带宽是否足够呢，我学到了两个方法：看阿里云网络监控，看服务器联网状况。原本是两个每天看到的东西，愣是今天才明白，都很差意思是说本身是计算机专业毕业的了。懂的就飘过，权当我作个笔记吧，有错的欢迎斧正，不能误了别人哩。

　　  1，如下是阿里云网络监控数据图，服务器使用 5Mbps 带宽，说明咱们的出网理论能够达到 5*1024kbps，服务器出网峰值4700多，说明够用。

　　

        2，也有说这个数据不是特别准确，咱们也能够登陆服务器远程查看联网信息，下图网络使用大概等于 0.05%*1Gbps ≈ 500kbps;

 

　　　　

　　   

　　观察了两边的数据，我肯定了带宽基本够用的，再不用本身去临时升级带宽了，知识比钱还万能，解决问题还能省钱。~~^_^~~~

　　

搞定内存

　　内存从的来的4G，升级到8G，仍是会提示内存不足，你说一天就2000多个子订单，再让别人加配置，怎么好意思呢。监控进程，发现w3wp.exe,sqlserver.exe 点的内存多，且在不断增长，直到最后程序提示内存不足时，依然还在吃内存。

　　w3wp.exe 是iis的进程，一个站点会生成一个进程，也许是程序中有bug，致使内存不断增长，可是要去发现他，真不是简单的事儿。那这个进程还能没法无天了么，固然，不是！。应用程序池能够设置内存限制，这就是他的天了。以下图。

　　

 

　　sqlserver.exe 是数据库有进程，这不是费话么，看名称就知道了。他也会一直吃内存，吃到没有为止（话说他本身不把本身吃了呢），程序当然有问题，不知道他本身有没有bug呢，无论了，给他划一片天，让他插翅难飞。

固然了，这终非治标之事，权宜之计了。

　　

　　内存就暂时这样处理了，近期不影响使用了，要治标仍是得好好查代码哩。上面的都是简单设置就Ok了，接下来才是重头戏。

降温CPU

　　CPU常年在60%以上，常常还会飚到80%多，服务器本身都照顾不过来了，怎么还有心情响应别人呢。因此嘛，就慢了。（这么简单的道理，怎么如今才想明白呢。）再细看，占CPU的全是 sqlserver.exe，好吧，哪哪都少不了你的，十处打鼓，九回在。不过话又说回来， sqlserver.exe成了泼妇骂街，哪哪在，还不是大家这个帮程序员逼的么。 好吧，大哥莫说二哥，脸上麻子同样多，咱仍是来相互理解吧。先上一张优化前的CPU使用率状况图，完事儿再上一个优化后的图，放一块儿怕是有了对比，就有了伤害。看了下图，真是惨不忍睹，平均估计得有60好几吧。

　　

 　　sqlserver.exe 常常占很高CPU，确定不是一处两处的问题，因此确定不是如大海捞针通常在代码里找了，好吧，你们都知道是 数据库引擎优化顾问，具体使用就不说了吧。直接优化建议，按里建立索引之类的，这也太简单了吧，确实简单，由于也没有太大的效果。

　　因而，继续看查看报告一栏，毕竟这里是真实的数据统计，每一个报告都略微看了下，当看到表报告时，word哥，当时真傻眼了，管理员表竟然成了引用数最多的表，这太不能接受了。真是不看不知道，一看笑一笑。笑啥呢，找到部分问题了还不让笑了么，哈哈哈。原来页面中几乎都会用到当前登陆用户的信息，但每次又都是根据cookie中的id去查数据库，我说呢，果断缓存登陆的帐号信息（这多年了，仍是这么陈旧的方式，还望有园友能够指点一二）。

　　

 

　　通过上一步后，CPU由原来常年飚高，变成常常升高，检查访问频率高的界面，结合优化报告，发现查询条件  DATEDIFF(day,OrderDateTime,GETDATE()) =0 很是可疑，这个字段本已经添加了到了非汇集索引里，但这样写后，执行计划变得

很是复杂，若是我修改为  OrderDateTime > '2016-10-26' 执行计划就简单多了。几个高频页面计划都是这样写的，之前以为这样写很是牛，还为常常记不住函数写法而懊恼，没文化真可怕。

　　再把优化报告，详情看了后，完成了一系列优化，主要也是就索引，sql语句写法等。索引吧，我是每天嚷嚷着学习，可是总是只知皮毛，悲伤中。

　　把上面优化部署后，仍是会偶尔忽然升高CPU，猜多是某个不是特别高频率的界面引发的，最后猜多是后台首页，有一些统计信息。果不其然，我每刷新一次，CPU就升高了，这些统计又不能没有，怎么办呢，对了，仍是缓存，这些数据也没有必要实时统计。以下图。到这里CPU终于降温了。

　　

　　好吧，完事儿了，好吧，还少一张优化后的使用率，安静多了吧。

　　

　　

结语

　　以上就是此次优化的大概过程了（个中心酸，着实也很多），网站是个小网站（，好吧，大网站也轮不到我哩），啥都在一个服务器上，也许这些个三脚猫的东西入不了不少人的法眼哩。不过，对我来讲仍是一次满可贵的经历了。

我相信我就是我，必定能火。若是能对你有帮助，十分荣幸，方便的话点个赞呗，让我也高兴下；写得不对，你能吐个槽，我也十分荣幸，若是能再指点一二，那就万分感激了。

　　最后，媳妇但愿把儿子的名字，写在博客里，未来他要是搜索本身的名字（别说你没干过这事儿哦），能看到这篇博客，那也是美事儿一件了。

　　好吧，当妈首先仍是想到的本身的娃；其实媳妇从怀孕开始，为了娃，管住了嘴，迈开了腿；爬楼梯，转公园，只为能顺产，有利于娃（虽然说最后也没能顺产，付出也是蛮多）；生了娃，事就更多了。这就是养儿方知父母恩了。好吧，打住了，再说下次去就是秀恩爱了。儿子名叫：戢雨泽，媳妇取的，但愿未来程序比我写得好。

 

　　 成为一名优秀的程序员！