nikitapo

Форум очень старый, с 2010 года им почти никто не занимался, меня попросили восстановить и технически администрировать. Мне пришлось со 2 версии IPB (или даже с 1-ой) последовательно накатывать все обновления, дотащил форум до версии 3.3.4 так он и работал некоторое время (в размерах сильно не изменялся), пока не упал в следствие вирусной атаки на хостинг. Я восстановил форум и сделал все актуальные обновления до версии 4.1.19.4 (по факту я дотащил базу до этой версии о поставил чистый форум) и опять на время о нем забыл, пока мне не пришло сообщение, что места на хостинге почти не осталось, зашел, стал разбираться и выяснил, что очень быстро растет таблица core_cache (действительно забивает ее страницами в html разметке, только вместо кириллицы гонит кодировку типа "/428/658/454/324/"). Сам он не очищается, только в ручную (или задачей). За неделю размер базы разрастается до 3-4Гб при этом значительно увеличивается нагрузка на сервер (из 4% допустимых процентов может доходить до 40%), правда, здесь не могу однозначно сказать, что это взаимосвязано, но очень похоже. Спасибо, попробую поиграть с кешированием.

Спасибо вам за помощь. Согласен, что к любому совету надо подходить осмысленно, но зачастую скрипт могут просто скопировать и запустить. То есть, принять решение проблемы в чистом виде. Кстати, вспомнил этот ролик. И смешно и грустно: https://www.youtube.com/watch?v=prD-2eVmFZc

Вот такие:

Да, так и есть. Вам просто пишут о том, что в предложенном вами скрипте есть очистка поисковых логов, что не правильно.

Сильно растет core_cache, в нем основная проблема (причину не выявил пока), а про поисковые индексы согласен, не стоит их удалять.

Зачистил по этой схеме и форум даже не упал. Думаю, что может вот эти две таблицы тоже стоит включить для очистки: ibf_core_tags_cache, ibf_core_like_cache? На данный момент размер БД чуть меньше 300 Мб.

Продолждение к предыдущему посту. На мой вопрос о расхождении отображаемого размера таблиц в phpMyAdmin и размера БД в личном кабинете тех.поддержка дала ответ: "В базе данных ortipb есть много таблиц в формате InnoDB. Из-за особенностей этого типа реальный объём таблиц на сервере может различаться с показываемым в phpMyAdmin объёмом". ibf_core_cashe , в частности, в формате InnoDB, но до этого примерный объем таблиц в phpMyAdmin совпадал с отображаемым в личном кабинете. В связи с этим реализую способ, предложенный "sergey81", и посмотрю, что произойдет.

Мой краткий отчет спустя 3 дня. 1. Включил автоматическую очистку логов каждый день. 2. Выполнил "Advanced Configuration -> Enable template disk caching". В таблицы данные за три дня. ibf_core_log стал очищаться каждый день, ibf_core_cashe раньше только постоянно рос, теперь стал самоочищаться примерно через день. Вроде бы все хорошо, но размер базы, который отображается в панели моего хостинга продолжает расти и с примерно 400 Мб вырос уже до 1Гб (картинка ниже). При этом не очень понимаю, где сокрыт этот размер, если просуммировать размер таблиц, то даже близко нет 1Гб (не исключаю, либо какой-то глюк на хостинге, либо я чего-то не знаю про размер БД). В любом случае еще раз всем спасибо за помощь!

Да по твоему описанию очень похоже на то, что у меня сейчас происходит (максимально БД доходила до 2.5Гб очень быстрыми темпами). Попробую выполнить твои инструкции. WOLF, спасибо за совет, уже включил автоматическую очистку логов каждый день, спустя 2-3 дня отпишусь в теме о результатах. kgb, спасибо, с кэшом одназначно что-то не так. Попробую включить этот пункт в конфиге, посмортим, что будет.

Спасибо за поддержку. После вчерашней оптимизации БД увеличилась на 300 Мб. Ниже скрин, где я подчеркнул виновника. К тому же, посмотрел логи за ночь, там было около 2500 обращений за 5 часов.

Здравсвуйте. У меня есть форум на IPS 4.1.19.4. При обновлении БД форума весила около 550 Мб, уже на следующие сутки БД стала весть около 608 Мб, спустя 5 дней весит около 1Гб. После оптимизации БД через phpMyAdmin размер базы сбрасывается до первоначального. В папке форума периодически появляются новые php файлы в подпапке - datastore, с названиями: leaderHashes_month-c81e728d9d4c2f636f067f89cc14862c.4e52a1ea3c.php settings.4e52a1ea3c.php template_1_5cf5b8e33cead46ac4a699bc41eb7f06_licensekey.4e52a1ea3c.php и т.п. Возможно кто-то сталкивался с подобной проблемой и есть решение? P.S. Сканер AI-Bolit не находит подозрительных файлов.

Спасибо за ответ. Хороший способ, но, как я понимаю, принципиально не отличается от того, что был предложен выше, то есть, ищем в базе и меняем. Я опасался, что может быть где-то не усмотрел дополнительные настройки, т.к с новой версией еще недостаточно разобрался. :)

Я видел, что подобные темы уже обсуждались, но не нашел совсем моего случая. Кратко: У меня был форум IPB 2.3.5 я сделал его последовательное обновление до IPB 3.4.6 на локальной машине, затем на хостинге установил по новой IPB 3.4.6 и сделал бэкап базы с локальной машины, в Административном центре изменил все ссылки, но позже обнаружил, что все смайлики, как изображения, в сообщениях имеют неправильный путь, тот путь, который был на локальной машине для версии IPB 2.3.5. Так как сами файлы форума были залиты по-новому и ссылки не исправились, решил, что ссылки стали статическими в процессе обновления форума и их можно исправить только исправлением в БД (не исключаю, что это предположение является ложным). Подобным запросами к БД исправил 4-е таблицы: UPDATE `ibf_message_posts` SET `msg_post` = REPLACE( msg_post, 'localhost/ipb', 'site.ru' ) UPDATE `ibf_posts` SET `post` = REPLACE( post, 'localhost/ipb', 'site.ru' ) UPDATE `ibf_skin_cache` SET `cache_content` = REPLACE( cache_content, 'localhost/ipb', 'site.ru' ) UPDATE `ibf_content_cache_posts` SET `cache_content` = REPLACE( cache_content, 'localhost/ipb', 'site.ru' ) Ссылки изменились и стали отображаться, но осталось чувство, что как-то по топорному решена проблема и не выльется ли в будущем это в какую-то новую проблему. Посоветуйте, пожалуйтса. Спасибо.