Сбежавшая программа создала большое количество (как минимум миллион?) файлов в /var/log. Даже после удаления всех (?) мошеннических файлов любой запрос к папке/дереву теперь занимает около 5 минут и может привести к замедлению работы всей системы.
Проблема заключалась в том, что файлы .gz, созданные logrotate, добавлялись в другие архивы .gz, а те архивировались и... упс. Таким образом, все недействительные файлы .gz были удалены из /var/log - проблема с исходным кодом была исправлена.
Как я могу точно узнать, что по-прежнему вызывает задержки?
- В дереве /var/log есть 75 каталогов с 1606 файлами, занимающими всего 1 ГБ.
лс /вар/журнал обработка занимает более 5 минут.- Другие более крупные деревья папок требуют гораздо меньше времени для запросов.
лс, найти, grep, и т.д.
дерево на /var/log также занимает около 5 минут и в результате получается совершенно нормальное дерево папок/файлов.дф -я показывает в общей сложности 10 миллионов инодов, менее миллиона используемых, более 9 миллионов неиспользуемых. Система была перезагружена несколько раз.
я был бы в порядке с рм -рф на всем дереве журнала с последующим перезапуском. С мв или же ср в другую папку, «некоторый сброс» и перемещая все обратно, я был бы обеспокоен тем, что просто копирую проблему из одного места в другое.
Мне интересно, можем ли мы сканировать / очищать поврежденные индексные дескрипторы или, может быть, это поможет уменьшить количество инодов до минимума, а затем снова запустить его после перезапуска.
Это простая установка с /var в единственном корневом разделе / для ОС/данных. Так что размонтировать/заменить не вариант.
Я могу легко провести диагностику и предоставить соответствующую информацию.
Это полностью пропатченный облачный сервер v20.04.3. Я могу открыть консоль, если нужно.
e4defrag не показал фрагментации. Может работать fsck (e2fsck или же выключение -rF), если это рекомендуется.Это примеры утилит, которые я ищу, чтобы помочь с диагностикой такого рода проблем.
