删除非常大的文件而不冻结网络服务器

在我的Web服务器（apache正在运行，Linux CentOS）中，有一个非常大的日志文件（50 GB）。该Web服务器在生产中具有一些Web服务。

当我尝试删除日志文件时，Web服务器大约10秒钟没有响应。（服务时间。）

rm -f monthly.log

有什么方法可以在不冻结Apache的情况下删除此大文件？

首先通过logrotate，使用如下配置将其旋转：

/path/to/the/log {
    missingok
    notifempty
    sharedscripts
    daily   
    rotate 7
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
    compress
}

然后在午夜创建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

如建议的量子，您需要先对其进行对数旋转。

echo "0" > monthly.log && rm -f monthly.log

我会用该: > /path/to/monthly.log操作将文件截断/归零。然后可能会重新启动Apache进程并设置日志轮换以防止将来发生这种情况...

但是，这经常出现：

请参阅：有没有一种方法可以在Linux上删除100GB文件而不破坏IO /负载？

在UNIX中，减小正在主动写入的海量日志文件的大小的最佳方法是什么？

Linux服务器空间不足

如果不需要数据，请使用/ dev / null截断它：

cat /dev/null > monthly.log

截断后，Web服务器将继续向文件中写入数据，从而避免了重新启动Web服务器的任何需要（与rm monthly.log删除文件不同）。

解决眼前的危机后，请考虑Quanta建议的对数旋转。您不希望这种情况再次发生。注意，默认情况下，Apache日志文件已经在CentOS上旋转

还可以考虑通过syslog发送网络日志（/usr/bin/logger例如，使用）。使用syslog创建的日志通常也已经设置了logrotation。

如果使用的是ext3文件系统，请考虑切换到ext4。

Ext3删除大文件的速度可能很慢，因为它存储每个4k块的位置：一个50GiB文件（50 * 1024 ^ 3字节）占用13107200个块，每个块都以32位块号记录在inode表中，总共50MiB的簿记数据仅用于跟踪文件内容在磁盘上的位置。较大的阻止列表可能分散在许多间接块中，删除文件时必须全部更新。试图访问所有这些间接块的磁盘可能是造成延迟的原因。

另一方面，Ext4最多以128MiB的“范围”分配文件。仅使用400个扩展记录即可将50GiB文件记录在inode表中，而无需使用13107200个单独的块号，这大大减少了删除文件时所需的磁盘I / O数量。

请注意，如果将现有的ext3文件系统就地转换为ext4，则将使用扩展区分配新文件，但是现有文件仍将使用阻止列表。您可以使用chattr +e命令使用扩展​​区重新分配现有文件；在性能方面，这相当于复制文件然后删除原始文件。

这归结为文件系统性能问题。在这个SO问题上有一个有趣的答案，但这确实取决于您使用的文件系统。创建文件系统以为MythTV存储数百个千兆字节的MPEG2文件时，我使用XFS，因为当时XFS的删除性能远远优于ext3。在随后的几年中，情况可能发生了很大变化。

我确实喜欢@quanta的答案。将文件拆分成较小的部分将导致更快的删除速度。

我想这个问题是由于您正在从特权用户删除文件而该特权用户对磁盘操作的优先级高于apache Web服务器用户。无论选择哪种方式删除日志文件（rm -f或通过>截断），都应将其磁盘优先级操作降低到最低水平：

  ionice -c3 rm -f filename.log