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

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

 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, который удаляет файл).

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

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

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

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

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

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

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

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

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

  ionice -c3 rm -f filename.log