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

Тема в разделе "Counter-Strike: Global Offensive", создана пользователем seduvuyewo, 15 фев 2016.

  1. seduvuyewo

    seduvuyewo

    Сообщения:
    10
    Симпатии:
    0
    Все плагины написаны по 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
     
  2. Monomizer

    Monomizer Мимо пробегал Супер-модератор

    Сообщения:
    1.528
    Симпатии:
    201
  3. seduvuyewo

    seduvuyewo

    Сообщения:
    10
    Симпатии:
    0
    Тема актуальна и перенесена сюда.

    Продолжаем эксперименты.
    Сейчас выяснилось что от платформы проблема не зависит, на винде задержка имеет место быть. Что на 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);
     
    Последнее редактирование: 16 фев 2016
  4. oxoTHuk

    oxoTHuk

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

    Monomizer Мимо пробегал Супер-модератор

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

    gibs Фитиль народного волненья

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

    seduvuyewo

    Сообщения:
    10
    Симпатии:
    0
    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
    }
     
  8. gibs

    gibs Фитиль народного волненья

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

    seduvuyewo

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

    Осталось только подтвердить это на практике, но если кто-то лишний раз подтвердит мои догадки - буду признателен)
     
    Последнее редактирование: 17 фев 2016
  10. filipok

    filipok

    Сообщения:
    73
    Симпатии:
    8
    Имел такие же лаги, как только запрос в БД стал "сложнее". Тут ответ, мою проблему решил ThreadQuery.
     
  11. gibs

    gibs Фитиль народного волненья

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