На хостиге обратил внимание на жор памяти!
Спецы сообщили, что у меня более 2 млн. коннектов к базе (это при 200 посетителях в сутки) и рекомендовали узнать: не используются ли где-то в скриптах постоянные соединения к базе!
В связи с этим вопрос и к создателям Инстанта и к разработчикам дополнений:
Применяются ли где-то постоянные подключения к базе данных, как они могут накапливаться в сумме и как их сбрасывать средствами скрипта?
Кеширование на сайте отключено, Мемкеш на хостинге тоже вырублен.
Огромное количество коннектов к базе данных
ЕСТЬ РЕШЕНИЕ
ЗАКРЫТО
InstantCMS 2.X
#2
6 декабря 2017 в 09:07
может за весь период, столько сервак не поддерживал бы😊На айхоре не всегда в саппорте на первой линии поймут вас😊смотреть статистику и логи.что у меня более 2 млн. коннектов к базе
версия какая? может спамеры ломятся регестрироваться?
#3
6 декабря 2017 в 09:57
Спецы сообщили
Кто они? Обычно когда спецы сообщают, то дают какие то фактические данные, например хотя бы скриншот состояния сервера mysql.
Сегодня в 18:28
Столько набирается менее чем за сутки!может за весь период, столько сервак не поддерживал бы
Специально по моей просьбе проверили как образуются соединения к базе данных и утверждают, что их плодит функция mysql_pconnectКто они? Обычно когда спецы сообщают, то дают какие то фактические данные, например хотя бы скриншот состояния сервера mysql.
Я ее обнаружил в одном единственном файле скрипта сайта /system/libs/geshi/geshi/php.php, а в нем в одной единственной строчке 'mysql_num_fields','mysql_num_rows','mysql_pconnect','mysql_ping',
И утверждают, что это происходит из-за того, что скрипт по какой то причине не закрывает соединения при выходе пользователя или обрыве соединения.
#5
7 декабря 2017 в 01:34
Fuze, может быть вы что то подскажите?
Или дайте инфу куда ткнуть носом спецов, которая их убедит, что они не правы!
Или дайте инфу куда ткнуть носом спецов, которая их убедит, что они не правы!
#6
7 декабря 2017 в 09:22
Интересно, как они это определили?проверили как образуются соединения к базе данных и утверждают, что их плодит функция mysql_pconnect
Подсказываю. В InstantCMS нет постоянных соединений. Соединение с базой закрывается сразу после окончания работы.Fuze, может быть вы что то подскажите?
Это библиотека подсветки синтаксиса.Я ее обнаружил в одном единственном файле скрипта сайта /system/libs/geshi/geshi/php.php
Видимо потому, что сервер криво настроен.что это происходит из-за того, что скрипт по какой то причине не закрывает соединения при выходе пользователя или обрыве соединения.
Понаберут саппорт по объявлениям…
#7
7 декабря 2017 в 12:51
Спасибо, сообщил… Кстати, это не у Айхора проблема...vikont:
что это происходит из-за того, что скрипт по какой то причине не закрывает соединения при выходе пользователя или обрыве соединения.
Видимо потому, что сервер криво настроен.
Пожалел, не стал им так прямо...., но подвожу их к пониманию, что надо расти…Понаберут саппорт по объявлениям...
#8
7 декабря 2017 в 17:17
vikont, отпишитесь, как выясните причину проблемы — любопытно очень
vikont, выложите php.ini и my.cnf
или сообщите сколько там max_execution_time
а может вы сами в htaccess php_value max_execution_time 10000000000000000000000000000000000000000 прописали?
Ну и боюсь даже предположить — а не в BRAINY ли дело?
Ну и посмотрите статистику у mysql.
или сообщите сколько там max_execution_time
а может вы сами в htaccess php_value max_execution_time 10000000000000000000000000000000000000000 прописали?
Ну и боюсь даже предположить — а не в BRAINY ли дело?
Ну и посмотрите статистику у mysql.
#10
7 декабря 2017 в 18:37
vikont, стукнитесь в личку, я завтра могу помочь вам разобраться. Т.к. это туфта про незакрытые соединения.
#11
7 декабря 2017 в 21:12
Обязательно! Держу вопрос в режиме постоянного мониторинга статистики…vikont, отпишитесь, как выясните причину проблемы — любопытно очень
#12
7 декабря 2017 в 21:40
Данный параметр вообще отсутствует в файле my.cnfvikont, выложите php.ini и my.cnf
или сообщите сколько там max_execution_time
Напишите ваше предложение по настройке.
Шутник…а может вы сами в htaccess php_value max_execution_time 10000000000000000000000000000000000000000 прописали?
Клавиатура не выдержит столько нулей бить… 
Как вариант, возможно! Они сейчас какие то супер срочные критические ошибки закрывают!Ну и боюсь даже предположить — а не в BRAINY ли дело?
Чего, чего, а логов у Брайни просто зашибись…Ну и посмотрите статистику у mysql.
Каждый день отлавливаю любителей ломать рутовый вход по SSH
Может быть это заинтересует и что то прояснит, хотя вряд ли. Давал команду каждую минуту. По сути, заменили Мускул 5,6 на МариаДБ и стало чуток полегче. Судя по данным, База периодически ложится и тут же поднимается сбрасывая ниже показанные значения. Когда был последний сброс был 75 минут назад.
Большое спасибо! Если до завтра проблема не рассосется, обязательно обращусь....vikont, стукнитесь в личку, я завтра могу помочь вам разобраться. Т.к. это туфта про незакрытые соединения.
А то уши маленькие "лапша" не держится, устал поправлять…
#14
8 декабря 2017 в 14:28
max_execution_time в php.ini
Там и искал… пропустил...max_execution_time в php.ini
max_execution_time = 120