Создавать 600 потоков, грузящих систему на 100% на 4-8-16-32 ядерной машине бессмысленно, твои потоки порвут сервак на клочки в битве за ресурсы. То как ты решаешь данную проблему: для одного коннекта все равно у тебя запросы будут исполняться последовательно, а твои потоки будут просто ждать пока предыдущий запрос выполняется, при этом бессмысленно отжирая памыть и периодически грузя процессор при просыпании.
Необходим пул воркеров: создаёшь к примеру N воркеров, каждый из которых имеет свооё соединение с базой данных, у каждого воркера есть очередь запросов. Задача воркера: взял запрос из очереди, отправил базе, взял запрос отправил и тд. И соответственно пришла инфа от пользователя - формируешь SQL запрос отдаёшь воркеру, у которого самая короткая очередь к примеру. С числом N можно поиграться, чтобы добаться лучшей производительности.
Если делаешь на питоне, то стоит всё таки воркеры делать отдельными процессами, а не потоками, хотя я с питоном на вы, и можно ли в нём данными между процессами кидаться я не знаю. Почитай третью ссылку эдворда, там про эмулюцию многопоточности в питоне расписано.
Вообще задача довольно интересная, но я бы её решал на си, там куда шире простор для оптимизации и многопоточность настоящая =)
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → Python → python, postgres и многопоточность
python, postgres и многопоточность
Страницы: ← Предыдущая страница →
-
Сообщения:
574
Репутация:
N
Группа:
Джедаи
-
Сообщения:
435
Репутация:
N
Группа:
Джедаи
22 июня 2012 г. 3:08, спустя 15 часов 11 минут 27 секунд
Задача-то какая в итоге? Можно поподробнее? Зачем threading вообще? Сколько запросов в секунду надо делать? -
Сообщения:
23
Репутация:
N
Группа:
Кто попало
22 июня 2012 г. 4:21, спустя 1 час 13 минут 33 секунды
Задача-то какая в итоге? Можно поподробнее? Зачем threading вообще? Сколько запросов в секунду надо делать?
Задачу я описал двумя постами ранее подробнее некуда. Если имеются конкретные вопросы, с удовольствием отвечу. -
Сообщения:
435
Репутация:
N
Группа:
Джедаи
22 июня 2012 г. 5:46, спустя 1 час 25 минут 7 секунд
Задача-то какая в итоге? Можно поподробнее? Зачем threading вообще? Сколько запросов в секунду надо делать?
Задачу я описал двумя постами ранее подробнее некуда. Если имеются конкретные вопросы, с удовольствием отвечу.
Слушай, ну если я спрашиваю - значит хуёво описал. Тебе помощь нужна или нет?
1. Сколько запросов в секунду к БД хочется организовать. Если 100к, то видимо postgres тут не помощник, хоть ты си будешь юзать, хоть ассемблер. Да и в любом случае - кей-валуе (redis) не обойтись для твоих задач? Ну или документно-ориентированной базой (couchDB, mongoDB)? Нужна транзакционность и будут сложные выборки?
2. Threading это, цитирую - "GOTO наших дней". В питоне он просто чтобы было. Проблема в I/O, городить потоки для её решения - иметь низкий КПД и все проблемы разделяемой памяти.
3. Если питон и только питон, тогда надо смотреть в сторону gevent - monkey.path_all() - если коннектор с постгресом на чистом питоне (socket питоновкий в итоге юзается), или вот пример обертки к psycopg2 https://bitbucket.org/denis/gevent/src/d0cf5d8a4ce0/examples/psycopg2_pool.py
4. Ну и если в системе сотни-тысячи сетевых запросов в секунду + тысячи вставок в БД и это всё растет… То питон не решение. Смотри в сторону erlang. -
Сообщения:
7958
Репутация:
N
Группа:
в ухо
22 июня 2012 г. 5:53, спустя 6 минут 6 секунд
еще мода на питон полностью не дошла, вы уже ерланг пихаете)Спустя 292 сек.вы фанатики, блин)
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
-
Сообщения:
435
Репутация:
N
Группа:
Джедаи
22 июня 2012 г. 6:57, спустя 47 минут 46 секунд
Ну вы даёте. Там про erlang в самом конце и при условии высоченных нагрузок. Формально ТС должно спасти переход на redis+gevent.
Ну, а если у него планируется через полгода тыщи ip и миллионы железок, то в одну машину он точно уже не влезет и надо будет это всё распределять. Ну вот тут то, уж точно… -
Сообщения:
7958
Репутация:
N
Группа:
в ухо
-
Сообщения:
23
Репутация:
N
Группа:
Кто попало
22 июня 2012 г. 9:56, спустя 2 часа 57 минут 14 секунд
Слушай, ну если я спрашиваю - значит хуёво описал. Тебе помощь нужна или нет?
1. Сколько запросов в секунду к БД хочется организовать. Если 100к, то видимо postgres тут не помощник, хоть ты си будешь юзать, хоть ассемблер. Да и в любом случае - кей-валуе (redis) не обойтись для твоих задач? Ну или документно-ориентированной базой (couchDB, mongoDB)? Нужна транзакционность и будут сложные выборки?
2. Threading это, цитирую - "GOTO наших дней". В питоне он просто чтобы было. Проблема в I/O, городить потоки для её решения - иметь низкий КПД и все проблемы разделяемой памяти.
3. Если питон и только питон, тогда надо смотреть в сторону gevent - monkey.path_all() - если коннектор с постгресом на чистом питоне (socket питоновкий в итоге юзается), или вот пример обертки к psycopg2 https://bitbucket.org/denis/gevent/src/d0cf5d8a4ce0/examples/psycopg2_pool.py
4. Ну и если в системе сотни-тысячи сетевых запросов в секунду + тысячи вставок в БД и это всё растет… То питон не решение. Смотри в сторону erlang.
Ок, попробуем еще раз.
1. Дело упирается, как мне кажется, не в производительность БД, а в запаздывании сбора данных - пока все железки по всем ip опросятся, проходит 2 часа. Коннектов, грубо прикинул, 5 в секунду. Зато открыто может быть несколько сотен коннектов одновременно. Там БД хорошо смаштабирована вертикально, упросил еще 2 сервера на проект - буду реализовывать горизонтальное масштабирование.
2. Производительность языка здесь опять же не главное. Как я уже сказал, время уходит на опрос большого кол-ва железок. Вот если потоки криво реализованы, то это другой вопрос, можно посмотреть на другие языки. Сейчас это все и вовсе на PHP работает, и неплохо работало, надо сказать, пока не понадобилось распараллелить сбор данных.
3. Спасибо, попробую.
4. Кстати, про erlang я уже думал с год назад, но тогда нагрузка была сильно меньше, и мне показалось это пушкой по воробьям. Возможно, стоит вернуться к нему.
Страницы: ← Предыдущая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!