首页 > 运维 > 记一次网站紧急维护过程

记一次网站紧急维护过程

2008年2月25日

学院自己设计的选课系统,今年初次启用,用于一个年级约150人的同时选课。选课开始之后很快网站便失去响应。重启服务器之后重新开启选课系统,但是又迅速停止服务。于是选课宣布推迟。

 


二次选课安排在某日下午。于第二次选课前一天接手站点维护,对站点的结构和程序性能进行分析。该站点由两台服务器分别负责数据库和Web服务。采用10个
并发用户模拟选课过程时,210个事务操作需要10分钟左右。期间Web服务器基本没有负载,而数据库服务器CPU满载。站点数据表尺寸在1M的级别,程
序代码中仅有一次锁表操作,但是有若干处在循环中查询数据库。因此推测性能问题是由于对数据库访问次数过多而导致的。

 

开启
数据库的日志并访问课程列表页面,发现仅此一个页面就有200余次数据库查询操作。对课程列表页面进行压力测试发现,数据库服务器每秒可处理近800次查
询请求。而一次完整的选课过程则会导致900余次数据库查询。这说明程序结构存在着严重的问题,因此对程序进行重构,消除循环中对于数据库的访问。共将三
处循环中对于数据库的访问改为存储过程,另外修改了一些查询语句。同时对数据表项目进行了小的调整,添加了几个表项作为缓存,消除了几处多余查询和重复查
询。撤销了两个被频繁调用的且结果稳定的函数中对于数据库的调用,将部分结果暂时硬编码至程序中。另有一处被频繁调用的函数因程序结构原因无法进行快速重
构,故而放弃对其的修改。经过上述重构,显示课程列表页面所需的访问数据库次数降低至20次左右,同时由于数据库和程序客户端的问题增加了三次额外的数据
库连接操作。应当说这个数据库访问次数仍是偏多的,但是与原先的情况相比有了明显的改进,同时由于程序结构的限制,在短时间内无法进行进一步的优化,因此
对程序的优化到此为止告一段落。整个重构过程耗时约12小时。在程序重构的同时,根据网站页面的功能对于部分网页暂时采取了转为静态页面和不显示的方法以
降低重构的工作量。优化结束后对课程列表页面进行压力测试,10个客户端连续刷新时Web服务器的CPU占用在40%左右,而数据库服务器的CPU占用在
30%附近。

 

程序重构结束之后,对数据库以及两台服务器的操作系统继续进行优化。根据程序中的查询语句为数据库增添了一些
索引,从而使得10个客户端连续刷新课程列表页面时数据库服务器的CPU占用降低至10%以下。此时Web服务器的CPU占用相对较高,同时使用压力测试
软件进行测试时响应时间有明显的周期性分布。检查Web服务器的网络连接情况,发现Web服务器端访问数据库的网络连接在程序结束之后没有及时关闭,猜测
这可能导致网络连接数过多,从而导致响应时间周期性的分布。因此调整Web服务器的部分网络参数以消除此现象。另外为Web服务器安装了程序脚本的预编译
模块以避免重复的脚本编译操作。经过这些优化之后,25个客户端连续刷新课程列表页面时Web服务器的CPU占用降低至20%以下,数据库服务器的CPU
占用在15%左右。

 

分析维护前后系统的性能,对于程序的重构使响应速度提高了近10倍;添加新的数据库索引以及Web程序脚本预编译又各自使得Web服务器和数据库服务器的响应速度翻倍。因此总的来看,维护之后站点的性能提高了近20倍。

 


日上午对于网站的内容以及程序逻辑进行进一步的检查,更正了几处数据和逻辑错误。下午选课时,网站负载在选课开始3分钟后达到峰值。Web服务器的峰值
CPU占用在15%,而数据库服务器的峰值CPU占用在10%。选课开始10分钟后两服务器已没有明显负载。根据数据库内容的监测,此时大部分学生的选课
已基本结束。

运维 , ,

  1. 目前还没有任何评论.
  1. 目前还没有任何 trackbacks 和 pingbacks.