怎么宣传自己的网站推广,网站默认主页设置,seo友情链接是什么,福建网站优化前言一个项目上线了两个月#xff0c;除了一些反馈的优化和小Bug之外#xff0c;项目一切顺利#xff1b;前期是属于推广阶段#xff0c;可能使用人员没那么多#xff0c;当然对于项目部署肯定提前想到并发量了#xff0c;所以早就把集群安排上#xff0c;而且还在测试环… 前言一个项目上线了两个月除了一些反馈的优化和小Bug之外项目一切顺利前期是属于推广阶段可能使用人员没那么多当然对于项目部署肯定提前想到并发量了所以早就把集群安排上而且还在测试环境搞了一下压测绝对是没得问题的但是就在两个月后的一天系统突然跑的比乌龟还慢投诉开始就陆续反馈过来了。经过排查原来是频繁执行一条耗时100ms的SQL导致100ms感觉不长但就是把系统搞崩了具体细节如下。正文1. 项目概况项目采用ABP进行开发集成统一的认证中心(IDS4)部分数据对接第三方系统拆分后的这个项目架构相对简单。考虑并发量不高就算是高峰期也不会超过1000于是就搞了个单台的数据库服务器(MySQL)测试环境中经过压测完全能抗住。上线时由于线上资源的关系DB服务器的配置没有按测试环境的标准来分配相关人员想着后续看情况进行补配。上线推的比较紧简单评估了配置风险初步判断没啥大问题于是就推上线了。相关技术栈ABP、IdentityServer4、Autofac、AutoMapper、Quartz.NET、EF Core、Redis、MySQL等这都不重要重要的是100ms的SQL把系统搞崩了。由于系统相对不大并没有把分布式日志、调度监控性能监控集成上去。2. 问题排查上线期间前期处于使用推广阶段一切正常。两个月后的一天系统处于使用高峰时段突然陆续收到反馈系统有点卡于是赶紧进行排查。由于系统已经是集群部署的慢这个问题首先怀疑是数据库服务器于是让DBA的同事排查了一下没有锁只是有大量事务等待提交(waiting for handler commit)通过如下命令可查的# 查看正在执行的脚本select * from information_schema.PROCESSLIST t where t.COMMAND ! Sleep order by time desc;看到结果都是插入审计日志记录导致一看日志记录频率差不多一秒500条记录。DBA同事说可能是记录插入频繁导致此时CPU已经爆到100%了为了快速解决问题于是就赶紧关掉了一些不必要的日志记录。这么一改稍微降了一点没有事务提交的记录系统勉强可以撑着用但是CPU还是在85%~97%波动看到这种情况当然还是不放心继续排查。中间有对服务器的配置产生过怀疑但非常肯定的是这不是主要原因于是和DBA的同事继续排查。系统虽然可以正常使用但时不时的也看看监控屏CPU一直处于高水位状态还是有点慌的因为一有问题信息和电话都要爆。突然DBA同事发现有一个单表查询的SQL执行比较频繁于是单独拿出来试了一下查询时间150ms左右这个表的数据量不大8万左右但没有加任何索引因为想着数据量不大查询时长还可接受所以当时就没有加相关索引。定位到这条SQL后想到的第一步就是增加索引在测试环境上试了一把执行效率直接飞速提高到1ms效果如下所以和DBA同事达成一致意见在生成环境上增加复合索引(创建索引一定要注意字段顺序)在中午时候系统使用频率不太高于是就在生成上快速加了索引我去CPU一下降到了20%以内意不意外就算在使用高峰期也没超过20%通过zabbix工具监控看到CPU的效果问题算是解决了总算松了一口气。这里有个问题CPU都爆了为什么没有报警提醒这块DBA同事正在排查相关配置。这里发现CPU爆了还是无意的远程到服务器发现很卡一看CPU才知道爆了。系统虽小问题不大但其实暴露的问题还是挺多。总结这次线上小事故暂时分享到这因为项目不大所以没有做那么多监控但以下建议小伙伴可以参考一下频繁执行的SQL语句一定要保证其执行效率不要小看ms级的优化如果并发量上来也会是灾难对应服务器要做好监控指定预警范围提醒避免打个措手不及尽量避免频繁的自动刷新引入实时通信的方式会减少不必要的访问压力。关于系统频繁记录的审计日志尽量不要和业务数据库存放在一起大量的日志频繁操作数据库是很占用IO的。对于拆分的项目再加上集群部署分布式日志管理必须安排上不然分析日志排查问题是个费时费脑的事关注“Code综艺圈”和我一起学习吧。
