因打印日志而引发的故障
程序员文章站
2022-03-20 13:09:08
问题描述: 最近已经有两个项目因为日志打印问题而引发了故障,可以说是血的教训了。两次故障的原因也是非常的相似,都是由于其他业务系统调用了另外一个老系统的接口,但是由于传递的参数不正确,而老系统会因为参数不正确而打印日志。当错误的请求量增大,打印日志会造成当前线程阻塞,容易使机器机器负载升高,产生性能 ......
问题描述:
最近已经有两个项目因为日志打印问题而引发了故障,可以说是血的教训了。两次故障的原因也是非常的相似,都是由于其他业务系统调用了另外一个老系统的接口,但是由于传递的参数不正确,而老系统会因为参数不正确而打印日志。当错误的请求量增大,打印日志会造成当前线程阻塞,容易使机器机器负载升高,产生性能问题
排查方法:
1. 直接查看机器上日志大小
2. 还可以通过jstack查看 占用cpu最多的线程,多查看几次,如果每次都是打印日志的线程,那基本上也可以确定是打印日志的问题
解决方案:
1. 提前校验参数,如果参数有问题应该抛出异常
2. 在logback的asyncappender中配置<neverblock>true</neverblock> 避免业务线程的阻塞
<!-- 异步输出 --> <appender name ="stdout_async" class= "ch.qos.logback.classic.asyncappender"> <discardingthreshold >0</discardingthreshold> <queuesize>512</queuesize> <includecallerdata>false</includecallerdata> <neverblock>true</neverblock> <appender-ref ref ="stdout"/> </appender>
logback的neverblock原理:
由于logback相当于是生产者-消费者模式,当时我们在系统中ogger.info()或者ogger.error()时,是把日志信息加入到logback的队列中,默认是调用队列的put方法,而当队列满了之后,就会阻塞当前的线程。而设置了neverblock后,则会调用offer方法,如果队列满了,则丢弃。可以查看源码:
上一篇: 基于EF的一个简单实战型分层架构
下一篇: 异步调用task
推荐阅读