微服务性能优化-日志调优

A进程是提供接口给手机客户端调用,B进程是刚上的服务,A进程调用B进程的超时时间设置为3秒,超过3秒就报错,上报到监控系统。上线后收到短信告警,超时的请求量较多。查看监控图如下


纵座标的顶部是3秒,每隔一小时就有一个高峰达到3秒。刚开始怀疑B进程有定时任务在跑,查看代码后发现没有,最后查到运维人员在系统中跑定时任务,每小时检查log目录下的文件是否大于500M,是的话就切割文件压缩。文件的时间与监控图的超时时间一致。


怀疑是在操作系统定时任务切割日志文件的时候,与业务进程抢压日志文件资源,阻塞了业务进程IO。


由于B进程是个重要服务,开发人员为了方便定位问题,把每次的请求和返回数据都打开出来,请求量也较大,导致每小时内都达到500M。

做了以下优化:

1. 减少日志量,只记录关键信息到日志文件

2. 修改log4j配置

log4j.additivity.monitorLogger=false
设置监控logger的日志不会输出到rootlogger
log4j.appender.monitorAppender.BufferedIO=true
log4j.appender.monitorAppender.BufferSize=8192
设置log4j输出日志的时候采用缓冲的方式,而不是即时flush方式,并且设定了缓冲为8K,可以根据日志输出的情况来修改,不即时写入文件可以减少与定时任务冲突的概率。

 

log4j有个AsyncAppender选项可以设置为异步输出日志,这里不改为异步的原因,是因为B进程已经有100个线程,且并发量较大,在网上看到异步不移定。

优化完后,系统稳定,很少再收到告警短信,终于睡个好觉。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值