nikitapo
-
Постов
13 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Загрузки
База знаний IPS Community Suite 4
База знаний IP.Board 3.x
Форумы
События
Магазин
Совместные покупки
Сообщения, опубликованные nikitapo
-
-
9 минут назад, sergey81 сказал:
фу блин вы со своими логами уже плешь проели. это как опция на будущее...для человека было указано, что мол скриптом такого характера, можно настраивать и другие задачи. ну как бы расширение функциональности скрипта.
Спасибо вам за помощь. Согласен, что к любому совету надо подходить осмысленно, но зачастую скрипт могут просто скопировать и запустить. То есть, принять решение проблемы в чистом виде. Кстати, вспомнил этот ролик. И смешно и грустно: https://www.youtube.com/watch?v=prD-2eVmFZc
-
5 минут назад, kgb сказал:
Я выше спросил
Вот такие:
-
В 04.06.2017 в 12:24, sergey81 сказал:
Братское сердце...возможно это, то что тебе нужно:
1- в корне своего хостинга создай clean_sql.sh
2- вставь туды этот код очистки некоторых таблиц
--------------------------
#!/bin/sh
mysql --user=name_user_sql --password=pass_sql_user -e "USE ips_base_name; TRUNCATE sql_core_acp_search_index; TRUNCATE sql_core_search_index; TRUNCATE sql_core_admin_logs; TRUNCATE sql_core_admin_login_logs; TRUNCATE sql_core_cache; TRUNCATE sql_core_log; TRUNCATE sql_core_moderator_logs; TRUNCATE sql_core_tasks_log; TRUNCATE sql_core_search_index_item_map";
Да, так и есть. Вам просто пишут о том, что в предложенном вами скрипте есть очистка поисковых логов, что не правильно.
-
36 минут назад, kgb сказал:
Да, да, у ТС растет core_log, а в него сыпятся сообщения об ошибках, вместо того, что бы сделать так, что бы ошибок не было, будем очищать логи. Охриненное решение ничего не скажешь. Заодно кеш очишать, что бы лишние запросы к базе генерировались. Индекс очистить, нахрена нам поиск, да? Про остальные логи я уже не говорю, вместо того, что бы в админке их очистку настроить, будем плодить сущности, свои скрипты создавать.
Прежде чем предлагать такие решения, мозг включать надо, а то ведь люди купятся, а потом пойдут вопросы, почему это не работает, да то не работает
Сильно растет core_cache, в нем основная проблема (причину не выявил пока), а про поисковые индексы согласен, не стоит их удалять.
-
В 04.06.2017 в 12:24, sergey81 сказал:
mysql --user=name_user_sql --password=pass_sql_user -e "USE ips_base_name; TRUNCATE sql_core_acp_search_index; TRUNCATE sql_core_search_index; TRUNCATE sql_core_admin_logs; TRUNCATE sql_core_admin_login_logs; TRUNCATE sql_core_cache; TRUNCATE sql_core_log; TRUNCATE sql_core_moderator_logs; TRUNCATE sql_core_tasks_log; TRUNCATE sql_core_search_index_item_map";
Зачистил по этой схеме и форум даже не упал.
Думаю, что может вот эти две таблицы тоже стоит включить для очистки: ibf_core_tags_cache, ibf_core_like_cache? На данный момент размер БД чуть меньше 300 Мб.
-
Продолждение к предыдущему посту. На мой вопрос о расхождении отображаемого размера таблиц в phpMyAdmin и размера БД в личном кабинете тех.поддержка дала ответ: "В базе данных ortipb есть много таблиц в формате InnoDB. Из-за особенностей этого типа реальный объём таблиц на сервере может различаться с показываемым в phpMyAdmin объёмом". ibf_core_cashe , в частности, в формате InnoDB, но до этого примерный объем таблиц в phpMyAdmin совпадал с отображаемым в личном кабинете. В связи с этим реализую способ, предложенный "sergey81", и посмотрю, что произойдет.
-
В 04.06.2017 в 14:00, kgb сказал:
Advanced Configuration -> Enable template disk caching
Мой краткий отчет спустя 3 дня.
1. Включил автоматическую очистку логов каждый день.
2. Выполнил "Advanced Configuration -> Enable template disk caching".
В таблицы данные за три дня. ibf_core_log стал очищаться каждый день, ibf_core_cashe раньше только постоянно рос, теперь стал самоочищаться примерно через день. Вроде бы все хорошо, но размер базы, который отображается в панели моего хостинга продолжает расти и с примерно 400 Мб вырос уже до 1Гб (картинка ниже). При этом не очень понимаю, где сокрыт этот размер, если просуммировать размер таблиц, то даже близко нет 1Гб (не исключаю, либо какой-то глюк на хостинге, либо я чего-то не знаю про размер БД). В любом случае еще раз всем спасибо за помощь!
-
3 часа назад, sergey81 сказал:
Братское сердце...возможно это, то что тебе нужно.
Да по твоему описанию очень похоже на то, что у меня сейчас происходит (максимально БД доходила до 2.5Гб очень быстрыми темпами). Попробую выполнить твои инструкции.
WOLF, спасибо за совет, уже включил автоматическую очистку логов каждый день, спустя 2-3 дня отпишусь в теме о результатах.
kgb, спасибо, с кэшом одназначно что-то не так. Попробую включить этот пункт в конфиге, посмортим, что будет.
-
14 часов назад, WOLF сказал:
Смотрите саму БД какая таблица там растет?
Спасибо за поддержку.
После вчерашней оптимизации БД увеличилась на 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 не находит подозрительных файлов.
-
8 часов назад, Respected сказал:
Можно сделать бэкап базы с помощью Sypex Dumper Pro 2.0.11, открыть базу в текстовом редакторе и заменить все адреса. После чего восстановить копию.
Спасибо за ответ. Хороший способ, но, как я понимаю, принципиально не отличается от того, что был предложен выше, то есть, ищем в базе и меняем. Я опасался, что может быть где-то не усмотрел дополнительные настройки, т.к с новой версией еще недостаточно разобрался. :)
-
Я видел, что подобные темы уже обсуждались, но не нашел совсем моего случая.
Кратко: У меня был форум 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' )
Ссылки изменились и стали отображаться, но осталось чувство, что как-то по топорному решена проблема и не выльется ли в будущем это в какую-то новую проблему. Посоветуйте, пожалуйтса.
Спасибо.
Увеличение объема БД на 10% в сутки
в Техническая поддержка Invision Community
Опубликовано
Форум очень старый, с 2010 года им почти никто не занимался, меня попросили восстановить и технически администрировать. Мне пришлось со 2 версии IPB (или даже с 1-ой) последовательно накатывать все обновления, дотащил форум до версии 3.3.4 так он и работал некоторое время (в размерах сильно не изменялся), пока не упал в следствие вирусной атаки на хостинг. Я восстановил форум и сделал все актуальные обновления до версии 4.1.19.4 (по факту я дотащил базу до этой версии о поставил чистый форум) и опять на время о нем забыл, пока мне не пришло сообщение, что места на хостинге почти не осталось, зашел, стал разбираться и выяснил, что очень быстро растет таблица core_cache (действительно забивает ее страницами в html разметке, только вместо кириллицы гонит кодировку типа "/428/658/454/324/"). Сам он не очищается, только в ручную (или задачей). За неделю размер базы разрастается до 3-4Гб при этом значительно увеличивается нагрузка на сервер (из 4% допустимых процентов может доходить до 40%), правда, здесь не могу однозначно сказать, что это взаимосвязано, но очень похоже. Спасибо, попробую поиграть с кешированием.