Разработка модуля MySQL

[Колян 2]

Ну допустим пхп коннектиться и дисконнектиться к серверу мускуля если тот же на той же машине, она не нагружена за примерно 0,0001-0,0003 сек. Вам решать). Ну или хотябы не каждый запрос, а блок запросов. Для того, чтобы не держать соединение. Как по мне, так держать соединение постоянно бессмысленно. Возможно, на какие-то 20% систему при большом кол-ве юзеров, которые активно качают, и так далее будет нагружать больше чем в предыдущем, зато должно быть надежнее.

[Cell 7]

Ну допустим пхп коннектиться и дисконнектиться к серверу мускуля если тот же на той же машине, она не нагружена за примерно 0,0001-0,0003 сек. Вам решать). Ну или хотябы не каждый запрос, а блок запросов. Для того, чтобы не держать соединение. Как по мне, так держать соединение постоянно бессмысленно. Возможно, на какие-то 20% систему при большом кол-ве юзеров, которые активно качают, и так далее будет нагружать больше чем в предыдущем, зато должно быть надежнее.

Да причем тут php? :-0

Коннект осуществляет сам stg и пишет туда данные, поэтому нет ничего проще чем сделать простой sql запрос типа SELECT * FROM users WHERE user="vasya" каждые скажем NN секунд и проблема будет решена сама собой!

[Alferov 0]

Не решить эту проблему таким способом.

Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. И не возвращает ничего в ответ... либо возвращает 0. А раз вернулся 0, то запрос считается выполненным... со всеми вытекающими.

 

Имхо, надо отказываться от постоянного соединения в пользу варианта с: подключился - запрос - ответ - отключился

[Колян 2]

Не решить эту проблему таким способом.

Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. И не возвращает ничего в ответ... либо возвращает 0. А раз вернулся 0, то запрос считается выполненным... со всеми вытекающими.

 

Имхо, надо отказываться от постоянного соединения в пользу варианта с: подключился - запрос - ответ - отключился

Ну либо так. Но держать соединение постоянно это не есть хорошо. Зачем просто? У меня с пхп небыло никогда такого, шоб мускуль не возвращал результат. Почему тут? Не знаю, хотоя может из-за того, что соединение и висит!

[platerx 0]

Итак сейчас я буду заниматься разработкой этого модуля, точнее исправлением ошибок. Есть несколько вопросов к тем кто тестировал его:

1) Через какое время после запуска модуля происходит потеря соединения ?

2) Зависит ли это время от нагрузки на stg ?

 

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

[Render_ 0]

Вопрос к разработчикам:

Сколько процессов-подключений должно быть в mysql если база работает только на биллинг т.е. подключается только стг, а в процессах куча соединений со статусом sleep ?

 

Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает.

вот откуда баг с пропаданием личных данных пользователей (адреса, телефоны)

[Колян 2]

Непредвиденно пропадает. Когда юзера меняешь. Бывает и статистику перестает писать. Настаиваю, не очень конечно в силу своих знаний, но все же настаиваю сделать так, как мы с Альферовым предложили.

[Alferov 0]

Я конечно не разработчик, но, в силу того, что изучал это место в исходниках, скажу: соединение должно быть одно. И не более!

По крайней мере в версии 0.63.

 

Уважаемый PlaterX!

Насчет зависимости от нагрузки... не думаю что есть какая то зависимость. Во всяком случае, я не замечал. Что на пустом, что на боевом (~220 юзеров) - одинаковые симптомы.

А симптомы следующие:

Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает.

Если на mysql-сервере снять висящий (sleep) процесс, то тут же начинается запись в базу и все нормализуется.

 

FreeBSD 5.4

MySQL 4.0.26

STG - последняя сборка.

модуль - 0.63

[Колян 2]

Ну вот "лечение" висящих соединений по-моему и состоит в том, чтобы просто не держать постоянно соединение, да зачем просто? По-моему надежнее будет коннект-запрос-ответ-дисконнект! А вдруг коннект по непредвиденным причинам порвется? Вероятность разрыва коннекта при "коннект-запрос-ответ-дисконнект" намного меньше. ну и как всегда:

фря 5.5

мускуль 5.хх(точно не помню)

СТГ-последняя сборка от Макса

модуль 0.63.

[zulu_Radist 856]

Полностью согласен с мнением Коляна.

 

gentoo 2006 ядро 2.6.19

мускуль 5.хх(тоже точно не помню)))

STG - последняя сборка от Max

mysql-модуль 0.63

[Cell 7]

Мущины.... мне кажется фигня это делать коннекты по мере необходимости... При больших объемах сервер будет занят только коннектами. В таком случаее необходимо делать какой-то дамп определенной величины и записывать его с определенной периодичностью - как это сделано в некоторых биллинговых системах.(это касается как минимум детальной статистики) Данные пользователей можно писать например сразу, ну и другую не тяжелую инфу.

О периодичности:

Сервер работает с 16 июня - падал 3 раза за это время, нагрузка 2 тестовых юзера (юзают не по детски).

Linux,

mysql 3.bla.bla (не сломалось - не чини! :-0)

STG - последняя сборка.

модуль - 0.63

[Max 0]

Мущины.... мне кажется фигня это делать коннекты по мере необходимости... При больших объемах сервер будет занят только коннектами. В таком случаее необходимо делать какой-то дамп определенной величины и записывать его с определенной периодичностью - как это сделано в некоторых биллинговых системах.(это касается как минимум детальной статистики) Данные пользователей можно писать например сразу, ну и другую не тяжелую инфу.

О периодичности:

Сервер работает с 16 июня - падал 3 раза за это время, нагрузка 2 тестовых юзера (юзают не по детски).

Linux,

mysql 3.bla.bla (не сломалось - не чини! m.gif)

STG - последняя сборка.

модуль - 0.63

ИМХО +1

[Колян 2]

Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать?

[Render_ 0]

Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать?

Стату сразу писать, и соединение постоянно держать. А разве в mysql нет KeepAlive для поддержания соединения...

[Колян 2]

Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать?

Стату сразу писать, и соединение постоянно держать. А разве в mysql нет KeepAlive для поддержания соединения...

Ну уже 2 месяца даже больше держим соединение, и чего добились?

[Render_ 0]

Колян, у меня СТГ на 2х серверах, 1 - рабочий, 2 - для извращений.

Железо почти одинаковое, ос - gentoo 2007.0 и все собрано одинаково под x86. Стг ведет себя по разному на обоих машинах. Сейчас на обоих серверах mysql 5.x. На рабочем по 8-12 sleep поединений висит. На нерагруженном всего одного. Может быть с разными версиями mysql по разному надо этот реализовать.

[Колян 2]

А чем собственно предложенный мною метод плох?

[Render_ 0]

Представь, у тебя хотябы 10 активно качающих пользователей онлайн. Выстроилась очередь для зависи в базу, у каждого нужно списать со счета денюжку. Получается так мы подключаемся делаем операчии с первым пользователем, потом отключаемся - подключаемся делаем тоже самое для второго .. и т.д. Почти половина всего времени будет уходить на установку соединения с базой.

[Alferov 0]

Ну веб-сайты как то без allow_persistent работают же. И нет у них проблем с соединением/отсоединением. А запросов там поболе будет, ведь так?

[Render_ 0]

Там от скорости доступа к базе изменится время получения пользователем странички. А тут биллинг (серьезные данные, от потери которых можно хорошо влететь на деньги). Вообще зачем придумали базу данных ? может для того чтобы отказаться от дисковых операций и писать все и быстро.

[Колян 2]

Представь, у тебя хотябы 10 активно качающих пользователей онлайн. Выстроилась очередь для зависи в базу, у каждого нужно списать со счета денюжку. Получается так мы подключаемся делаем операчии с первым пользователем, потом отключаемся - подключаемся делаем тоже самое для второго .. и т.д. Почти половина всего времени будет уходить на установку соединения с базой.

Лучше надежно чем быстро. Если тачка не тянет - *2 оперативки и проц помощнее, надежность превыше всего.

[Cell 7]

Грошь цена этому всему. Надо делать правильно - а не так как проще. Нет никакой проблемы делать дисковый дамп и скажем раз в N минут записывать его в базу.(парсить конечно придется а это не есть гуд но как вариант).

[Колян 2]

Грошь цена этому всему. Надо делать правильно - а не так как проще. Нет никакой проблемы делать дисковый дамп и скажем раз в N минут записывать его в базу.(парсить конечно придется а это не есть гуд но как вариант).

Да о каком дисковом дампе речь может идти? Парсить... Коннект с СУБД будет быстрее, чем файло парсить. От файлов же отказываемся, зачем? Чтобы возвратиться? Зачем мускуль? Не просто так же наверное. А коннект можно по умному сделать, не на каждый запрос, а на блок запросов, которые подряд выполняются. Только чтобы более 2-х секунд не длилось, не нужно. Чем больше соединение держится, тем больше у него шансов зависнуть или оборваться.

[Render_ 0]

off top

Чем больше соединение держится, тем больше у него шансов зависнуть или оборваться.

Шансы соединения оборваться 50/50, а вот вероятность разве что от погоды на луне не зависит. Почитай учебник по терверу =)

[Alferov 0]

шансы 50/50 - это как? Оборвется либо не оборвется? )))

 

Выскажу и свое имхо.

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

Вы же предлагаете вернуться к этому же.

 

Вариантов решения проблемы на сегодня два.

1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случае аварийного завершения работы сервера или еще чего то.

 

2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей.

Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново.

Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново.

Это все нюансы. Главное определить принцип работы.

 

Однако дампы... файлы... - не тот путь! ИМХО.