这是一个创建于 1895 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个奇怪的问题，在线上服务器使用 echo > stdout.log 清理日志，可以释放 df 和 du 的空间，但是 ll -h 显示的问题还是没有缩小，该文件不能使用 grep 、sed 、head 这些命令处理了，会卡住。使用 tail 或者 vim 跳转到最后也是可以的。文件写入很快，操作系统是 Ubuntu 18.04.3，文件是 java print 的重定向。只有线上环境出现了这个问题。感觉和日志写入速度有关系。
 | 1 CallMeReznov 2020-10-23 15:15:19 +08:00 得先停止之前操作这个文件的进程,然后才能真正的"释放" 用 lsof 看一下就知道了 |
 | 2 arloor 2020-10-23 15:40:22 +08:00 1 楼正解 |
 | 3 zqyisasd OP 是的，是进程占用了。重启进程可以解决。不过就是每次都是要重启才能释放，在别的环境没有这种问题。感觉很奇怪。 |
| 4 CallMeReznov 2020-10-23 16:15:17 +08:00 一般日志都有一个截断的操作,一般为天,巨大的为小时,分钟等. |
| 5 zqyisasd OP echo > stdout.log 截断日志，即使是日志很小也不能成功。日志写入很慢的开发、测试环境都是正常截断的。因为这个是 java -jar > logs/stdout.log, 所以项目也不能处理这个文件。 |
 | 6 yanqiyu 2020-10-24 00:58:54 +08:00 用 `truncate -s 0` 清空看看 不过既然 df 都提示空间释放了，我猜空间是真的释放了 ls -lh 的输出可能是撞上了 bug |
| 7 yanqiyu 2020-10-24 01:06:19 +08:00 @zqyisasd 才读到这一条，换用 >> 来重定向到日志试一试，理论上这样才能保证打开文件用了 O_APPEND 属性，从而使得 > 清理文件好用 |
| 8 zqyisasd OP @yanqiyu 不只是 ll -h, 文件本身的头部也损坏了。文件在>清空时候，同时有大量新的内容写入，估计造成了这个 bug 。 |
| 9 zqyisasd OP 除了重启进程和使用 rsync，这些可以释放文件。目前测试其他的方法都不好使。使用 rsync 后 java 进程不再向文件输入内容。 |
| 10 zqyisasd OP 在文件写入比较慢的时候，truncate -s 0 stdout.log 是有效的 |
| 11 yanqiyu 2020-10-27 20:23:47 +08:00 那就考虑这个 https://man7.org/linux/man-pages/man1/split.1.html 用法： somecommand | split -l <合适的截断行数> --filter='gzip > $FILE.gz' - <输出文件名前缀> 就能实现日志自动分割与存档 |
Select Language