21 час назад, UraSuper сказал:

если сразу  с запуском скрипта

Правильно сделал в clean_sql.sh  ?

#!/bin/sh

mysql --user=имя пользователя   --password=пароль    --database=имя базы -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";

exit 0

Зашел в дминке в Инструмнты SGL, что то нет очистки в данных таблицах.  

Наверно Cron надо включить в админке и настроить, как настроить кто подскажет подробно, еще не сталкивался с этим?

В 08.06.2017 в 23:32, nikitapo сказал:

в панели моего хостинга продолжает расти и с примерно

панель хостинга может и врать. Это раз.

Два -  просто очищать растущий core_log  глупо. Надо ошибки исправлять, а не удалять сообщения об ошибках. Если он растет, значит на сайте куча ошибок, на которые ты забиваешь. Вот , например, мой core_log со стандартным интервалом очистки 30 дней. И то там почти все ошибки, что facebook долго не отвечает. Размер 1 Мб.

Три.  Здесь какие значения стоят -- Advanced Configuration -> Data Storage ??

3 часа назад, Helios сказал:

TRUNCATE sql_core_acp_search_index; TRUNCATE sql_core_search_index;

Верх идиотизма очищать поисковые индексы

13 минут назад, kgb сказал:

Верх идиотизма очищать поисковые индексы

Пока ни чего очищается) эти примеры выше скинули в общем скрипте. 

Это тоже не надо очищать, подскажите? TRUNCATE sql_core_search_index_item_map

58 минут назад, Helios сказал:

Пока ни чего очищается) эти примеры выше скинули в общем скрипте. 

Это тоже не надо очищать, подскажите? TRUNCATE sql_core_search_index_item_map

Да, тоже не стоит очищать

1 час назад, Helios сказал:

подскажите

Что за болезнь такая, очищать. Все что можно очищать,  все настраивается в админке. То, что еще можно очистить - не скажу, нечего туда лезть, если не понимаешь что делаешь.  Вот ты удалил бы core_acp_search_index - и все нахрен, поиск в админке не работает.  Не занимайтесь херней

В 16.06.2017 в 12:04, Helios сказал:

Правильно сделал в clean_sql.sh  ?

#!/bin/sh

mysql --user=имя пользователя   --password=пароль    --database=имя базы -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";

exit 0

Зашел в дминке в Инструмнты SGL, что то нет очистки в данных таблицах.  

Наверно Cron надо включить в админке и настроить, как настроить кто подскажет подробно, еще не сталкивался с этим?

скрипт незапускается в таких случаях как...

1- не настроен его Cron запуск

2- права отсутствуют у скрипта на группу или на запуск ключ -x в правах доступа

3-вы не верно указали или название базы или пароль (иногда если в пароле есть непечатные знаки типа %&*  - их треба закрывать символом $ впереди. Т.е. в пароле Gh%kdf*5&^ нужно перед не печатным знаком ставить $ - Gh$%kdf$*5&$^ - ...более детально про не печатные символы уточняйте у вашего хостинг провайдера, от типа ОС они либо разрешены или запрещены в прямом использовании при вызове в скриптах, обычно FreeBSD капризничает)

4-создали скрипт,положили в корень, прописали в кроне...возьми и проверь тупо в командной строке SSH или bash запуск его вручную. Если запустится ... то ты увидишь его работу, если ошибка - то увидишь код ошибки. 

И никакого нет в этом идиотизма. Для каждых задач есть решение оптимальное. Просто кто с этим не сталкивался, тот и пишет что это все бред. Просто у них посещаемость 1000 человек. И нет проблемы такой. А есть популярные и раскрученные форумы...где логи и прочая нечесть растет как на дрожжах, и дело там не в том, что логи пишутся когда ошибки в неверных настройках. В IPS 4 там особо то и настраивать нечего. Система защищена от дураков. Поэтому если есть проблема такая - вот решение как описал выше. Если нет, то и читать пост и комментировать не стоит.

Лично я так и делаю...если тема меня не касается, не нужно писать что все решения которые предложены вопрошающему - бред или идиотизм. Просто пройди мимо и займись своими делами.

Всем удачи)

13 минут назад, sergey81 сказал:

И никакого нет в этом идиотизма.

Есть, а настаивание на идиотизме - идиотизм в квадрате.

Еще раз повторяю для тех, кто полностью в танке - sql_core_acp_search_index и sql_core_search_index - это поисковые индексы.  Очищаешь их, и перестают работать поиск, ленты активновности и т.д.. И если общий поиск еще можно перестроить, то поиск по админке формируется при установки приложений.

И не надо ляля про логи.  Выше я привел скрин своего core_log , который у ТС растет "как  на дрожжах" . 1 мб за месяц при посещаемости 7 - 15 т. чек в сутки.  Чего это он не растет, так же как и не растут другие логи? Что я делаю не так, а?

Кроме того, все логи очищаются автоматисчески, для этого не надо запускать отдельный скрипт.

25 минут назад, sergey81 сказал:

Поэтому если есть проблема такая - вот решение как описал выше

Это не решение проблемы, это подавление сообщений о проблеме.  Проблема то остается и рано или поздно боком может выйти

8 минут назад, kgb сказал:

Есть, а настаивание на идиотизме - идиотизм в квадрате.

Еще раз повторяю для тех, кто полностью в танке - sql_core_acp_search_index и sql_core_search_index - это поисковые индексы.  Очищаешь их, и перестают работать поиск, ленты активновности и т.д.. И если общий поиск еще можно перестроить, то поиск по админке формируется при установки приложений.

И не надо ляля про логи.  Выше я привел скрин своего core_log , который у ТС растет "как  на дрожжах" . 1 мб за месяц при посещаемости 7 - 15 т. чек в сутки.  Чего это он не растет, так же как и не растут другие логи? Что я делаю не так, а?

Кроме того, все логи очищаются автоматисчески, для этого не надо запускать отдельный скрипт.

Это не решение проблемы, это подавление сообщений о проблеме.  Проблема то остается и рано или поздно боком может выйти

это уже другой разговор. если не решение - то предлагайте идеи. а не кидайтесь выражением типа мы идиоты тут сидим. 

Что конкретно вы предлагаете если растет база SQL в час на 2 Гб ? вы с этим сталкивались? искали этому решение? или просто сидите тут комментите на злобу дня?

28 минут назад, sergey81 сказал:

Что конкретно вы предлагаете если растет база SQL в час на 2 Гб

Что я должен предложить? Я уже писал, смотреть, что и почему растет и исправлять ошибки. С ничего ничего расти не будет

 

 

 

 

15 минут назад, kgb сказал:

Что я должен предложить? Я уже писал, смотреть, что и почему растет и исправлять ошибки. С ничего ничего расти не будет

 

 

 

 

вот и мы...посмотрели ...посмотрели и нашли решение! о чем собственно и поделились здесь с товарищем. Раз он боле не пишет - значит решение наше помогло. А ваша демагогия...ну писанина и не боле. 

В будущем, старайтесь писать конкретику, а не свое отношение к тому или иному вопросу.

4 минуты назад, sergey81 сказал:

вот и мы...посмотрели ...посмотрели и нашли решение!

Да, да, у ТС растет core_log, а в него сыпятся сообщения об ошибках, вместо того, что бы сделать так, что бы ошибок не было, будем очищать логи. Охриненное решение ничего не скажешь. Заодно кеш очишать, что бы лишние запросы к базе генерировались. Индекс очистить, нахрена нам поиск, да? Про остальные логи я уже не говорю, вместо того, что бы в админке их очистку настроить, будем плодить сущности, свои скрипты создавать.

Прежде чем предлагать такие решения, мозг включать надо, а то ведь люди купятся, а потом пойдут вопросы, почему это не работает, да то не работает

 

36 минут назад, kgb сказал:

Да, да, у ТС растет core_log, а в него сыпятся сообщения об ошибках, вместо того, что бы сделать так, что бы ошибок не было, будем очищать логи. Охриненное решение ничего не скажешь. Заодно кеш очишать, что бы лишние запросы к базе генерировались. Индекс очистить, нахрена нам поиск, да? Про остальные логи я уже не говорю, вместо того, что бы в админке их очистку настроить, будем плодить сущности, свои скрипты создавать.

Прежде чем предлагать такие решения, мозг включать надо, а то ведь люди купятся, а потом пойдут вопросы, почему это не работает, да то не работает

 

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

7 минут назад, nikitapo сказал:

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

вообще то вопрос изначально был по ibf_core_cache

 

а core_cache это отнюдь не логи. с чего вы пишите что решение наше было логи очищать?

логи и поисковый индекс было указано как опция...что мол данное решение может включать очистку и этого и того и сего. А изначально речь шла о росте беспрецедентном ibf_core_cache.

Поэтому тут про внимательность стоит поговорить!

А если речь про рост  ibf_core_cache - тогда коллеги хочу конкретику услышать от вас. А про логи проехали...вопрос был не по этой теме.

В 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";

 

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

16 минут назад, nikitapo сказал:

Сильно растет  core_cache, в нем основная проблема

Я выше спросил

Цитата

 Здесь какие значения стоят -- Advanced Configuration -> Data Storage ??

 

1 минуту назад, nikitapo сказал:

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

фу блин вы со своими логами уже плешь проели. это как опция на будущее...для человека было указано, что мол скриптом такого характера, можно настраивать и другие задачи. ну как бы расширение функциональности скрипта. 

А вы эпопею развели про логи. Зацепились про логи и все. А решение именно для снижения и ликвидации безудержного роста именно таблиц ibf_core_cache  вы не предлагаете. Поэтому ваша писанина - ни о чем по существу вопроса!

Что конкретно вы предлагаете делать с ростом объема таблиц ibf_core_cache  ??? давайте...предложите. И еще, назовите например причину роста объема, или как искать причину роста...в логах? в каких...где искать...что смотреть.

А то так...ветер здесь гоняете.

5 минут назад, kgb сказал:

Я выше спросил

 

Вот такие: 

6 минут назад, nikitapo сказал:

Вот такие: 

а причем здесь эта настройка? если бы оно не верно было у товарища прописано...там бы явно были другие ошибки и косяки. Эта фича тут не причем!

вы знаете за что отвечает таблица ibf_core_cache ?? да или нет?

9 минут назад, sergey81 сказал:

фу блин вы со своими логами уже плешь проели. это как опция на будущее...для человека было указано, что мол скриптом такого характера, можно настраивать и другие задачи. ну как бы расширение функциональности скрипта. 

 

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

13 минут назад, nikitapo сказал:

Вот такие: 

Ну в принципе по умолчанию.

Если версия форума свежая ( в какой то из предыдущих были проблемы с core_cache ) посмотри задачи - clearcache не заблокирована? И если есть возможность, то лучше настроить крон на задачи. Если гостей мало, можно попробовать отключить кеширование для гостей (то что на скрине 30 сек. ) или поиграться временем кеширования.

 

19 минут назад, kgb сказал:

Ну в принципе по умолчанию.

Если версия форума свежая ( в какой то из предыдущих были проблемы с core_cache ) посмотри задачи - clearcache не заблокирована? И если есть возможность, то лучше настроить крон на задачи. Если гостей мало, можно попробовать отключить кеширование для гостей (то что на скрине 30 сек. ) или поиграться временем кеширования.

 

с другой стороны не пойму зачем вы гадаете если не знаете...напишите в тех поддержку и спросите что хранит таблица _core_cache

по нашим предположениям и поведению глюка связанного с быстрым ростом заполнения таблицы, вплоть до 4 Гб за час, можно сказать однозначно...что связано это с неким переполнением буфера. Т.е. обычная уязвимость видимо. Т.к. прямых зависимостей роста объема с посещаемостью, с разными хостинг площадками и прочими моментами, не наблюдается. Это может произойти в любой момент, в любом сервере...в любой версии ну кроме 3.4.6

25 минут назад, sergey81 сказал:

что хранит таблица _core_cache

Кеширует странички для гостей/ Включи QUERY_LOG зайди под гостем и посмотри.  Первый заход будет полтора десятка запросов  (или больше), обнови страничку и увидишь только один, что то типа

SELECT cache_value FROM `XXX_core_cache` AS `core_cache` WHERE cache_key='page_b7dd03f559686c0d09ea9668603e303d_1_1' AND cache_expire>1498327502

Поэтому вопрос скорее не почему растет, а почему не очищается.

12 минут назад, kgb сказал:

Кеширует странички для гостей/ Включи QUERY_LOG зайди под гостем и посмотри.  Первый заход будет полтора десятка запросов  (или больше), обнови страничку и увидишь только один, что то типа

SELECT cache_value FROM `XXX_core_cache` AS `core_cache` WHERE cache_key='page_b7dd03f559686c0d09ea9668603e303d_1_1' AND cache_expire>1498327502

Поэтому вопрос скорее не почему растет, а почему не очищается.

ну очищаться очищается все как настроено в журналах логов. 31 или 1 день...это не принципиально. Тут речь о том, что за час..за 1 час объем этой таблицы растет до 4 Гигабайт. Это первое

Второе, если это связано с авторизацией..и входом...значит корни уходят в неподтвержденные какие-то попытки входа. Т.е. возможно кто-кто сканером или спам системой, которая автоматически должна публиковать мусор и спам на форумах (там где нет capcha) ... вот именно с этим думаю и связано. Попытки несанкционированной автоматизированной авторизации на форуме и вызывают переполнение таблицы. А очиститься она и может сама..но не чаще  1 раза в сутки, как позволяют настройки конфигурации IPS. А за сутки...ба-ба и у вас уже 500 гигабайт таблица будет))

 

Кто согласен с таким предположением?

36 минут назад, sergey81 сказал:

ну очищаться очищается все как настроено в журналах логов. 31 или 1 день...это не принципиально.

Причем здесь настройки очистки логов и core_cache? Ты что то прыгаешь с одного на другое.  За очистку core_cache clearcache отвечает.

42 минуты назад, sergey81 сказал:

Второе, если это связано с авторизацией..и входом...значит корни уходят в неподтвержденные какие-то попытки входа.

Это не связано с авторизацие. Написано же - это кеширование содержимого для гостей. Зашел гость, страничка собралась "по кусочкам", отобразилась и записалась в core_cache. Следующему гостю страничку уже не собирают "по кусочкам" а выдают целиком из core_cache. Все.

21 час назад, kgb сказал:

Ну в принципе по умолчанию.

Если версия форума свежая ( в какой то из предыдущих были проблемы с core_cache ) посмотри задачи - clearcache не заблокирована? И если есть возможность, то лучше настроить крон на задачи. Если гостей мало, можно попробовать отключить кеширование для гостей (то что на скрине 30 сек. ) или поиграться временем кеширования.

 

 

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