История про дэбаг геморроя с гига-кешем com_k2_extended, куда может деваться свободное место на сервере и про способы поиска источника проблемы. В некоторых особо запущенных случаях с поиском причины утечки места на диске могут возникнуть проблемы, например когда команда du -shc повесилась
Предыстория
Предыстория возникшего геморроя примерно следующая:
- есть некий сайт с тысячами материалов и каким-то неизвестным количеством их авторов;
- все авторы имеют права администратора, что КАТЕГОРИЧЕСКИ НЕ РЕКОМЕНДОВАЛОСЬ делать, но так пожелал владелец ресурса;
- какое-то время из месяца в месяц, из года в год сайт стабильно работал без видимых признаков радикальных изменений в его размерах на диске;
- потом неизвестно почему, вдруг, спустя пару месяцев стало пропадать свободное место на диске по 2 ГБ в день!
САМО ж по себе ничто и никогда ОНО НЕ ЛОМАЕТСЯ! У проблем всегда есть руки/ноги, ФИО, паспорт, ИД-код, и.., РФИД- мозговые чипы в обозримом будущем.
Толи по злому умыслу, то ли по случайной неосторожности.., короче говоря на сайте что-то пошло не так.
Первым же делом в голову пришла мысль узнать размеры всех каталогов с помощью команды du -shc /*, но она взяла и повесилась намертво...
man du -c, --total produce a grand total -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) -s, --summarize display only a total for each argument
man du - как-то звучит неприлично...
Трассировка процесса показывает нам то место, где в данный момент идёт работа:
sudo strace du -hc /* ... newfstatat(6, "5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-03787f67a2b0176779b2f24136013b54.php", {st_mode=S_IFREG|0644, st_size=58131, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(6, "5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-43cc9b42650c6d181c06d4dca8db5bd8.php", {st_mode=S_IFREG|0644, st_size=25681, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(6, "5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-d3e17888473ed2b90d206898502c7581.php", ^Cstrace: Process 13402 detached <detached ...>
По тексту com_k2_extended стало ясно-понятно, что это и где оно примерно, но можно использовать locate com_k2_extended - это каталог: /cache/com_k2_extended
Меняем права на каталог тем самым запрещая запись всем кроме root с доступом только на чтение для всех остальных:
sudo chown root:root /cache/com_k2_extended
Листинг файлов в директории с выводом в файл по одному на строку:
sudo ls -1 /cache/com_k2_extended > /tmp/com_k2_extended_ls
Размер:
du -shc /tmp/com_k2_extended_ls 64M /tmp/com_k2_extended_ls 64M total
Число строк (файлов в com_k2_extended):
sudo wc -l /tmp/com_k2_extended_ls 720688 /tmp/com_k2_extended_ls
Спустя пару минут, повторяем листинг и подсчет строк в итоговом файле, чтобы убедится в отсутствии изменений в числе файлов:
sudo ls -1 /cache/com_k2_extended > /tmp/com_k2_extended_ls2 sudo wc -l /tmp/com_k2_extended_ls2 720688 /tmp/com_k2_extended_ls2
Предварительно зафиксировав до сек. текущее время, возвращаем права взад и незамедлительно повторяем процедуру:
sudo chown usr:usr /cache/com_k2_extended sudo ls -1 /cache/com_k2_extended > /tmp/com_k2_extended_ls2 sudo wc -l /tmp/com_k2_extended_ls2 720905 /tmp/com_k2_extended_ls2
Итого ушла одна минута времени (21:18 - 21:19), за которую в каталоге /cache/com_k2_extended наросло (720905 - 720688) 217 новых файлов.
Если снова на каталог /cache/com_k2_extended вернуть права прежнему владельцу, от имени которого работают скрипты сайта, процесс появления новых файлов возобновляется и никогда не прекращается!
Давайте посмотрим, что же там внутри:
sudo less /tmp/com_k2_extended_ls2 ... 5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-ffffef95bdf8685cb34ecaea6e68812f.php (END) sudo less /cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-ffffef95bdf8685cb34ecaea6e68812f.php
Прикинем примерный размер всего каталога исходя из размера одного файла в байтах:
sudo ls -la /cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-ffffef95bdf8685cb34ecaea6e68812f.php -rw-r--r-- 1 usr usr 26440 Sep 24 17:05 /cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-ffffef95bdf8685cb34ecaea6e68812f.php
В итоге: 26440 байт * 720905 файлов = 19031892000 / 1024 = 18585832,0312 кб / 1024 = 18150,226593 МБ / 1024 = 17,7248306572 ГБ!
Поищем дубликаты:
sudo apt-get install fdupes sudo fdupes /cache/com_k2_extended/ Progress [236695/720905] 32%
Наверное быстрее было бы:
- очистить каталог /cache/com_k2_extended/;
- вернуть права на каталог прежнему владельцу;
- подождать мин 30 пока оно туда дерьма снова навалит, но не так много как 17,7248306572 ГБ!;
- потом поискать дубликаты.
Но, нам так быстро и не нужно потому, что кроме этого геморроя у нас имеется куча других, и к тому же для чистоты эксперимента пусть оно (fdupes) покажет себя при работе с таким числом файлов.
fdupes накопало по 2-3 дубля на экземпляр:
/cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-3e3146b672520a10758baef6cda55b28.php /cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-d12adf6e775c08590146ed96db42e6f9.php /cache/com_k2_extended/5bcecfbf0285810c7684ebdf955539df-cache-com_k2_extended-3c708a0a6ee9121d4eba437bca93cd37.php
Решено очистить /cache/com_k2_extended/, но сделать это оказалось тоже не так просто:
sudo sh -c "rm -rf /cache/com_k2_extended/*" sh: 1: rm: Argument list too long
Делается это через:
sudo sh -c 'find /cache/com_k2_extended/ -type f -print0 | xargs -0 rm'
Всю ту кучу дерьма, файл за файлом, команда rm выпиливала минут 60+, ПОСЛЕ ЧИСТКИ НА ДИСКЕ СНОВА ПОЯВИЛОСЬ 30 ГБ свободного дискового пространства.
Сервера не останавливались, работа веб-ресурса не прерывалась, проблему временно стабилизировали сменой прав на каталог sudo chown root:root /cache/com_k2_extended, что запрещает запись в него.
Нам нужно переключится на другие задачи, а тем временем владелец веб-ресурса со своими администраторами пусть подумают и повспоминают, что и где в настройках они могли там наадминистрировать?!
ВЕДЬ МИНУС ПО 2 ГБ В СУТКИ, а до появления проблемы там было свободно примерно 25 ГБ, - ЭТО ГДЕ-ТО дней на 10 (на дольше точно не хватило бы), следовательно ДНЕЙ 10 ТОМУ ВЗАД НАЧАЛОСЬ и точно не само по-себе!
Но уже заранее ответ примерно ясен-понятен: МЫ НИЧЕГО НЕ ТРОГАЛИ И ОНО САМО ВСЁ ВЗЯЛО И ПОЛАМАЛОСЯ!
Тогда сразу же следом возникает закономерный вопрос: А НАФИГА Ж ВАМ ТАМ ТОГДА АДМИНИСТРАТИВНЫЕ ПРАВА РАЗ ВЫ НИЧЕГО НЕ МЕНЯЕТЕ А ТОЛЬКО МАТЕРИАЛЫ ПОСТИТЕ?!
НЕ ИСКЛЮЧЁН И ВАРИАНТ ГЛЮКА в компоненте
Но, также НЕ ИСКЛЮЧЁН И ВАРИАНТ ГЛЮКА в компоненте при достижении некоторого условного числа материалов, при превышении которого компонент начинает херачить файлы в кеш по-кругу и каждый раз с новым хешем *-cache-com_k2_extended-NEW_HASH...
Проверка на вирусы дала негативный результат:
sudo clamscan /home/user/www/ -l /home/user/www/clamscan.log -r ... ----------- SCAN SUMMARY ----------- Known viruses: 8698542 Engine version: 0.103.9 Scanned directories: 4130 Scanned files: 74526 Infected files: 0 Data scanned: 4307.22 MB Data read: 4319.84 MB (ratio 1.00:1) Time: 1342.205 sec (22 m 22 s) Start Date: 2024:09:25 15:31:38 End Date: 2024:09:25 15:54:00
Изменённых файлов в движке за последние 60 дней не обнаружено:
sudo find /home/user/www/ -ctime -60|grep -v -E "(/cache|/images|/media)"|less
На первый взгляд с файлами движка всё чисто, без видимых изменений, без вирусов.., - остаются только настройки БД или глючность компонента.
Способы стабилизации
Учитывая тот факт, что причин появления упомянутой выше проблемы может быть много, и капец может оказаться намного ширше и глубже чем мы сможем предположить, - нам нужны какие-то костыли, которые помогут стабилизировать пациента вже сьогодня
.
Консолидироваться можно вдвоём, по вечерам, и на костылях...
(с) Х/Ф Замысел 2019 (Донфильм)
immutable bit и sticky bit (Костыли V1)
Самый быстрый и безотказный вариант - запрет на запись в каталог навсегда и вовеки веков, АДминь:
sudo chown root:root /cache/com_k2_extended
Если после этого сайт продолжает работать, то всё ок, и для ещё более полной стабилизации как вариант можно установить sticky bit и immutable bit на каталог:
sudo chmod +t /cache/com_k2_extended/ sudo ls -la /cache|grep com_k2_extended drwxr-xr-t 2 root root 1363968 Sep 25 04:09 com_k2_extended sudo chattr -RV +i /cache/com_k2_extended sudo lsattr /cache|grep com_k2_extended ----i---------e---- /cache/com_k2_extended
blackhole directory (Костыли V2)
Для данных из stdout в системе есть /dev/null, где весь перенаправленный туда текстовый вывод любых программ исчезает без следов и навсегда.
С файлами и каталогами чуть сложнее, но и для них найдутся чёрные дыры.., что-то вроде nullfsvfs.
nullfsvfs - это виртуальная файловая система (НЕ blackhole), где создаваемые файлы и каталоги не занимают физического дискового пространства, но читаются как реальные возвращая ноли вместо реальных данных.
Спомощью nullfsvfs можно относительно элегантно и безболезненно решить кучу головных болей сваливая туда тонны ненужного файлового шлака, а из ключевых недостатков nullfsvfs можно отметить следующие:
- НЕ является blackhole по-определению потому, что файлы там сохраняются и доступны для чтения;
- НЕ доступно из репозиториев, требует ручной сборки и установки;
- При обновлении ядра и перезагрузке с новым ядром virualfs отвалится и потребуется пересборка программы, а иначе весь файловый шлак снова может попереть на реальную ФС;
- Вызывает задержки при чтении больших размеров виртуальных файлов, но сей косяк можно поправить перед компиляцией добавив return 0; в начале тела функции
read_null()файлаnullfs.c.
По-нашему субъективному мнению-суждению создание каталогов и файлов вместо их полного исчезновения, как то происходит с stdout в /dev/null, есть недостатком nullfsvfs, что не даёт ей права называться blackhole directory или даже /dev/null, - этому проекту скорее подходит название virualfs | zerovfs | или что-то в таком роде.
Холивар на данную тему по ссылке:
nullfsvfs возможно форк более старого своего собрата nullfs:
Поиск и физическое устранение
Самый верный, но возможно и самый затратный вариант решения - поиск и физическое устранение источника проблемы ИМХО борьба с последствиями в долгосрочной перспективе вполне может обойтись дороже.
В данном случае проблема, как уже можно было догадаться, в компоненте com_k2_extended, или - в его настройках.
K2 - ЭТО ЕЩЁ ТОТ ГЕМОРРОЙ!
Помнится, годами ранее с этим же веб-ресурсом возникли капитальные проблемы с нагрузкой на сервер БД, которы просто наглухо вешался и сайт стало невозможно просматривать. Покопавшись в журналах медленных запросов обнаружили основного потребителя ресурсов БД - криво-руко-жопый плагин k2_additional_categories и непродуманная структура индексов в его таблице БД.
Плагин тогда не трогали, хорошо подумав перераспределили/добавили/удалили индексы в нескольких таблицах и сайт сразу завёлся и зашуршал, как новенький только начатый - по сегодняшний день кажись без проблем.
Сошедшему с ума кэшу компонента com_k2_extended можно запретить писать на диск сменой прав или сим-линком перенаправить в blackhole (в идеале) или в виртуальную ФС если blackhole как таковой по-определению для файлов ещё не придумали.
Но сошедший с ума кэш компонента com_k2_extended так или иначе какую-то же нагрузку на ресурсы сервера будет продолжать создавать, занимая сокеты/таймауты/иноды и прочие ресурсы.
Если вбить в поиск com_k2_extended:
То напервых же позициях всплывает геморр с кешем и как его вырубить:
- disable caching com_k2_extended - Community Forum - JoomlaWorks
- K2 Cache is too big com_k2_extended - Community Forum - JoomlaWorks
- K2 + cache и большое количество статей - ошибка сохранения/изменения материалов
Где юзеры:
- жалуются на гиговый кеш
- бъются в конвульсиях отчаяно пытаясь найти способы отключения кеша
- ставят какие-то скрипты очистки в задачи крон(а)
- закрывают комментариями кучи строк в коде
- и т.д.
Затраханные кешем com_k2_extended пользователи отмечают гиговые его размеры в 1-4 ГБ (широты/высоты/толщины), в нашем случае его без малого 20 ГБ почти выросло/наросло!
Спрашивается, если на сайте 5-10К материалов, то какого куя файлов кеша миллион штук, среди которых по 2-3 дубля - fdupes прошерстивший /cache/com_k2_extended/ не даст соврать!
При всём том.., прирост материалов десятки в день, а прирост файлов кеша около 100 000 за день наросатает и не останавливается никогда что самое главное, даже когда материалы не добавляются!!!
Время жизни кеша скажете?
Ок, но, во-первых, общее число всех материалов и ежедневный прирост общего числа файлов кеша, - как-то не совпадают...
Во-вторых, если материал остался неизменным, то и его хеш (имя файла в кеше) должен оставаться прежним, а значит повторно создавать файл кеша точно с тем же содержимым но с новым хешем в имени файла, - нет никакого смысла! А если по хеш-сумме материала не проверяется наличие аналогичного файла в кеше, или какие-то просчёты/промахи в хешировании, как с индексами БД в k2_additional_categories, то - это точняк лютейший сука баг, а никак не фича!
И ты попробуй это геморройное место в их говнокоде сначала найди.., потом исправь.., и самая главная мега-сложная задача, - ещё попробуй потом дебилам-разрабам (разжуй) докажи важность (и в рот положи), а иначе при следующем апгрейде говно-кода твои правки слетят в blackhole.
Складывается такое впечатление, что это com_k2_extended делали конченные Пи...асы.., не ЛГБТшники, а именно Пи...асы и бесчеловечные садо-мазохисты.
Продолжение следует...
