Рейтинг темы:
  • 0 Голос(ов) - 0 в среднем
  • 1
  • 2
  • 3
  • 4
  • 5
Too many connections
#1
После введения наработок через некоторое время работы сервер стал флудить ошибками о том, что было слишком много подключений к MySQL, так вот - в чем может быть проблема? Все MySQL запросы я закрываю следующим образом:

Код:
        Connection conq = null;
        try
        {
            conq = L2DatabaseFactory.getInstance().getConnection(conq);
            PreparedStatement statement = conq.prepareStatement("SELECT * FROM таблица");
            ResultSet rset = statement.executeQuery();
            while (rset.next())
            {        
                данный
            }
            rset.close();
            statement.close();
        }
        catch (SQLException e)
        {
            _log.warn("", e);
        }
        finally
        {
            L2DatabaseFactory.close(conq);
        }
Ведь в таком случае после выполнения функции запрос должен закрыть подключение?

Такие проверки у меня стоят в тасках, быть может, что таск не дает сделать закрытие?
Ответ
#2
какая версия джавы используется?
Ответ
#3
Параноидально-древняя.
Есть профайлеры, которые могут отследить какие конекты висят на мускуле, и какие последние запросы были выполнены через них, включайте голову
Ответ
#4
HastemaNS Написал:После введения наработок через некоторое время работы сервер стал флудить ошибками о том, что было слишком много подключений к MySQL, так вот - в чем может быть проблема? Все MySQL запросы я закрываю следующим образом:

Код:
        Connection conq = null;
        try
        {
            conq = L2DatabaseFactory.getInstance().getConnection(conq);
            PreparedStatement statement = conq.prepareStatement("SELECT * FROM таблица");
            ResultSet rset = statement.executeQuery();
            while (rset.next())
            {        
                данный
            }
            rset.close();
            statement.close();
        }
        catch (SQLException e)
        {
            _log.warn("", e);
        }
        finally
        {
            L2DatabaseFactory.close(conq);
        }
Ведь в таком случае после выполнения функции запрос должен закрыть подключение?

Такие проверки у меня стоят в тасках, быть может, что таск не дает сделать закрытие?

Используйте кеширование коннектов к mysql, ибо нехрен их открывать и закрывать 100 раз в секунду или сейчас это модно, чтобы подчеркнуть т.н. hiload process?
Так же еще можете заюзать кеширование запросов в базу данных, это было бы вообще ШИКАРНО. Особенно с учетом объединения запросов в один.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ
#5
Исходники построены на 1.6 версии Java, та же джава стоит и на серверной машине.

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

Проблема появилась именно после ввода изменений, но смотрел - везде используются закрытия. Может быть я делаю это неправильно?
Ответ
#6
HastemaNS Написал:Исходники построены на 1.6 версии Java, та же джава стоит и на серверной машине.

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

Проблема появилась именно после ввода изменений, но смотрел - везде используются закрытия. Может быть я делаю это неправильно?

Я уже написал выше, как можно решить Вашу проблему, плюсом закрыть КУЧУ дыр на l2j эмуляторе.
Не сложно представить модель падения Вашего сервера, из-за лавинообразной нагрузки на БД, т.к. в l2j используется еще то дерьмецо.

Ах да. L2j такая интересная штука, что коннекты там часто __вообще__ не закрываются и остаются висеть на весь life-цикл жизни сервера, т.к. всем срать на timeout'ы и аналоги keep alive.

Очень рекомендую для решения таких проблем прочитать мой пост выше или же написать хотя бы заглушку для работы с БД, которая будет собирать запросы и 1 раз, например в 10 минут, пихать их в БД. Это избавит от вашей проблемы и закроет дырку, что, например я, могу зайти на сервер и тупо положить его N-ым количеством ботов, которые будут выполнять "тяжелые" действия для БД или же действия, где коннект не закрывается.

Just do it.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ
#7
Pointer*Rage Написал:Используйте кеширование коннектов к mysql, ибо нехрен их открывать и закрывать 100 раз в секунду или сейчас это модно, чтобы подчеркнуть т.н. hiload process?
Так же еще можете заюзать кеширование запросов в базу данных, это было бы вообще ШИКАРНО. Особенно с учетом объединения запросов в один.

Таски вызываются раз в 5 минут, причем таблица состоит из 2(!) записей при 8 полях. Так что, думаю, перегрузки вообще никакой нет в этом.

Кстати, сейчас это самое дело произошло всего за часа 3, т.е даже скорость переполнения этими коннектами нестабильная. На серверной машине, а на локале вообще как было, так и работает.:ck:Я в панике.

UPD: Возможно Вы и правы, но на данный момент время очень ограничено, т.к сервер уже запущен, поэтому не могу задаться переписанием всей сборки. Думаю, что проблема, все таки, именно в моем коде. Т.к раньше ничего подобного не было.

UPD2: Действительно - коннекты не закрываются и остаются висеть в Sleep, но как так я вообще не понимаю, ведь в моих дополнениях везде указано закрытие процесса после выполнения. :negodue:

UPD3: Нагуглил следующее - добавить в настройки mysql:
Код:
interactive_timeout = 1000
wait_timeout = 1000
Но боюсь не будет ли проблем с сервером? По идее это должно просто закрывать Sleep процессы, а эти процессы висят в простом ожидании. Значит не должно повлиять на работу сервера и не будет захламлять соединения. Ведь так?
Ответ
#8
Цитата:Но боюсь не будет ли проблем с сервером?
1. куда _уже_ хуже?
2. вы знаете, что сделали, поэтому если вдруг станет _еще_ хуже - то вернете назад

Делайте и эксперементируйте, постоянно спрашивая - трудно будет самому
Ответ
#9
Я не думаю, что проблема именно в Вашем коде Smile Попробуйте сменить пул потоков для работы с БД или поиграться с настройками (например выключить кеширование, если оно включено, т.к. может работать криво). Хотя бы порыть javadoc вашей библиотеки.

А что там переписывать? Smile
Просто делаем перегрузку стандартного жаба-класса Connection, его имплементации в пуле, или же тупо хукаем создание коннектов и их клоус с текстом запроса. Ловим, ничего не отсылаем в БД и кладем в кеш. Ставим таску на 10 минут по заливке скопившихся запросов кеша в БД. Profit.
m0nster.art - clear client patches, linkz to utils & code.
Гадаю по капче.
Ответ
#10
Pointer*Rage Написал:Я не думаю, что проблема именно в Вашем коде Smile Попробуйте сменить пул потоков для работы с БД или поиграться с настройками (например выключить кеширование, если оно включено, т.к. может работать криво). Хотя бы порыть javadoc вашей библиотеки.

А что там переписывать? Smile
Просто делаем перегрузку стандартного жаба-класса Connection, его имплементации в пуле, или же тупо хукаем создание коннектов и их клоус с текстом запроса. Ловим, ничего не отсылаем в БД и кладем в кеш. Ставим таску на 10 минут по заливке скопившихся запросов кеша в БД. Profit.

Попробовал слип процессы пообрубать, начали выплывать ошибки, особенно с вещами. Видимо, там необходимо постоянное соединение с БД.

А если делать раз в 10 минут, то будет ведь беда, если сервер крашнется.

Еще появился вопрос - посмотрел на маршруты ходящих нпц - там, какой то, механизм, похоже прогружает всю таблицу в память? И MySQL не используется в дальнейшем, как я понял?

А вообще, спасибо за советы, покопаю в этом направлении, и правда не к чему перегружать MySQL. Просто сейчас сервер уже запущен, поэтому у меня эти ошибки вызывают некоторую панику, прошу простить за обилие вопросов.
Ответ


Перейти к форуму:


Пользователи, просматривающие эту тему: 5 Гость(ей)