背景介绍:
2017年9月,公司安排我们研发部搞一个中秋礼品抢购的功能,参与抢购的同事六七千名,我通知其他同事要搞下压力测试,然而功能急急忙忙上线,埋下了宕机的隐患,这是一次血的教训,当然也是一次宝贵的经验。
整个过程:
早上7点,起床打开手机,企业微信就有同事发来消息说网站访问缓慢,我并未在意,觉得是同事的网络有问题;
早上8点多在公交上,突然发现群里反馈信息的人越来越多,我赶紧打开手机,网站已经没了响应,直接报错,我打开电脑,连上手机4g,发现已经连不上阿里云服务器,服务器已经宕机或者过载状态中。(抢购活动9点才开始,同事在上班路上纷纷打开手机访问抢购页面,服务器被挤爆宕机,fpm-php线程数设置的是动态加载,已连接的线程未释放,cpu负载过高,总结应该是这个问题)
早上9点多到了公司后,抢购时间已经开始了,页面又打不开,集体领导各种电话打到办公室催促,运维同事重启了阿里云,然而重启过后一会,网站又立刻变卡,php线程数又暴增,运维只能不停的重启fpm-php与mysql
早上9点半多重启fpm-php一会,页面就会报memcache连接数过多的问题,赶紧让运维将memcache连接数设置到2000(实际上来说是有慢查询,memcache连接不能及时释放),然后设置到2000后,memcahche的问题没有再报,但访问还是异常卡
早上快10点时,通过mysql慢日志与p