Peka пишет:Vascom пишет:Теперь можешь посмотреть du -hs /var/* и далее, пока не найдёшь виновника. Потом уже можно решить что с этим делать.
Так у меня там база Пострегреса, она может быть и больше 100 Гб.
Выходит, что мне нужно увеличить /dev/mapper/vg_user1c-lv_root.
А как это сделать ?
Самое простое - перенести базу в терабайтный /home, а на прежнем месте создать символьную ссылку на новое расположение (ln -s /path_to_new /path_old). Можно и размеры томов покорячить... Но это - больше времени займет, и не даст никакой гарантии, что новый объем исчерпан быстро не будет.
И по /tmp в ramfs. Я не такой большой специалист как Vasсom, но не вижу ничего опасного в перемещении /tmp в RAM по tmpfs (не ramfs-же...). Если мне не изменяет склероз, то то, что не помещается в tmpfs будет (в отличие от ramfs) выноситься в swap.
Перенести /tmp очень просто (правда, придется перезагрузить компьютер) - пишем в /etc/fstab одну строчку:
tmpfs /tmp tmpfs defaults 0 0
Проверяем, чтобы последняя строка этого файла была пустая и перезагружаемся.
Ну и zRam до кучи тоже неплохо было бы активизировать. Особенно если памяти много, а приложения хотят в свап залезть. Тоже ускорит работу.
В качестве примера приведу личный опыт. Есть клиентское приложение 1С v7.7. Работает на DBF-файлах. Есть в нём штатная операция "восстановление последовательности документов". Если 1С (с окружением) настроен штатно, то у меня проведение документов за месяц осуществляется за 40-50 минут в зависимости от количества документов. Но, если я перекину временный wine-каталог (user/Temp) в RAM, то тот же месяц у меня будет обрабатываться не дольше 10 минут против почти часового елозанья по жесткому диску в штатных настройках.
Отсюда - если есть приложение, активно работающее с tmp-файлами, то его tmp-файлопомойку следует размещать в RAM.