ээ... а сейчас к мусклю чем подключение идет-то?

@pragus может это и вариант. Не знаю. Просто я считал, что треды на python как-то не принято использовать из-за всяких GIL

gil отпускается на i/o и сишных расширениях

начать может надо с изучения метрик - искать узкие места

это, кстати, да, но мы же не думаем, что топик стартер просто так на базу грешит, без причины...

ээ... а сейчас к мусклю чем подключение идет-то?

sqlalchemy

gil отпускается на i/o и сишных расширениях

при чем тут gil и io? gil отпускается, когда передается управление другому треду. на блокирующем io этого не происходит.

sqlalchemy не работает с базами. это обёртки, тредпул и орм

это, кстати, да, но мы же не думаем, что топик стартер просто так на базу грешит, без причины...

подозреваю что таки узкое место выбрано от балды

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

Dmitry вы профилировали приложение как-то?

может просто "настал момент"

и пора запустить второй процесс?

на скорости 200км/ч мерседеса обгоняет запорожец. его водила скорчив зверскую гримасу рычит "а теперь - вторая!"

в худшем случае можно купить пока тазик помощнее и заняться рефакторингом

Dmitry вы профилировали приложение как-то?

процессов сейчас итак запускаем штук 50 на сервер. Не профилировали толком, но от совсем долгих запросов постарались избавиться, но тем не менее оно не вывозит.

вроде ж считается оптимальным гонять колво ядер + пара сверху...

при чем тут gil и io? gil отпускается, когда передается управление другому треду. на блокирующем io этого не происходит.

я несколько криво выразился :) допустим, мы из основного треда породили ещё 1 и в нем с интервалом в 50мс выплёвываем а stderr "hello world". если основной тред заблокируется, то в stderr по-прежнему с интервалом в 50мс будет что-то печататься.

я несколько криво выразился :) допустим, мы из основного треда породили ещё 1 и в нем с интервалом в 50мс выплёвываем а stderr "hello world". если основной тред заблокируется, то в stderr по-прежнему с интервалом в 50мс будет что-то печататься.

как бы хер

вроде ж считается оптимальным гонять колво ядер + пара сверху...

примерно так и делается сейчас

ага... т.е. тазик приличный

ну, значит нужен второй тазик;)

брать второй и лоадбалансить..

причем может лоадбалансить не веб, а мускль

брать второй и лоадбалансить..

у нас итак далео не один сервер

а нагрузка на CPU какая?

как бы хер

эээ... теперь я в смятении. что бы такое почитать чтобы заведомо заблокироваться?

если базка на отдельном сервере и нагрузка на проц большая, то базка не при чем

метрики пособирать реально

чо ваще

эээ... теперь я в смятении. что бы такое почитать чтобы заведомо заблокироваться?

ну пошли запрос http на сервер который заакцептит и будет молчать

надо мерять. причем всю цепочку - от фронта до базы...

ну и на работу с базой посмотреть.

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

а нагрузка на CPU какая?

сам tornado грузит где-то 15-20% от всех ядер (не от одного). При этом на серваках еще есть другой софт, но теоретически можно было бы дойти до того, чтобы tornado грузил 50%

ну пошли запрос http на сервер который заакцептит и будет молчать

а, можно проще. почитать stdin

сам tornado грузит где-то 15-20% от всех ядер (не от одного). При этом на серваках еще есть другой софт, но теоретически можно было бы дойти до того, чтобы tornado грузил 50%

короче надо мерять

а, можно проще. почитать stdin

а как это всё связано с гил?

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.

хм...

цпу баунд треды хавают гил по черному

ну и опять же, помним про new gil в 3.3

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.

короче, ты не прав. если тред заблокируется, то второму вполне норм

ну, тут вопрос "как заблокируется"

бизли там офигенные картинки рисовал, в частности про конвойный эффект в новом гил при смешивании и/о и цпу баунд тредов

на чистом системном io - да, норм

короче, ты не прав. если тред заблокируется, то второму вполне норм

короче я тупанул, да. io + треды = дружба:)

на чистом системном io - да, норм

https://gist.github.com/anonymous/05ff1e1509cdbc964e13ab5b339d802e

www.dabeaz.com/python/NewGIL.pdf вот это надо обязательно знать про гил

сам tornado грузит где-то 15-20% от всех ядер (не от одного). При этом на серваках еще есть другой софт, но теоретически можно было бы дойти до того, чтобы tornado грузил 50%

А почему вы решили что бд?

Ладно, всем спасибо. Но, я так понимаю, что опыта решения подобной проблему ни у кого нет?

А почему вы решили что бд?

что бд?

ну это как лечить пациента по его детским фотографиям...

что бд?

вы утверждаете, что виновно общение с бд. на чём основано данное утверждение? вообще, возьмите тот же vmprof и постройте flamegraph )

Ладно, всем спасибо. Но, я так понимаю, что опыта решения подобной проблему ни у кого нет?

нет пока проблемы как таковой. tornado - это event loop, где всё блокирующее должно исполнятся в пуле тредов. если вы этого не делаете - сделайте. если сделали и не помогло - надо профайлить.

вы утверждаете, что виновно общение с бд. на чём основано данное утверждение? вообще, возьмите тот же vmprof и постройте flamegraph )

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

Ладно, всем спасибо. Но, я так понимаю, что опыта решения подобной проблему ни у кого нет?

есть. только с такой формулировкой решение проблемы - процесс измерения, анализа и оптимизации, а не ответ "нажми сюда"

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

"ходит в базу" и "sqlalchemy" - это может быть всё что угодно. от плохих запросов, до плохой схемы

ну вот, если нужен драйвер под торнаду, я дал ссылку, драйвер - это то что под sqlalchemy у вас работает и собственно ходит в базу

Всем спасибо, думаю мне лучше вернуться уже завтра

и лучше к исследованию приложения;)

https://github.com/brutasse/graphite-api/blob/master/graphite_api/functions.py#L68-L71

вот зачем так писать?

return reduce(operator.sub, safeValues)

потому что reduce надо импортить в 3-ке

а если оно под оба, то придется что-то делать

try: reduce except NameError: from functools import reduce

именно это я и называю что-то делать

ERROR: S client not available

ну или брать бгмерзкий six

и они разные, нно для этого кейса не критично

где всё сделато за нас

там, кстати, не всё;)

ну я про вот эти вот проверки 2/3 и приведение импортов к общему знаменателю

ну или брать бгмерзкий six

а чем он богомерзкий?

а накой он?

ну я про вот эти вот проверки 2/3 и приведение импортов к общему знаменателю

вот за этим;)

но там не всё;)

я вечно натыкаюсь что там чего-нибудь нет

по мне проще вставить пару except ImportError с фоллбаками

в смысле не покрыто

по мне проще вставить пару except ImportError с фоллбаками

а, ну ок

чем тащить полновесный пакадж, который еще и ломает порой серьезно код

когда у тебя только два импорта да, но часто он уже есть

Нашел в продакшен коде))

обычно оно быстро превращается в собственный compat.py

Костлей

обычно оно быстро превращается в собственный compat.py

six от этого не всегда спасает

> Костлей

просто если ты уже написал метакласс с six и заюзаз строки оттуда, то можно и для импортов уже six

нууу... если нужна настолько тяжелая артиллерия, то можно и сикс потащить

я ни разу не против оправданных зависимостей

а тащить сикс вместо банального from __future__ import print_function, unicode_literals порой оверкилл

вот зачем так писать?

кстати, а что, напоролся на чтото?

а тащить сикс вместо банального from __future__ import print_function, unicode_literals порой оверкилл

ну это да

кстати, а что, напоролся на чтото?

да тут в devops рассказывали что можно графит ускорить раза в 3 запустив на pypy и что pypy не любит всякую магию и для него list comprehensions - это плохо.

ээээ

но на самом деле list comprehensions в pypy быстрее