Огромное количество коннектов к базе данных

ЕСТЬ РЕШЕНИЕ ЗАКРЫТО InstantCMS 2.X
#1 5 декабря 2017 в 17:39
На хостиге обратил внимание на жор памяти!
Спецы сообщили, что у меня более 2 млн. коннектов к базе (это при 200 посетителях в сутки) и рекомендовали узнать: не используются ли где-то в скриптах постоянные соединения к базе!
В связи с этим вопрос и к создателям Инстанта и к разработчикам дополнений:
Применяются ли где-то постоянные подключения к базе данных, как они могут накапливаться в сумме и как их сбрасывать средствами скрипта?

Кеширование на сайте отключено, Мемкеш на хостинге тоже вырублен.
#2 6 декабря 2017 в 09:07

что у меня более 2 млн. коннектов к базе

vikont
может за весь период, столько сервак не поддерживал бы😊На айхоре не всегда в саппорте на первой линии поймут вас😊смотреть статистику и логи.
версия какая? может спамеры ломятся регестрироваться?
#3 6 декабря 2017 в 09:57

Спецы сообщили

vikont

Кто они? Обычно когда спецы сообщают, то дают какие то фактические данные, например хотя бы скриншот состояния сервера mysql.
#4 6 декабря 2017 в 17:03

может за весь период, столько сервак не поддерживал бы

kirkr
Столько набирается менее чем за сутки!

Кто они? Обычно когда спецы сообщают, то дают какие то фактические данные, например хотя бы скриншот состояния сервера mysql.

letsgo
Специально по моей просьбе проверили как образуются соединения к базе данных и утверждают, что их плодит функция mysql_pconnect
Я ее обнаружил в одном единственном файле скрипта сайта /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

vikont
Интересно, как они это определили?

Fuze, может быть вы что то подскажите?

vikont
Подсказываю. В InstantCMS нет постоянных соединений. Соединение с базой закрывается сразу после окончания работы.

Я ее обнаружил в одном единственном файле скрипта сайта /system/libs/geshi/geshi/php.php

vikont
Это библиотека подсветки синтаксиса.

что это происходит из-за того, что скрипт по какой то причине не закрывает соединения при выходе пользователя или обрыве соединения.

vikont
Видимо потому, что сервер криво настроен.

Понаберут саппорт по объявлениям…
#7 7 декабря 2017 в 12:51

vikont:
что это происходит из-за того, что скрипт по какой то причине не закрывает соединения при выходе пользователя или обрыве соединения.
Видимо потому, что сервер криво настроен.

Fuze
Спасибо, сообщил… Кстати, это не у Айхора проблема...

Понаберут саппорт по объявлениям...

Fuze
Пожалел, не стал им так прямо...., но подвожу их к пониманию, что надо расти… laugh
#8 7 декабря 2017 в 17:17
vikont, отпишитесь, как выясните причину проблемы — любопытно очень
#9 7 декабря 2017 в 18:12
vikont, выложите php.ini и my.cnf
или сообщите сколько там max_execution_time
а может вы сами в htaccess php_value max_execution_time 10000000000000000000000000000000000000000 прописали? smile
Ну и боюсь даже предположить — а не в BRAINY ли дело?
Ну и посмотрите статистику у mysql.
#10 7 декабря 2017 в 18:37
vikont, стукнитесь в личку, я завтра могу помочь вам разобраться. Т.к. это туфта про незакрытые соединения.
#11 7 декабря 2017 в 21:12

vikont, отпишитесь, как выясните причину проблемы — любопытно очень

AndroS
Обязательно! Держу вопрос в режиме постоянного мониторинга статистики…
#12 7 декабря 2017 в 21:40

vikont, выложите php.ini и my.cnf
или сообщите сколько там max_execution_time

eoleg
Данный параметр вообще отсутствует в файле my.cnf
Напишите ваше предложение по настройке.

а может вы сами в htaccess php_value max_execution_time 10000000000000000000000000000000000000000 прописали?

eoleg
Шутник… smileКлавиатура не выдержит столько нулей бить… shock

Ну и боюсь даже предположить — а не в BRAINY ли дело?

eoleg
Как вариант, возможно! Они сейчас какие то супер срочные критические ошибки закрывают!

Ну и посмотрите статистику у mysql.

eoleg
Чего, чего, а логов у Брайни просто зашибись…
Каждый день отлавливаю любителей ломать рутовый вход по SSH
Может быть это заинтересует и что то прояснит, хотя вряд ли. Давал команду каждую минуту. По сути, заменили Мускул 5,6 на МариаДБ и стало чуток полегче. Судя по данным, База периодически ложится и тут же поднимается сбрасывая ниже показанные значения. Когда был последний сброс был 75 минут назад.
#13 7 декабря 2017 в 21:43

vikont, стукнитесь в личку, я завтра могу помочь вам разобраться. Т.к. это туфта про незакрытые соединения.

kirkr
Большое спасибо! Если до завтра проблема не рассосется, обязательно обращусь....
А то уши маленькие "лапша" не держится, устал поправлять… rofl
#14 8 декабря 2017 в 14:28
max_execution_time в php.ini
#15 8 декабря 2017 в 15:14

max_execution_time в php.ini

eoleg
Там и искал… пропустил...
max_execution_time = 120
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.