在我的networking服务器（Apache正在运行，Linux CentOS），有一个非常大的日志文件（ 50千兆字节 ）。 这个Web服务器在生产中有一些Web服务。
当我试图删除日志文件时，Web服务器在10秒内没有响应。 （服务时间。）
rm -f monthly.log 有没有办法删除这个没有Apache冻结的大文件？
首先通过logrotate旋转它，使用像这样的configuration：
/path/to/the/log { missingok notifempty sharedscripts daily rotate 7 postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true endscript compress }
然后在午夜创build一个cron作业来删除旋转的文件：
30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1
要更快地删除大文件，可以使用truncate命令 – 将其缩小为零大小，然后将其删除：
truncate -s 0 monthly.log && rm -f monthly.log
作为量子build议，你需要先旋转它，但是。
echo "0" > monthly.log && rm -f monthly.log
我将截断/归零文件: > /path/to/monthly.log操作。 然后可能重新启动Apache进程并设置日志轮转以防止在将来发生这种情况…
不过这经常会出现：
请参阅： 有没有办法删除Linux上的100GB文件，而不会颠簸IO /负载？
在unix中，减less正在被写入的海量日志文件的大小的最佳方法是什么？
Linux服务器空间不足
如果您不需要这些数据，请使用/ dev / null截断它：
cat /dev/null > monthly.log
在截断之后，networking服务器将继续向文件写入数据，这避免了重新启动networking服务器（不像rm monthly.log ，这会删除文件）。
解决眼前的危机之后，考虑Quanta的build议。 你不想再发生这种情况。 请注意，Apache日志文件在CentOS上已经默认被旋转了
还要考虑通过系统日志发送networking日志（例如，使用/usr/bin/logger ）。 使用syslog创build的日志通常也已经build立了logrotation。
如果您使用的是ext3文件系统，请考虑切换到ext4。
Ext3在删除大文件时可能会很慢，因为它存储了每个单独的4k块的位置：一个50GiB文件（50 * 1024 ^ 3个字节）占用13107200个块，每个块都logging在inode表中作为32位块号，总共50MiB的logging数据只是为了跟踪文件内容在磁盘上的位置。 该大块列表可能分散在许多间接块中 ，当文件被删除时，所有这些块都必须被更新。 试图访问所有这些间接块的磁盘可能是导致延迟的原因。
另一方面，Ext4则以128MiB的“范围”分配文件。 这个50GiB文件只能使用400个扩展logginglogging在inode表中，而不是13107200个别的块号，这大大减less了删除文件时所需的磁盘I / O数量。
请注意，如果将现有的ext3文件系统就地转换为ext4，则将使用扩展区来分配新文件，但现有文件仍将使用块列表。 您可以使用chattr +e命令使用扩展数据块重新分配现有文件; 性能方面，这相当于制作文件的副本，然后删除原件。
这归结为文件系统的性能问题。 在这个问题上有一个有趣的答案，但是这取决于你正在使用的文件系统。 在创build文件系统时，我使用了XFS来为MythTV存储数百个多GB的MPEG2文件，因为当时XFS的删除性能远远优于ext3。 在这段时间里事情可能发生了很大的变化。
虽然我喜欢@ quanta的回答。 将文件分割成更小的部分将导致更快的删除。
问题来自我想，你是从特权用户删除文件比磁盘操作优先于apache的web服务器用户。 无论您select删除日志文件（rm -f或truncate by>），您都应该将其磁盘优先级降至最低：
ionice -c3 rm -f filename.log