У моєму веб-сервері (апарат запущений, 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командою - Скажіть, щоб зменшити її до розміру нуля, а потім видалити:
truncate -s 0 monthly.log && rm -f monthly.log
Як рекомендують кванти, вам потрібно спершу логротувати його.
truncateвідрізняється від >?
truncateПростіше у використанні , з sudoчим >. З цим також простіше find -exec.
Я б урізав / нулював файл : > /path/to/monthly.logоперацією. Тоді можливо перезапустіть процес Apache та встановіть обертання журналу, щоб уникнути цього в майбутньому ...
Це трапляється часто, хоча:
Дивіться: Чи є спосіб видалити 100 Гб файл в Linux без обміну IO / завантаження?
У Unix, який найкращий спосіб зменшити розмір масивного файлу журналу, який активно записується?
:. Можна просто зробити> /path/to/monthly.log
noop, але це має більше сенсу з навчальної точки зору.
true > /path/to/monthly.logзробити те ж саме, і це менш архаїчно :?
Якщо вам дані не потрібні, обріжте їх за допомогою / dev / null:
cat /dev/null > monthly.log
Веб-сервер продовжить записувати дані у файл після усікання, що дозволяє уникнути необхідності перезапускати веб-сервер (на відміну від того rm monthly.log, який видаляє файл).
Після вирішення негайної кризи розгляньте логратацію, як запропонувала Кванта. Ви не хочете, щоб це повторилося. Зауважте, що логіни Apache вже поворотно обертаються у CentOS
Також розглянути можливість надсилання веб-журналів через syslog ( /usr/bin/loggerнаприклад, наприклад). Журнали, які створені за допомогою syslog, зазвичай також вже налаштовані логротацією.
>logfileне потребуєте котів
Якщо ви використовуєте файлову систему ext3, розгляньте можливість переходу на ext4.
Видалення великих файлів Ext3 може бути повільним, оскільки він зберігає розташування кожного окремого блоку 4k: файл 50GiB (50 * 1024 ^ 3 байти) займає 13107200 блоків, кожен з яких записується в таблицю вкладень як 32-бітний номер блоку , загалом для 50MiB даних бухгалтерського обліку, щоб відстежувати, де вміст файлу знаходиться на диску. Цей великий список блоків може бути розкиданий по безлічі непрямих блоків , усі вони повинні бути оновлені, коли файл видалений. Диск, який прагне отримати доступ до всіх цих непрямих блоків, ймовірно, викликає затримку.
Ext4, з іншого боку, виділяє файли в "розширеннях" до 128MiB. Цей 50GiB-файл можна записати в таблицю inode, використовуючи записи на 400 розмірів, а не 13107200 індивідуальних номерів блоків, що різко зменшує кількість вводу / виводу диска, необхідного при видаленні файлу.
Зауважте, що якщо ви конвертуєте існуючу файлову систему ext3 в ext4, нові файли будуть виділятися за допомогою розтяжок, але існуючі файли все ще використовуватимуть списки блоків. Ви можете використовувати chattr +eкоманду для перерозподілу наявного файлу за допомогою розширень; Це залежить від продуктивності копіювання файлу та видалення оригіналу.
Це зводиться до проблеми продуктивності файлової системи. На це питання SO є цікава відповідь, але це залежить від того, яку файлову систему ви використовуєте. Я використовував XFS під час створення файлової системи для зберігання сотень багатогігабайтних MPEG2-файлів для MythTV, оскільки на той час продуктивність XFS для видалення була набагато кращою для ext3. Речі, можливо, істотно змінилися протягом останніх років.
Мені подобається відповідь @ quanta. Розщеплення файлу на менші частини призведе до швидшого видалення.
Я думаю, проблема полягає в тому, що ви видаляєте файл від привілейованого користувача, який має більше пріоритету для операцій на диску, ніж користувач веб-сервера apache. Незалежно від того, яким способом ви вирішите видалити файл журналу (rm -f або усікання за>), ви повинні знизити його пріоритетні дії на диску до мінімуму:
ionice -c3 rm -f filename.log