На страницу 1, 2, 3 След. |
|
|
Друзья, подскажите, какие в CentOS есть ненужные файлы, которые "съедают" место на жестком диске?
На одном ВПСе пару дней назад упала MySQL, пытался запустит\перезапустить ее, даже хотел переустанавливать, а потом базы из бэкапа накатить, хорошо вспомнил, что может быть проблема в нехватке места.
Проверил df -h, действительно, из 30 гигов 29 забиты чем-то непонятным!
Может есть такие файлы, которые периодически нужно удалять - какие-нибудь логи или другие нефункциональные файлы или вообще какой-нибудь пакет можно установить, чтобы он сам место освобождал на диске?
Например, нашел я файл /var/log/mysql.log - его размер аж 1,3 гигабайта!
Можно ли его удалить, чтобы немного очистить место?
И еще файл /var/log/httpd/access_log = 0,87 - гигабайта - можно его удалить?
Буду очень признателен за табличку крупных файлов, которые можно периодически удалять - всякие логи, сессии, чтобы не повредить самой CentOS.
Или может даже возможно прописать какой-то скрипт, чтобы задать максимальный размер таких логов, которые могут раздуваться до размера в гигабайты.
Спасибо!
|
|
|
|
|
|
1. логи, если там нет ничего важного - три.
2. конфиги нормально настрой, чтоб старые логи удалялись. смотри по оптимальному значению.
3. и как вариант можешь посмотреть сколько какая папка весит - и дальше так и искать тяжёлые места... возможно еще что папка с временными файлами не очищается. |
|
|
|
|
|
А разве эта ОС не умеет сама тереть не нужные файлы, особенно логи, в случае если идет нехватка спейса, или же, по иным причинам временности и/или не использованности этих файлов?
Это ладно брать там какой то WIN 2000-х, тут же CentOS, далеко не последняя ОСь для различных хост-станций. |
|
|
|
|
|
три логи да и отключи если не юзаешь, если юзаешь то архивируй кажд неделю/день/час скачивай и обнуляй на сервере - а почитать логи можно и с архивов - и их не удалят чудо хацкеры если что - а если удалят то ты заметишь |
|
|
|
|
|
IseeDeadPeople писал(а): |
А разве эта ОС не умеет сама тереть не нужные файлы, особенно логи, в случае если идет нехватка спейса, или же, по иным причинам временности и/или не использованности этих файлов?
|
Она сама и трет, архивирует старые логи, а старейшие логи удаляет. Видимо ТС как-то странно настроил центос, раз сейчас этого не происходит.
смотри все файлы, которые находятся в /var/log* там только и есть большие файлы.
А так конечно нужно смотреть апач, может логи и по другим директориям распиханы.
Если там есть ДНС и логи постоянно пишутся, то ищи в /var/named/chroot/* |
|
|
|
|
|
TheProLamer, drg, не, у меня не трет логи автоматически. Может поэтому так и раздулись они.
Может кинете линком на мануал или страницу, где описаны имена логов, которые безопасно удалять.
Я просто не хочу удалить что-то нужное |
|
|
|
|
|
Я думаю все лог файлы удалять безопасно.
Другое дело, надо бы тогда тебе на пхп, или на ином шелл языке, скрипт составить, и на крон его поставить, чтобы раз в неделю очищал заданные папки.
Скорее лучше поискать как это на шелл языке сделать, у пхп может не будет прав на такие операции, если запуск будет из под nobody.
Вот тебе ссылки по теме:
http://citforum.ru/programming/shell/ - на этом языке нужно будет составить скрипт
http://yandex.ru/yandsearch?text=unix+crontab - этим никс тулзом, нужно будет поставить его на крон, т.е. на выполнение его по расписанию |
|
|
|
|
|
|
Разумнее будет взять базовое администрирование у хостера. Или установить готовую сборку.
Хитрые скрипты или софт можно и самому подкручивать.
А базовые вещи типа ротации логов должны работать из коробки, ну или поручить админам. |
|
|
|
|
|
Вроде как скриптовый никсовый шел, те же команды что и в шелле. Поэтому можно сразу на крон поставить команду по очистке файлов. В таком случае, задание на кроне будет стоять не одно, но зато можно будет обойтись без промежуточных пакетных файлов.
В таком случае, строка на кроне будет примерно:
* * * * * команда_очистки_папки путь_до_папки |
|
|
|
|
|
exolon писал(а): |
Разумнее будет взять базовое администрирование у хостера. Или установить готовую сборку.
Хитрые скрипты или софт можно и самому подкручивать.
А базовые вещи типа ротации логов должны работать из коробки, ну или поручить админам.
|
Я не думаю что для этого нужно брать тарифы с администрированием.
Только если спросить у кого то из администраторов, где могут быть файлы, которые можно тереть.
Да и то, в никс шелле наверняка есть команды, поиска файлов по всем локальным директориям, и вывод их, если размер больше чем..
Тем более, это интересно, и полезно для общего развития в любом случае. |
|
|
|
|
|
В общем, я нашел еще файлы логов, которые забивали место на диске.
Поиск больших файлов удобно делать командой:
Код: |
find /home -type f -size +10000k -exec ls -lh {} \; | awk '{print $5 ": " $NF}'f
|
А большие логи находятся по адресам:
Код: |
/home/httpd/domain.com/stats/domain.com-custom_log
/home/httpd/domain.com/stats/domain.com-error_log
|
, где domain.com - это имя домена, нужно удалять логи для каждого добавленного и активного сайта.
У одного из сайтов удалил custom_log весом в 30 гигабайт!
После удаления логов нужно перезагрузить сервер, если удаляли файлы через WinSCP, а не через rm. Если не перезагружать, то df -h показывает размер с логами, после перезагрузки показывает правильный размер. |
|
|
|
|
|
ротацию лучше настроить и забыть
вообще админы должны заниматься этим |
|
|
|
|
|
IseeDeadPeople писал(а): |
Я думаю все лог файлы удалять безопасно
|
Мсье теоретик? Не раз видел как люди выполняли rm -rf /var/log/* а потом жаловались, что ось не поднялась "почему-то".
ТСу в помощь logrotate: http://linuxcommand.org/man_pages/logrotate8.html
du -h --max-depth=1 /
покажет какие папки в корне занимают много места. Так можно, переходя по дереву самых больших директорий, увидеть чем именно забито место. Обычно - это логи, почта, бэкапы, дампы памяти и т.д. |
|
|
|
|
|
Иного решения может и не быть. Или тереть логи, при этом не выборочно, если их там over 9999, или же получать потом повсеместные ошибки о нехватке памяти, ну и тормоз в работе.
Тем более, если ОСь умная, то она сама бы стерла, если же она это не делает, и самостоятельная очистка логов приводит к проблемам после ребута, то о каком качестве этой ОС можно говорить.
Тогда конечно будет проще вариант, сменить её. |
|
|
|
|
|
|
|