Сколько потоков слишком многие? [закрытый]
Объединение размещается между двумя блоками набора результатов и образует один блок набора результатов. Если вам нужно выражение where для определенного блока, вы можете поместить его:
select a from a where a = 1
union
select z from z
select a from a
union
select z from z where z = 1
select a from a where a = 1
union
select z from z where z = 1
Первый запрос в объединении определяет имена столбцов в выходных данных. Вы можете заключить вывод в квадратные скобки, присвоить ему псевдоним и сделать «где» для всего лота:
select * from
(
select a as newname from a where a = 1
union
select z from z where z = 2
) o
where o.newname = 3
Важно отметить, что a.a и z.z объединятся в новый столбец o.newname. В результате, высказывание where o.newname отфильтрует все строки как от a, так и от z (строки из z также помещаются в столбец newname). Внешний запрос знает только о o.newname, он ничего не знает о a или z
Примечание: вышеупомянутый запрос ничего не дает, потому что мы знаем, что объединение выводит только строки, где aa равно 1 и zz равно 2 как o.newname. Это имя o.new затем фильтруется только для выходных строк, которые равны 3, но ни одной строки не равны 3
select * from
(
select a as newname from a
union
select z from z
) o
where o.newname = 3
Этот запрос будет подбирать любые строки в a или z, где aa равно 3 или zz равно 3, спасибо для фильтрации результирующего объединения
9 ответов
Некоторые люди сказали бы, что два потоки - слишком многие - я нахожусь не совсем в том лагере :-)
Вот мой совет: мера, не предполагать. Одно предложение состоит в том, чтобы сделать это настраивающимся и первоначально устанавливать его на 100, затем выпускать Ваше программное обеспечение к дикой местности и контролировать то, что происходит.
, Если Ваши пики использования потока в 3, то 100 слишком много. Если это остается в 100 в течение большей части дня, ударьте его до 200 и посмотрите то, что происходит.
Вы могли на самом деле иметь свой код, сам контролируют использование и корректируют конфигурацию в следующий раз, когда это запускается, но это - вероятно, излишество.
<час>Для разъяснения и разработки:
я не рекомендую прокручивать Вашу собственную подсистему объединения потока, любой ценой использую ту, которую Вы имеете. Но, так как Вы спрашивали о хорошем пределе для потоков, я предполагаю, что Ваша реализация пула потоков имеет способность ограничить максимальное количество созданных потоков (который является хорошей вещью).
я записал поток и код объединения соединения с базой данных, и у них есть следующие функции (которому я верю, важны для производительности):
- минимальное количество активных потоков.
- максимальное количество потоков.
- закрывающиеся потоки, которые не использовались некоторое время.
первые наборы базовая линия для минимальной производительности с точки зрения клиента пула потоков (это количество потоков всегда доступно для использования). Вторые наборы ограничение на использование ресурсов активными потоками. Третьи возвраты Вы к базовой линии в тихие времена, чтобы минимизировать использование ресурса.
необходимо сбалансировать использование ресурсов наличия неиспользованных потоков (A) против использования ресурсов не наличия достаточных потоков, чтобы сделать работу (B).
(A) обычно использование памяти (стеки и так далее), так как поток, делающий работу, не будет использовать большую часть ЦП. (B) обычно будут задержкой обработки запросов, когда они прибывают, поскольку необходимо ожидать потока для становления доступными.
Вот почему Вы имеете размеры. Как Вы заявляете, подавляющее большинство Ваших потоков будет ожидать ответа от базы данных, таким образом, они не будут работать. Существует два фактора, которые влияют, сколько потоков необходимо допускать.
первым является количество доступных соединений с БД. Это может быть жестким пределом, если Вы не можете увеличить его в DBMS - я собираюсь предположить, что Ваш DBMS может взять неограниченное количество соединений в этом случае (хотя необходимо идеально измерять это также).
Затем количество потоков, которые Вы должны иметь, зависит от Вашего исторического использования. Минимум у Вас должно быть выполнение, является минимальным числом, из которого у Вас когда-либо было выполнение + % с абсолютным минимумом (например, и сделайте это настраивающимся точно так же, как A), 5.
максимальное количество потоков должно быть Вашим историческим максимумом + B %.
необходимо также контролировать для изменений поведения. Если бы по некоторым причинам Ваше использование переходит к 100% доступных в течение значительного времени (так, чтобы оно влияло бы на производительность клиентов), необходимо увеличить максимум, позволенный, пока это не еще раз B % выше.
<час>В ответ на, "что точно я должен измерить?" вопрос:
то, Что необходимо измерить конкретно, является максимальной суммой потоков в параллельном использовании (например, ожидая по возврату из вызова DB) при загрузке. Затем добавьте запас прочности 10% для пример (подчеркнутый, так как другие плакаты, кажется, берут мои примеры в качестве фиксированных рекомендаций).
, Кроме того, это должно быть сделано в продуктивной среде для настройки. Это должно хорошо получить оценку заранее, но Вы никогда не знаете, какое производство бросит Ваш путь (который является, почему все эти вещи должны настраиваться во времени выполнения). Это должно поймать ситуацию, такую как неожиданное удвоение клиента, призывает прибытие.
Если Ваши потоки выполнят какой-либо вид ресурсоемкой работы (ЦП/диск) затем, то Вы будете редко видеть преимущества вне один или два, и слишком многие уничтожат производительность очень быстро.
'лучший случай' - то, что Ваши более поздние потоки остановятся, в то время как первые завершаются, или у некоторых будут блоки низких издержек на ресурсах с низкой конкуренцией. Худший случай - то, что Вы начинаете перегружать кэш/диск/сеть и Ваши полные отбрасывания пропускной способности через пол.
хорошее решение А состоит в том, чтобы поместить запросы в пул, которые затем отправлены рабочим потокам от пула потоков (и да, избегая, чтобы непрерывное создание/разрушение потока было большим первым шагом).
количество активных потоков в этом пуле можно затем настроить и масштабировать на основе результатов Вашего профилирования, аппаратные средства, на которых Вы работаете, и другие вещи, которые могут происходить на машине.
Как Мир, справедливо сказанный, мера, не предполагают . Это, что я сделал для DNSwitness и результаты, было удивительно: идеальное количество потоков было намного выше, чем я думал, что-то как 15 000 потоков для получения самых быстрых результатов.
, Конечно, это зависит от многих вещей, вот почему необходимо измерить себя.
Полные меры (только на французском языке) в Combien de fils d'exГ©cution? .
Одна вещь рассмотреть состоит в том, сколько ядер существует на машине, которая будет выполнять код. Это представляет жесткий предел того, сколько потоков может продолжаться в любой момент времени. Однако, если, как в Вашем случае, потоки, как будут ожидать, будут часто ожидать базы данных для выполнения запроса, то Вы, вероятно, захотите настроить свои потоки на основе того, сколько параллельных запросов база данных может обработать.
Я думаю, что это - определенная уловка к Вашему вопросу, но почему не разветвляют их в процессы? Мое понимание сетей (с туманных дней былого, я действительно не кодирую сети вообще), был то, что каждое входящее соединение может быть обработано как отдельный процесс, потому что затем, если кто-то делает что-то противное в Вашем процессе, оно не уничтожает всю программу.
ryeguy, я в настоящее время разрабатываю подобное приложение, и мой номер потоков определяется к 15. К сожалению, если я увеличиваю его в 20, это отказывает. Так, да, я думаю лучший способ обработать, это должно иметь размеры, позволяет ли Ваша текущая конфигурация более или менее, чем номер X потоков.
В большинстве случаев необходимо позволить пулу потоков обрабатывать это. Если Вы отправляете некоторый код или предоставляете больше подробную информацию, могло бы быть легче видеть, существует ли некоторая причина, поведение по умолчанию пула потоков не было бы лучшим.
можно найти больше информации о том, как это должно работать здесь: http://en.wikipedia.org/wiki/Thread_pool_pattern
Столько же потоков сколько ядра процессора - то, что я слышал очень часто.
Следует иметь в виду, что python (по крайней мере, версия на основе C) использует так называемую глобальную блокировку интерпретатора , которая может иметь огромное влияние на производительность на многоядерные машины.
Если вам действительно нужна максимальная отдача от многопоточного Python, вы можете рассмотреть возможность использования Jython или чего-то подобного.