Удаление очень большого файла без зависания веб-сервера

На моем веб-сервере (работает Apache, Linux CentOS) есть очень большой файл журнала ( 50 Гбайт ). Этот веб-сервер имеет несколько веб-сервисов в производстве.

Когда я попытался удалить файл журнала, веб-сервер не получил ответа около 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команду Say, чтобы уменьшить его до нуля, а затем удалить:

 truncate -s 0  monthly.log && rm -f monthly.log

Как и было рекомендовано квантами, сначала необходимо войти в систему.

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

Я бы обрезать / обнулить файл с : > /path/to/monthly.logоперацией. Затем, возможно, перезапустите процесс Apache и настройте ротацию журналов, чтобы предотвратить это в будущем ...

Это часто возникает, хотя:

Смотрите: есть ли способ удалить файл 100 ГБ в Linux без перегрузки ввода-вывода / загрузки?

В Unix, как лучше всего уменьшить размер массивного файла журнала, в который активно записывается?

На сервере Linux не хватает места

Если вам не нужны данные, обрежьте их, используя / dev / null:

cat /dev/null > monthly.log

Веб-сервер будет продолжать записывать данные в файл после усечения, что исключает необходимость перезапуска веб-сервера (в отличие от того rm monthly.log, который удаляет файл).

После урегулирования непосредственного кризиса, рассмотрите logrotation, как предложил Quanta. Вы не хотите, чтобы это повторилось. Обратите внимание, что лог-файлы Apache уже повернуты по умолчанию в CentOS

Также рассмотрите возможность отправки логов через syslog ( /usr/bin/loggerнапример, используя). Журналы, которые создаются с использованием syslog, также обычно уже настроены.

Если вы используете файловую систему ext3, рассмотрите возможность перехода на ext4.

Ext3 может медленно удалять большие файлы, поскольку в нем хранится местоположение каждого отдельного блока 4 КБ: файл размером 50 ГБ (50 * 1024 ^ 3 байта) занимает 13107200 блоков, каждый из которых записывается в таблицу индексов как 32-битный номер блока. , в общей сложности 50MiB бухгалтерских данных только для отслеживания того, где содержимое файла находится на диске. Этот большой список блоков может быть разбросан по многим косвенным блокам , которые должны быть обновлены при удалении файла. Поиск диска для доступа ко всем этим косвенным блокам, вероятно, и является причиной задержки.

Ext4, с другой стороны, распределяет файлы в «экстентах» до 128 МБ. Этот файл размером 50 ГБ может быть записан в таблице inode, используя только 400 записей экстентов, а не 13107200 отдельных номеров блоков, что значительно сокращает объем дискового ввода-вывода, необходимый при удалении файла.

Обратите внимание, что если вы конвертируете существующую файловую систему ext3 на месте в ext4, новые файлы будут распределяться с использованием экстентов, но существующие файлы будут по-прежнему использовать списки блокировки. Вы можете использовать chattr +eкоманду для перераспределения существующего файла с использованием экстентов; с точки зрения производительности это сопоставимо с созданием копии файла и последующим удалением оригинала.

Это сводится к проблеме производительности файловой системы. На этот SO вопрос есть интересный ответ, но это скорее зависит от того, какую файловую систему вы используете. Я использовал XFS при создании файловой системы для хранения сотен мультигигабайтных файлов MPEG2 для MythTV, потому что в то время производительность удаления XFS была намного выше, чем у ext3. Вещи, возможно, значительно изменились за прошедшие годы.

Мне действительно нравится ответ @ кванты. Разделение файла на более мелкие части приведет к более быстрому удалению.

Проблема, я полагаю, заключается в том, что вы удаляете файл от привилегированного пользователя, который имеет больший приоритет для операций с диском, чем пользователь веб-сервера apache. Независимо от того, каким способом вы решите удалить файл журнала (rm -f или усечь по>), вы должны уменьшить приоритет операций с дисками до минимума:

  ionice -c3 rm -f filename.log