因为并发控制不当,几百个应用的覆盖率数据反复不断上传,导致磁盘不久就满了。应用中凡是牵扯到文件IO的全部报错。由于mysql也安装在这台linux服务器,当对数据库插入数据时也会报错。遭遇的几个问题,详述如下:
1、应用有写入zip文件的行为,当磁盘满时,会导致写入的zip文件不完整,导致后续读zip文件异常:
- Cause By:
- java.io.IOException: Truncated ZIP file
- org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:300)
- java.io.InputStream.read(InputStream.java:85)
- org.apache.commons.compress.utils.IOUtils.copy(IOUtils.java:66)
- org.apache.commons.compress.utils.IOUtils.copy(IOUtils.java:47)
- com.esc.common.util.UnCompressFileUtils.unPackZipFile(UnCompressFileUtils.java:51)
- com.esc.tcc.service.impl.TccDataServiceImpl.saveEmEc(TccDataServiceImpl.java:94)
- sun.reflect.GeneratedMethodAccessor288.invoke(Unknown Source)
- sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- java.lang.reflect.Method.invoke(Method.java:597)
- org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
2、无法向数据库表插入数据:
- Cause By:
- java.sql.SQLException: Disk is full writing './tcc_v40/tcc_p_a_msp_msp.MYD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
这种错误显然应该是极少遇到的,不过,倒是可以给测试人员提个醒,可以去测试这样一些情形,以确保应用在这样极端的情形下,依然有“正常”的表现,或者,给出合理的反馈信息。
线上故障,也有遭遇磁盘满的,比较典型的是因为配置更改,导致日志文件狂打印,把磁盘空间耗完,导致线上故障。提到日志打印,其实,也是一门学问,怎么打,在哪打,是否要打印完整堆栈?是否控制重复打?日志文件如何定时清理?等等。与本篇文章主题离的太远,不详细展开。
转载于:https://blog.51cto.com/memory/1035122