Лаг во время запроса к mysql

[seduvuyewo]

Все плагины написаны по threaded принципу.
Mysql сервер - Ubuntu Server 14 х64
При запуске CSGO сервера на Windows всё работает хорошо и гладко
При переносе CSGO сервера на тот же сервер где стоит Mysql во время запросов к mysql случаются лаги. lib32z1 установлен, без него запросы не работали вобще. Для запросов используется как FastQuery так и TQuery. Кол-во одновременных соединений выставлено в 1024, на деле 10-25. SM и MM стоят стабильные последние.

Т.е. проблема либо в том, что сервер mysql находится на том же хосте.
При указании в databases.cfg "localhost" - соединения вообще не устанавливаются, 127.0.0.1 - всё работает но есть лаги, указание mysql.sock - всё работает но есть лаги.
Либо проблема в 64 битной системе.

Характеристики серверов SSD, 4 Core, 16Gb Ram
загрузка процессора не более 6-8%, свободной оперативной памяти 12 GB

 

[Monomizer]

Повтор Соединение с mysql
тут нет слепых, смогут помочь - ответят

 

[seduvuyewo]

Тема актуальна и перенесена сюда.

Продолжаем эксперименты.
Сейчас выяснилось что от платформы проблема не зависит, на винде задержка имеет место быть. Что на x32 что на x64/ Значит проблема не в платформе, а либо в плагине который использует соединение с базой, либо в самой базе...

Лаг зависит от количества соединений

---
UPD 1 - Фигня эти рассказы про многопоточность, стоит запустить 10-20 SQL_FastQuery запросов подряд, как от многопоточности не остаётся и следа... Мда, разработчики удивили. Единственная разница theared запросов от non-threaded в том, что во время задержки при обычном запросе игра встанет колом (время замрёт), а во время многопоточного игра сделает вид что всё идёт гладко (время продолжит идти), а в момент получения ответа сделает крутой rollback(время вернётся на 1-2 секунды назад) к моменту отправки запроса. Вывод, можно не тратить силы на threaded запросы, выбор между "Игра лагнёт" или "Дёрнет назад"...

...очень сильно надеюсь что я тупой баран, и всё что я написал выше - фигня, но пока других результатов перекопав тонну исходников и примеров я не нашёл...

UPD 2 - Появилась идея, а может Fast_Query нифига и не threaded? Хотя должно быть FastQuery = SQL_TQuery(hDataBase, sQuery, null);

 

[oxoTHuk]

А настройки мускуль сервера на стоке, или менял чего?
У меня мускуль сервер на мвы отдельно стоит, с ним постоянно общаются 2 сервера 1.6 (32 и 22 человека в максимуме) и 1 сервер гоу 32 человека в максимуме.
Нагрузка ощутимая конечно (пришлось увеличить дефолтное значение одновременных подключений), но лагов на игровых серверах замечено не было. При этом, на локальной машине, где стоит мускуль, есть тестовый сервер 1.6, который часто запускается для тестирования плагинов. Но нем лагов нет. Так же, в ОБТ режиме работал SAMP сервер, примерно 10-15 человек. На лаги тоже не жаловались. Ну и какое-то время на этой же локальной машине, трудился сервер гоу на 22 человека, тоже не было проблем вроде.

 

[Monomizer]

тс, с каким плагином или веб обвязкой проблема?может плагин использует криво сбор отправки статистики. ибо даже не дефолте нормально должно быть. в руках несколько вдс с локальной базой и проблем никогда не возникало. от системы и разрядности точно не зависет
--- Добавлено позже ---
как в пример могу привести бывший сервер1,6 где был кривой плагин, который из базы 20000 игроков делал 7 запросов при подключении, что иопс диска забивало на максимум,что и вызывало лаги

 

[gibs]

Вот просто вопрос к ТС. А с чего ты вообще взял, что SQL_FastQuery выполняется в отдельном потоке? Это сказано хотя бы где-то в документации?
Это блокирующая основной поток функция. Выполняет запрос и игнорирует результат.

 

[seduvuyewo]

oxoTHuk
Количество одновременных соединений установлено в 900, ограничения кол-ва запросов с пользователя от имени которого происходит запрос снято. Тестировалось на PHP в цикле открывалось 899 соединений, они не закрывались до конца цикла, а потом они все продёргивались запросами в 100 потоков порождёнными дочерними процессами, тест проходил за 0.1874 секунды, выборка по актуальной базе. Так что с mysql проблем нет. Все настройки mysql изменялись, есть 1 сервер - на запись - 2 сервера(реплики) для чтения. На деле плагин устанавливает 3 соединения, первое делает 1 запрос в минуту, второе 10-25 запросов в начале раунда, третий делает 2 запроса в начале и в конце раунда.

Monomizer
Плагин написан самостоятельно, знаний в sp не много, но это компенсируется почти десятилетним стажем профессионального кодинга С, С++, Java, так что в sp чувствую себя довольно комфортно.
Код оптимизирован. лишних переменных не создаётся, если вызов функции повторяется возвращаемое значение сохраняется в переменную, повторный вызов убирается. Висящих хендлеров не оставляем. Обрывов соединений не наблюдается, mysql логирует все соединения, они происходят именно в том объёме в котором это ожидается, т.е. плагин ведёт себя на 100% предсказуемо, проблемы только с лагом во время mysql запроса. Среднее время выполнения самого тяжелого запроса на выборку по актуальной базе 0.00672, все индексы расставлены. отключал все плагины и все запросы выносил в отдельный плагин и прогонял каждый из них. Нет зависимости от сложности запроса, лаг зависит только от кол-ва этих запросов. Микро фриз при 1 запросе, заметный лаг при 20ти идущих друг за другом не ожидая завершения предыдущего.

gibs
Вот именно к этой мысли я кажется и шёл, похоже что утверждение FastQuery = SQL_TQuery(hDataBase, sQuery, null) не верно. И соответственно все запросы, даже те, у которых возврат результата не нужен, нужно переписать из FastQuery(hDataBase, sQuery)
в
SQL_TQuery(hDataBase, sQuery, nullCallback);
где
public nullCallback(Handle:owner, Handle:hndl, const String:error[], any:data)
{
// do nothing
}

 

[gibs]

gibs
Вот именно к этой мысли я кажется и шёл, похоже что утверждение FastQuery = SQL_TQuery(hDataBase, sQuery, null) не верно. И соответственно все запросы, даже те, у которых возврат результата не нужен, нужно переписать из FastQuery(hDataBase, sQuery)
в
SQL_TQuery(hDataBase, sQuery, nullCallback);
где
public nullCallback(Handle:owner, Handle:hndl, const String:error[], any:data)
{
// do nothing
}

Выводы? Ты должен был прочитать что именно делает эта функция, а не строить выводы.
ЗЫ: Функция, возвращающая значение не в коллбек ВСЕГДА является блокирующей.

 

[seduvuyewo]

ЗЫ: Функция, возвращающая значение не в коллбек ВСЕГДА является блокирующей.
Вот именно из-за того, что FastQuery ничего не возвращает, я и думал что она threaded.

Осталось только подтвердить это на практике, но если кто-то лишний раз подтвердит мои догадки - буду признателен)

 

[filipok]

а в момент получения ответа сделает крутой rollback(время вернётся на 1-2 секунды назад) к моменту отправки запроса.

Имел такие же лаги, как только запрос в БД стал "сложнее". Тут ответ, мою проблему решил ThreadQuery.

 

[gibs]

ЗЫ: Функция, возвращающая значение не в коллбек ВСЕГДА является блокирующей.
Вот именно из-за того, что FastQuery ничего не возвращает, я и думал что она threaded.

Осталось только подтвердить это на практике, но если кто-то лишний раз подтвердит мои догадки - буду признателен)

Она возвращает bool значение. И в описании ни слова про поток. Ты не думал, а старался угадать. После чего схватился за головушку.