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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

jijunjian 2016-10-27 08:53:00 浏览617
展开阅读全文

引子

   经过漫长的等待,儿子终于出生了。欣喜之余,就是各种手足无措,顾此失彼了。因为不懂,心里总是慌慌的,有点小毛病,恨不得一步就到医院。

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

   还是智慧少了,估计四大名著还得再读一遍(唬一下人应该还是可以的:-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终于降温了。

  

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

  

  

结语

  以上就是这次优化的大概过程了(个中心酸,着实也不少),网站是个小网站(,好吧,大网站也轮不到我哩),啥都在一个服务器上,也许这些个三脚猫的东西入不了很多人的法眼哩。不过,对我来说还是一次满难得的经历了。

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

  最后,媳妇希望把儿子的名字,写在博客里,将来他要是搜索自己的名字(别说你没干过这事儿哦),能看到这篇博客,那也是美事儿一件了。

  好吧,当妈首先还是想到的自己的娃;其实媳妇从怀孕开始,为了娃,管住了嘴,迈开了腿;爬楼梯,转公园,只为能顺产,有利于娃(虽说最后也没能顺产,付出也是蛮多);生了娃,事就更多了。这就是养儿方知父母恩了。好吧,打住了,再说下次去就是秀恩爱了。儿子名叫:戢雨泽,媳妇取的,希望将来程序比我写得好。

 

   成为一名优秀的程序员!

 

版权声明:
作者:J²
有事儿Q我
有事儿W我
编辑:妞妞
妞妞主页
出处:http://www.cnblogs.com/jijunjian/
本文版权归作者和博客园共有,欢迎转载,大家好,才是真的好!
 

网友评论

登录后评论
0/500
评论
jijunjian
+ 关注