|
|
1.描述一下服务器配置:
一台2c4g的centos,做api接口反代
一台8c16g的windows 2019 作为实际服务器,跑了iis,sql server,mongodb,redis
2.业务描述
2.0 服务器分为两个站点:importapi:用于处理数据导入,,,webapi:用于处理对用户端的数据查询
2.1 从数据源采集数据后,经过一系列的操作之后,写入sql和mongodb,部分基础信息会缓存在redis中,根据数据量的大小,从处理到写入的整个流程时间在60ms-1200ms之间,平均每秒服务器需要处理到2-3条数据,同一类型的数据使用队列处理,避免并发写入导致数据回跳或者出现脏数据的问题.
2.2 用户web端,每秒定时通过接口读取数据,并显示界面上
3.使用到技术/类库
Asp.net core 8,easycaching,freesql,redis
4.问题表现
当天晚上10点过后,突然mongodb,sqlserver和对外的webapi接口站点的进程突然cpu占用率暴涨,mongodb平均60-80%.webapi占用20%,sqlserver占用10%,内存占用了50%,,且远程桌面操作不卡,webapi数据接口处理时间跟平时一样200ms左右,但是数据不及时,通过日志检查的到,importapi站点原本处理时间上涨到6s-12s直接,导致了数据处理不及时,处理队列积压严重,从而导致了数据更新不及时.并且webapi接口项目不定时报"The wait queue for acquiring a connection to server 127.0.0.1:xxx is full".错误.从理论上说,我们的站点是小众站点,业内人士使用,并不会出现突然涌进几十倍的用户的情况出现的
5.解决方式以及思路
从表现上看,是mongodb的压力突然暴涨,导致写入变慢,但是压力来源是哪里,由于还没安装监控面板,所以也没办法查看,因此只能按业务反向的思路去解决,总的解决用了一下几个点
5.1 从导入的业务流程入手,尽量优化写入以及数据分析操作所需要用的时间(之前几天就想好的优化方案了,只是还没上而已)
5.2 关掉mongodb client 的 关掉WithWriteConcern
5.3 在webapi接口项目,action上加入加上ResponseCache,过期时间3秒,(这里的3秒主要是按业务上考虑的)
5.4 关掉反代nginx的日志(减少点压力,本来反代的服务器性能就没多高)
5.5 nginx开限流,10r/s/ip burst=20
5.6 准备一把刀(作用看后面)
以上处理后,importapi导入的时间降低到30ms-700ms,并且webapi输出时间降低到50-300ms(缓存内50ms,缓存外300ms),mongodb的cpu占用降低到10%内,webapi占用5%下,,
6.最终原因分析
说起来,,问题其实很简单,本来是只有一个前端站点把数据接口指向过来服务器的,,前两天迁移了另外一个站点,把数据接口也指向到这台接口服务器,意思就是两个web站点,使用同一套数据接口,,新接过来的站点,前端写完代码后,没检查,导致了一个致命的问题,由于前端使用vue,切换页面的时候调用了暂停每秒一次的定时器,然后进入详情页后,开了一个新的定时器,也是每秒取一次另外一个接口的数据,,最大的问题就出现在,进入详情页后,列表页的定时器调用关闭的函数报错了,,实际定时器是没关的,,这tm就吐血了,进去一次,开一个新的,后退到列表页又开一个新的,,来回10次,意味着加了20个每秒请求一次的的定时器,,直接自己ddos自己.至于这个问题怎么发现的,,,是解决完问题后,不死心,,去两个站点里翻找问题,本来以为这个问题在很久之前测试的时候出现过一次,应该不会再出现的,,,结果,,,,
7. 总结,,本次问题出现从晚上10点,一步一步优化,12点多1点的时候基本代码层面解决到1秒以内,,剩下的一些nginx的优化扫尾工作再花个不到一个钟头(开限流,关日志之类的操作),顺便帮前端的两个站点的centos服务器上,把nginx的静态文件gzip跟缓存功能也打开了,清理了一下写入到mongodb的日志,至于那把刀是今天准备给前端的
来源:https://www.cnblogs.com/kugar/p/18199022
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！ |
|
