Колян 2 Опубліковано: 2007-07-09 12:03:34 Share Опубліковано: 2007-07-09 12:03:34 Ну допустим пхп коннектиться и дисконнектиться к серверу мускуля если тот же на той же машине, она не нагружена за примерно 0,0001-0,0003 сек. Вам решать). Ну или хотябы не каждый запрос, а блок запросов. Для того, чтобы не держать соединение. Как по мне, так держать соединение постоянно бессмысленно. Возможно, на какие-то 20% систему при большом кол-ве юзеров, которые активно качают, и так далее будет нагружать больше чем в предыдущем, зато должно быть надежнее. Ссылка на сообщение Поделиться на других сайтах
Cell 7 Опубліковано: 2007-07-09 17:52:51 Share Опубліковано: 2007-07-09 17:52:51 Ну допустим пхп коннектиться и дисконнектиться к серверу мускуля если тот же на той же машине, она не нагружена за примерно 0,0001-0,0003 сек. Вам решать). Ну или хотябы не каждый запрос, а блок запросов. Для того, чтобы не держать соединение. Как по мне, так держать соединение постоянно бессмысленно. Возможно, на какие-то 20% систему при большом кол-ве юзеров, которые активно качают, и так далее будет нагружать больше чем в предыдущем, зато должно быть надежнее. Да причем тут php? :-0 Коннект осуществляет сам stg и пишет туда данные, поэтому нет ничего проще чем сделать простой sql запрос типа SELECT * FROM users WHERE user="vasya" каждые скажем NN секунд и проблема будет решена сама собой! Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-09 18:15:35 Share Опубліковано: 2007-07-09 18:15:35 Не решить эту проблему таким способом. Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. И не возвращает ничего в ответ... либо возвращает 0. А раз вернулся 0, то запрос считается выполненным... со всеми вытекающими. Имхо, надо отказываться от постоянного соединения в пользу варианта с: подключился - запрос - ответ - отключился Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-09 18:35:19 Share Опубліковано: 2007-07-09 18:35:19 Не решить эту проблему таким способом.Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. И не возвращает ничего в ответ... либо возвращает 0. А раз вернулся 0, то запрос считается выполненным... со всеми вытекающими. Имхо, надо отказываться от постоянного соединения в пользу варианта с: подключился - запрос - ответ - отключился Ну либо так. Но держать соединение постоянно это не есть хорошо. Зачем просто? У меня с пхп небыло никогда такого, шоб мускуль не возвращал результат. Почему тут? Не знаю, хотоя может из-за того, что соединение и висит! Ссылка на сообщение Поделиться на других сайтах
platerx 0 Опубліковано: 2007-07-09 18:48:33 Share Опубліковано: 2007-07-09 18:48:33 Итак сейчас я буду заниматься разработкой этого модуля, точнее исправлением ошибок. Есть несколько вопросов к тем кто тестировал его: 1) Через какое время после запуска модуля происходит потеря соединения ? 2) Зависит ли это время от нагрузки на stg ? По поводу таймаута могу сказать, что по умолчанию соединение рвёться если от клиента не было запросов в течении 8-ми часов. Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-09 23:33:17 Share Опубліковано: 2007-07-09 23:33:17 Вопрос к разработчикам: Сколько процессов-подключений должно быть в mysql если база работает только на биллинг т.е. подключается только стг, а в процессах куча соединений со статусом sleep ? Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. вот откуда баг с пропаданием личных данных пользователей (адреса, телефоны) Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-10 07:19:06 Share Опубліковано: 2007-07-10 07:19:06 Непредвиденно пропадает. Когда юзера меняешь. Бывает и статистику перестает писать. Настаиваю, не очень конечно в силу своих знаний, но все же настаиваю сделать так, как мы с Альферовым предложили. Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-10 08:21:36 Share Опубліковано: 2007-07-10 08:21:36 Я конечно не разработчик, но, в силу того, что изучал это место в исходниках, скажу: соединение должно быть одно. И не более! По крайней мере в версии 0.63. Уважаемый PlaterX! Насчет зависимости от нагрузки... не думаю что есть какая то зависимость. Во всяком случае, я не замечал. Что на пустом, что на боевом (~220 юзеров) - одинаковые симптомы. А симптомы следующие: Бывает так, что при запуске стг, уже после соединения с БД, запросы не выполняются. Т.е. баг этот не в том, что соединение замирает по истечении какого то времени, а в том, что модуль шлет запросы, а mysql-сервер их почему то не воспринимает. Если на mysql-сервере снять висящий (sleep) процесс, то тут же начинается запись в базу и все нормализуется. FreeBSD 5.4 MySQL 4.0.26 STG - последняя сборка. модуль - 0.63 Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-10 11:44:50 Share Опубліковано: 2007-07-10 11:44:50 Ну вот "лечение" висящих соединений по-моему и состоит в том, чтобы просто не держать постоянно соединение, да зачем просто? По-моему надежнее будет коннект-запрос-ответ-дисконнект! А вдруг коннект по непредвиденным причинам порвется? Вероятность разрыва коннекта при "коннект-запрос-ответ-дисконнект" намного меньше. ну и как всегда: фря 5.5 мускуль 5.хх(точно не помню) СТГ-последняя сборка от Макса модуль 0.63. Ссылка на сообщение Поделиться на других сайтах
zulu_Radist 856 Опубліковано: 2007-07-10 13:29:41 Share Опубліковано: 2007-07-10 13:29:41 Полностью согласен с мнением Коляна. gentoo 2006 ядро 2.6.19 мускуль 5.хх(тоже точно не помню))) STG - последняя сборка от Max mysql-модуль 0.63 Ссылка на сообщение Поделиться на других сайтах
Cell 7 Опубліковано: 2007-07-10 17:03:35 Share Опубліковано: 2007-07-10 17:03:35 Мущины.... мне кажется фигня это делать коннекты по мере необходимости... При больших объемах сервер будет занят только коннектами. В таком случаее необходимо делать какой-то дамп определенной величины и записывать его с определенной периодичностью - как это сделано в некоторых биллинговых системах.(это касается как минимум детальной статистики) Данные пользователей можно писать например сразу, ну и другую не тяжелую инфу. О периодичности: Сервер работает с 16 июня - падал 3 раза за это время, нагрузка 2 тестовых юзера (юзают не по детски). Linux, mysql 3.bla.bla (не сломалось - не чини! :-0) STG - последняя сборка. модуль - 0.63 Ссылка на сообщение Поделиться на других сайтах
Max 0 Опубліковано: 2007-07-10 17:10:20 Автор Share Опубліковано: 2007-07-10 17:10:20 Мущины.... мне кажется фигня это делать коннекты по мере необходимости... При больших объемах сервер будет занят только коннектами. В таком случаее необходимо делать какой-то дамп определенной величины и записывать его с определенной периодичностью - как это сделано в некоторых биллинговых системах.(это касается как минимум детальной статистики) Данные пользователей можно писать например сразу, ну и другую не тяжелую инфу.О периодичности: Сервер работает с 16 июня - падал 3 раза за это время, нагрузка 2 тестовых юзера (юзают не по детски). Linux, mysql 3.bla.bla (не сломалось - не чини! m.gif) STG - последняя сборка. модуль - 0.63 ИМХО +1 Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-11 07:55:45 Share Опубліковано: 2007-07-11 07:55:45 Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать? Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-11 08:18:36 Share Опубліковано: 2007-07-11 08:18:36 Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать? Стату сразу писать, и соединение постоянно держать. А разве в mysql нет KeepAlive для поддержания соединения... Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-11 08:26:59 Share Опубліковано: 2007-07-11 08:26:59 Я же описал, сколько коннект длится. Ну зачем постоянно держать стату в оперативке, а потом писать? Стату сразу писать, и соединение постоянно держать. А разве в mysql нет KeepAlive для поддержания соединения... Ну уже 2 месяца даже больше держим соединение, и чего добились? Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-11 08:42:58 Share Опубліковано: 2007-07-11 08:42:58 Колян, у меня СТГ на 2х серверах, 1 - рабочий, 2 - для извращений. Железо почти одинаковое, ос - gentoo 2007.0 и все собрано одинаково под x86. Стг ведет себя по разному на обоих машинах. Сейчас на обоих серверах mysql 5.x. На рабочем по 8-12 sleep поединений висит. На нерагруженном всего одного. Может быть с разными версиями mysql по разному надо этот реализовать. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-11 08:48:12 Share Опубліковано: 2007-07-11 08:48:12 А чем собственно предложенный мною метод плох? Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-11 08:55:56 Share Опубліковано: 2007-07-11 08:55:56 Представь, у тебя хотябы 10 активно качающих пользователей онлайн. Выстроилась очередь для зависи в базу, у каждого нужно списать со счета денюжку. Получается так мы подключаемся делаем операчии с первым пользователем, потом отключаемся - подключаемся делаем тоже самое для второго .. и т.д. Почти половина всего времени будет уходить на установку соединения с базой. Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-11 09:23:25 Share Опубліковано: 2007-07-11 09:23:25 Ну веб-сайты как то без allow_persistent работают же. И нет у них проблем с соединением/отсоединением. А запросов там поболе будет, ведь так? Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-11 10:54:03 Share Опубліковано: 2007-07-11 10:54:03 Там от скорости доступа к базе изменится время получения пользователем странички. А тут биллинг (серьезные данные, от потери которых можно хорошо влететь на деньги). Вообще зачем придумали базу данных ? может для того чтобы отказаться от дисковых операций и писать все и быстро. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-11 12:16:43 Share Опубліковано: 2007-07-11 12:16:43 Представь, у тебя хотябы 10 активно качающих пользователей онлайн. Выстроилась очередь для зависи в базу, у каждого нужно списать со счета денюжку. Получается так мы подключаемся делаем операчии с первым пользователем, потом отключаемся - подключаемся делаем тоже самое для второго .. и т.д. Почти половина всего времени будет уходить на установку соединения с базой. Лучше надежно чем быстро. Если тачка не тянет - *2 оперативки и проц помощнее, надежность превыше всего. Ссылка на сообщение Поделиться на других сайтах
Cell 7 Опубліковано: 2007-07-11 16:15:50 Share Опубліковано: 2007-07-11 16:15:50 Грошь цена этому всему. Надо делать правильно - а не так как проще. Нет никакой проблемы делать дисковый дамп и скажем раз в N минут записывать его в базу.(парсить конечно придется а это не есть гуд но как вариант). Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-11 16:58:24 Share Опубліковано: 2007-07-11 16:58:24 Грошь цена этому всему. Надо делать правильно - а не так как проще. Нет никакой проблемы делать дисковый дамп и скажем раз в N минут записывать его в базу.(парсить конечно придется а это не есть гуд но как вариант). Да о каком дисковом дампе речь может идти? Парсить... Коннект с СУБД будет быстрее, чем файло парсить. От файлов же отказываемся, зачем? Чтобы возвратиться? Зачем мускуль? Не просто так же наверное. А коннект можно по умному сделать, не на каждый запрос, а на блок запросов, которые подряд выполняются. Только чтобы более 2-х секунд не длилось, не нужно. Чем больше соединение держится, тем больше у него шансов зависнуть или оборваться. Ссылка на сообщение Поделиться на других сайтах
Render_ 0 Опубліковано: 2007-07-11 18:08:16 Share Опубліковано: 2007-07-11 18:08:16 off top Чем больше соединение держится, тем больше у него шансов зависнуть или оборваться. Шансы соединения оборваться 50/50, а вот вероятность разве что от погоды на луне не зависит. Почитай учебник по терверу =) Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-12 04:44:10 Share Опубліковано: 2007-07-12 04:44:10 шансы 50/50 - это как? Оборвется либо не оборвется? ))) Выскажу и свое имхо. Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр. Вы же предлагаете вернуться к этому же. Вариантов решения проблемы на сегодня два. 1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случае аварийного завершения работы сервера или еще чего то. 2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей. Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново. Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново. Это все нюансы. Главное определить принцип работы. Однако дампы... файлы... - не тот путь! ИМХО. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас