ФорумПрограммированиеPython → python, postgres и многопоточность

python, postgres и многопоточность

  • Nyaah

    Сообщения: 574 Репутация: N Группа: Джедаи

    Spritz 21 июня 2012 г. 14:56, спустя 1 час 27 минут 24 секунды

    Создавать 600 потоков, грузящих систему на 100% на 4-8-16-32 ядерной машине бессмысленно, твои потоки порвут сервак на клочки в битве за ресурсы. То как ты решаешь данную проблему: для одного коннекта все равно у тебя запросы будут исполняться последовательно, а твои потоки будут просто ждать пока предыдущий запрос выполняется, при этом бессмысленно отжирая памыть и периодически грузя процессор при просыпании.

    Необходим пул воркеров: создаёшь к примеру N воркеров, каждый из которых имеет свооё соединение с базой данных, у каждого воркера есть очередь запросов. Задача воркера: взял запрос из очереди, отправил базе, взял запрос отправил и тд. И соответственно пришла инфа от пользователя - формируешь SQL запрос отдаёшь воркеру, у которого самая короткая очередь к примеру. С числом N можно поиграться, чтобы добаться лучшей производительности.
    Если делаешь на питоне, то стоит всё таки воркеры делать отдельными процессами, а не потоками, хотя я с питоном на вы, и можно ли в нём данными между процессами кидаться я не знаю. Почитай третью ссылку эдворда, там про эмулюцию многопоточности в питоне расписано.

    Вообще задача довольно интересная, но я бы её решал на си, там куда шире простор для оптимизации и многопоточность настоящая =)
    Work, buy, consume, die
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 22 июня 2012 г. 6:08, спустя 15 часов 11 минут 27 секунд

    Задача-то какая в итоге? Можно поподробнее? Зачем threading вообще? Сколько запросов в секунду надо делать?
  • bRUtality

    Сообщения: 23 Репутация: N Группа: Кто попало

    Spritz 22 июня 2012 г. 7:21, спустя 1 час 13 минут 33 секунды


    Задача-то какая в итоге? Можно поподробнее? Зачем threading вообще? Сколько запросов в секунду надо делать?

    Задачу я описал двумя постами ранее подробнее некуда. Если имеются конкретные вопросы, с удовольствием отвечу.
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 22 июня 2012 г. 8: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.
  • Sinkler

    Сообщения: 7958 Репутация: N Группа: в ухо

    Spritz 22 июня 2012 г. 8:53, спустя 6 минут 6 секунд

    еще мода на питон полностью не дошла, вы уже ерланг пихаете)
    Спустя 292 сек.
    вы фанатики, блин)
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 22 июня 2012 г. 9:10, спустя 16 минут 58 секунд

    не говори!
    Сапожник без сапог
  • mathete

    Сообщения: 435 Репутация: N Группа: Джедаи

    Spritz 22 июня 2012 г. 9:57, спустя 47 минут 46 секунд

    Ну вы даёте. Там про erlang в самом конце и при условии высоченных нагрузок. Формально ТС должно спасти переход на redis+gevent.
    Ну, а если у него планируется через полгода тыщи ip и миллионы железок, то в одну машину он точно уже не влезет и надо будет это всё распределять. Ну вот тут то, уж точно…
  • Sinkler

    Сообщения: 7958 Репутация: N Группа: в ухо

    Spritz 22 июня 2012 г. 9:58, спустя 1 минуту 3 секунды

    лишь бы все распределить :D
  • bRUtality

    Сообщения: 23 Репутация: N Группа: Кто попало

    Spritz 22 июня 2012 г. 12: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 я уже думал с год назад, но тогда нагрузка была сильно меньше, и мне показалось это пушкой по воробьям. Возможно, стоит вернуться к нему.

Пожалуйста, авторизуйтесь, чтобы написать комментарий!