线上又炸了

上一次记录线上问题还是在2018年【问题记录】,最近线上日活突破巅峰,又炸了。记录下。


 

线上几天连续活动,活动基本的刺激用户都上线操作某个业务。通过广告,内部通知,App全量推送等方式激活。

晚上7.30左右就开始告警。到8.00其实已经很多用户在排队。2G的带宽直接塞满,mysql,redis,memcache,各个.net core项目相继也出现异常。

前期没有做好充足的准备,其实应该在晚上7点左右就应该重视。告警都没有重视,得过且过。

后面的应对方案:

1.cdn
2.索引碎片优化重组,慢查询日志查看
3.dump内存cpu分析
4.内部带宽优化 部分redis memcache缓存移动到进程内存
5.弹机器
6.运维memcache集群不集中到一台物理机器,进行迁移。增加内部带宽优化

 

cdn:

     kibana上面nginx的日志分析接口的访问量,看到有大量的静态资源没有走cdn,马上改掉。其次有意思的发现钉钉访问我们图片资源的时候会带上参数(钉钉自己的cid等参数),直接导致就算访问cdn服务器资源地址,cdn也会来我们自己的项目索要资源,后续cdn脚本忽略了请求后面的url参数

sqlserver,mysql:

     sqlserver看到有部分表的索引碎片达到10%以上,甚至90%。且表里面的数据量十分庞大。立马索引碎片优化。mysql慢查询日志开启,检查sql是否有根据索引进行查询。其次还发现有一句sql对索引字段进行频繁的删除修改(是一个定时的回收任务),后面直接改了表结构解决

dump:

     线上cpu满,内存也满。直接dump看。用的是dotnet-dump【以前的记录

     首先是cpu满了问题,dump 分析线程堆栈信息,发现是因为用了lazy去延迟获取一个资源对象,用的是LazyThreadSafetyModel,即当一个线程已经在拿的时候,其他线程等着。在并发很高的情况下,直接卡死(项目在并发很高的情况下重启了)。后面直接改成单例对象。

 

 

 

     其次是内存问题,发现有大面积的Microsoft.Win32.SafeHanfles.SafeCryptKeyHandle对象。发现是应为我们在使用.net core加解密对象的时候,没有去dispose,也就是每次都是new一下,而且解密异常的时候直接return string.empty。。。。23333。  后面直接加了using解决

 

 

 

 

 

 部分redis memcache缓存移动到进程内存

     线上看到外部带宽塞满,其实内部带宽也满了。 直接导致运维都无法操作。想上个跳板机看一下都难。在grafana看到。redis和memcache占用的很高。原因:我们一开始的思想就是一些相对固定不变的接口返回值都放到redis(例如固定的字符串(角色广告,动态导航路由))。但是这些资源都很大,访问频繁,用户量大高并发下,直接给你撑满带宽。后面部分这种资源用进程缓存去处理了,一开始用自己写的ConcurrentDictionary,发现没这么简单(不仅仅是线程安全,还有回收,面向接口等思想)后面直接用了ASP.NET Core IMemoryCache对象。MemoryCache源码地址,源码里面感觉有点不好就是每次查询都去回收,后续可能改成IhostService去起一个线程定时回收。

     其实这点 有好处也有坏处。 也不建议以后啥都往进程内存放,放多了也不好

 

总结就到这把。希望下次可以不用再写了

 

posted @ 2021-04-23 11:13  TeemoHQ  阅读(14)  评论(0编辑  收藏