Как только размер вашей очереди превысит параллелизм вашего потока, влияние будет преимущественно на задержку по сравнению с ранней ошибкой.Чем больше очередь, тем больше задержка между вставкой «задания» и достижением start .Чем больше ограничение на размер очереди, тем дольше вы активно замечаете потенциально огромную задержку.В одних рабочих нагрузках огромный буфер и задержка в порядке, в других это катастрофа.Поскольку это не приоритетная очередь (это пятерка), нелегко получить «экстренное задание» для руководителя линии - вам придется подождать или начать писать специализированную диспетчеризацию и управление очередью в соответствии с потребностями вашего бизнеса.«Болевая точка» чаще всего обратная - спросите себя, сколько времени максимум допустимо между введением задания в очередь и его началом.Возьмите это число, разделите на среднее время выполнения для ваших заданий, разделите на размер потока очереди (если он меньше, чем фактический аппаратный параллелизм) - это ваш максимальный размер очереди.
Time to Start Job = Current Length of queue * Time per job / Number of (real) threads.
Maximum (or average working) queue size == (Maximum Latency * threads ) / Time per job
Математика салфеток: Предполагается, что следующие сферические элементы:
Jobs = 100ms/each Thread Count = 16 (real cores) Max acceptable latency = 10 seconds
----------------------------- Queue Size Limit = 10*16/.1 = 1600
If your max latency is 10000 seconds then q=1600000
If your max latency is 1 sec then q=160
Для коэффициента 2-го порядка - когда вы продвигаете параллелизм и загружаете, вероятность возникновения конфликта блокировки возрастает - не-линейно (в зависимости от вашего кода) - обратите внимание на это.Следите за историей мониторинга на предмет конфликтов блокировок, ожидания и т. Д. Удаление числа потоков, скорее всего, принесет больше пользы, чем удаление размера очереди в этом случае.