从一次服务器IO过高问题说到Log4j2的自动压缩配置

线上服务器遇到IO过高问题，造成线上业务严重卡顿。查明原因是运维做了一个压缩日志的脚本，每隔十分钟把未压缩的日志压缩一次，刚好当时一次压缩时间超过了十分钟，脚本也没有检查自己是否已经在执行，会新启动一个脚本再压缩，而两个并行的脚本会比之前更慢，会再超过十分钟，再新启动新的脚本，如此反复，一直到五十分钟后，并行压缩的多个脚本终于引发了IO过高，影响到了线上业务。

教训一，任何服务器脚本都需要检查自己是否已经在执行，避免重复执行。

教训二，如果有现成的很好的实现，不要重新发明轮子。

其实Log4j2已经实现了自动压缩日志的功能，只需要把归档日志的文件后缀名声明为.gz或者.zip。

建议配置为按时间和文件大小滚动，比如一小时和大小1GB，通过Log4j2压缩过大的文件同样会影响程序性能。

注意，滚动归档日志文件名一定要带%i参数，看到很多文档里没有说明这一点，会导致日志会被滚动覆盖。

Log4j2的配置：

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="info" monitorInterval="600">
	<Properties>
		<Property name="LOG_PATTERN">%d{DEFAULT}|%level|%t|%c{40}|%msg%n%ex</Property>
	</Properties>
	<Appenders>
		<Console name="Console" target="SYSTEM_OUT">
			<PatternLayout>
				<Pattern>${LOG_PATTERN}</Pattern>
			</PatternLayout>
		</Console>
		<RollingRandomAccessFile name="File" fileName="log/gameserver.log"
						  filePattern="log/gamelog/gameserver.%d{yyyyMMddHH}.%i.log.gz"
						  immediateFlush="false"
						  append="true">
			<PatternLayout>
				<Pattern>${LOG_PATTERN}</Pattern>
			</PatternLayout>
			<Policies>
				<TimeBasedTriggeringPolicy modulate="true" interval="1" />
				<SizeBasedTriggeringPolicy size="1000MB"/>
			</Policies>
		</RollingRandomAccessFile>
	</Appenders>
	<Loggers>
		<AsyncRoot level="info"
				   includeLocation="true"
				   additivity="false">
			<AppenderRef ref="Console"/>
			<AppenderRef ref="File"/>
		</AsyncRoot>
	</Loggers>
</Configuration>