Доброго дня, господа.
Я чесс сказать не знаю как это правильно расписать, и что вам предоставить.
Начну по порядку. Вы обращайтесь если что
Периодически (каждые 6-8 часов виснет монитор модуля Inet на вкладке ошибки).
Помогает ребут процесса BGBillingServer.
По этому поводу создано обращение "[6222] [7.0] Проблема со входом в монитор модуля Inet"
Общались с Амиром, к общему знаменателю не пришли, поступило предложение проверить обновление MySQL'а т.к. стоит старая версия, и в момент зависания те же запросы которые обрабатывались быстро - начинают думать очень долго.
Были подозрения на query cache и т.д. и т.п.
Выгрузил из базы все что возможно, с тем чтобы она начала помещаться в памяти.
Поставил sync_binlog = 0, т.к. Амир за него спрашивал и я подумал что это имеет какое-то отношение к проблеме.
В момент зависания снял show status; и снял его сразу после рестарта процесса сервера биллинга.
Обнаружил высокие показатели Prepared_stmt_count.
Вывел в заббикс.
Получил следующую картиночку
Падение в 7:30 это как раз таки рестарт сервера. Резкое возрастание в 00:15 было не понятно с чем связано, т.к. в 00:15 нет заданий. В 00:10 есть начисление Npay абонплат.
Окей. Проблема начинает выявляться. Виснуть начинает когда достигает значения max_prepared_stmt_count, которое по умолчанию составляет 16382.
Погуглил по форуму нашел похожую проблему. Рекомендуют выключить кеширование запросов в db.url (cachePrepStmts=false).
Логично, что подобное закрытие глаз на проблему - не наши методы
И я даже не стал это проверять.Решил проверить начисление NPAY абонплат. Запустил задачу начисления абонплат. И вуаля.
Упало соответственно после ребута.
Следующее что пришло в голову из-за чего в течении дня могут так вырасти запросы - приход платежей. Значит будем плясать от этого и модуля NPAY.
Поднимаем тестовый сервер 7.0.
Голый, только с установленным модулем NPay.
Конфиг сервера - из доки.
Конфиг NPay - из рабочего сервера, с настроенным дебетовым режимом.
Дальше лень писать - смотрите видео.
