Здравствуйте, LWhisper, Вы писали:

AVK>>Не можешь. Нельзя Thread.Abort использовать от слова вообще.
LW>Вполне себе могу. Код корректно обрабатывает ThreadAbortException и использует CER согласно правилам, там где это необходимо.

Все равно ты можешь сломать код библиотечный — там никто статические конструкторы не защищает.

Здравствуйте, AndrewVK, Вы писали:

AVK>А зачем все 10К делать LR?
Потому что они есть и от этого не уйти.

AVK>Разница есть, потому что остаются еще зависимости.
Какие зависимости?

Здравствуйте, LWhisper, Вы писали:

AVK>>А зачем все 10К делать LR?
LW>Потому что они есть и от этого не уйти.

Что есть? Ничего у тебя нет. Смысл LR не в том, что задача выполняется больше некоторого времени, а в том что она выполняется намного дольше остальных задач.
Еще раз — твое представление о работе конвеера TPL слишком упрощено. Очередь в TPL совсем не одна, их много. По одной на активный поток. Да еще и work stealing может перекидывать задачки из очереди в очередь в зависимости от загрузки. И еще есть специальный тип задач, который сам конвеер TPL может резать на куски нужного ему размера.
LR же нужны чтобы убрать потери на неровное окончание этих очередей в самом конце исполнения.
Поэтому правильная стратегия оптимизации — разделить задачи на категории и LR сделать только те, которые выполняются явно в разы дольше других. Если такое нельзя сказать заранее — тогда, как советовал Sinix, придется их динамически перекидывать, но это уже существенно больший объем работы по допиливанию шедулера.
Ну а на втором этапе надо все таки самые долгоиграющие вещи резать по точкам ожидания, неважно каким образом — при помощи await или ContinueWith. От этого точно никуда не уйти если тебе хоть сколько то важна эффективность.

AVK>>Разница есть, потому что остаются еще зависимости.
LW>Какие зависимости?

Одной задачи от результата другой.

Здравствуйте, LWhisper, Вы писали:

LW>Существуют ли какие-либо рекомендации по оптимизации подобных сценариев?
1. Использовать ThreadPool
2. Использовать очереди producer/consumer с ограничееным числом consumer
3. Использовать внешние очереди(самописные или rebbitmq, nservicebus, msmq и так далее) с масштабированием consumers на несколько серверов.

Здравствуйте, LWhisper, Вы писали:

LW>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

А что тут оптимизировать и зачем? Что-то объективно медленно работает? Процессоры недогружены или перегружены? Что там вообще с CPU usage в установившемся режиме? Ну повисли они в thread.sleep, и пусть себе спят — это довольно эффективно, даже если их много.

Здравствуйте, LWhisper, Вы писали:

LW>Всем привет.

LW>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

Оставить как есть, беспокоиться надо было после первой сотни потоков. Раз не чесались, значит и не надо было.

LW>Существуют ли какие-либо рекомендации по оптимизации подобных сценариев?

Сопровождать старую версию и писать новую, с учётом накопленных знаний.

Здравствуйте, LWhisper, Вы писали:

LW>Существуют ли какие-либо рекомендации по оптимизации подобных сценариев?

Чтобы дать рекомендации нужно не ваше решение описывать, а исходную задачу. Ты опиши задачу. Объясни откуда у вас там 10к потоков вырисовывается, а мы подумаем. Арсенал то решений огромный ведь.

Здравствуйте, LWhisper, Вы писали:

LW>Просто перейти на очередь задач сейчас не получится, так как задачи имеют обыкновение виснуть в неожиданный момент и тогда встрянет весь пул задач.


Если поток при этом в сигнальном состоянии, т.е. используется Sleep или Wait, то можно воспользоваться APC, чтобы нагрузить его работой на это время.

Здравствуйте, LWhisper, Вы писали:

LW>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

это так и называется — c10k problem

Здравствуйте, LWhisper, Вы писали:

LW>Всем привет.

LW>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

LW>Существуют ли какие-либо рекомендации по оптимизации подобных сценариев? Исходим из того, что реально одновременно выполняться может не больше 128 потоков, остальное время мы вынуждены гонять контекст между ними. Но из-за вышеупомянутых задержек, 10000 потоков с постоянным переключением контекста, работают быстрее, нежели 128, которые большую часть времени жизни спят.

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

Здравствуйте, Visor2004, Вы писали:

V>Если поток при этом в сигнальном состоянии, т.е. используется Sleep или Wait, то можно воспользоваться APC, чтобы нагрузить его работой на это время.

Благодарю. Это интересно!

Здравствуйте, Sharowarsheg, Вы писали:

S>А что тут оптимизировать и зачем? Что-то объективно медленно работает? Процессоры недогружены или перегружены? Что там вообще с CPU usage в установившемся режиме? Ну повисли они в thread.sleep, и пусть себе спят — это довольно эффективно, даже если их много.
В процессе сборки мусора, GC приостанавливает все потоки. Когда их 10000, это начинает бить по производительности. Новые потоки висят в ожидании GC. Растёт очередь финализации. К сожалению, у меня недостаточно знаний о работе GC на низком уровне, чтобы обосновать происходящее. За сим и пришёл.
P.S. А ещё студия падает при попытке открыть такие дампы. Это, конечно, лишний повод в совершенстве овладеть WinDbg, но и там с таким количеством потоков не совсем удобно работать.

Здравствуйте, VladD2, Вы писали:

VD>Чтобы дать рекомендации нужно не ваше решение описывать, а исходную задачу. Ты опиши задачу. Объясни откуда у вас там 10к потоков вырисовывается, а мы подумаем. Арсенал то решений огромный ведь.
100 пользователей запускают 100 параллельных задач, которые радостно ломятся на удалённый сервер, запуская на нём вычисления и передавая данные.
Ставить пользователей в очередь нельзя. Прокачивать CPU, RAM и сеть на сервере можно в пределах разумного.
По уму, стоило бы писать на erlang, с прицелом на кластер и горизонтальное расширение. Увы, имеем .NET и один процесс, обслуживающий всех клиентов. Вот с этим нужно как-то жить. Рефакторить и переписывать с нуля, конечно, можно, но лишь в отдалённой перспективе.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>это так и называется — c10k problem
Впервые вижу.
Спасибо, ознакомлюсь.

Здравствуйте, LWhisper, Вы писали:

LW>100 пользователей запускают 100 параллельных задач, которые радостно ломятся на удалённый сервер, запуская на нём вычисления и передавая данные.

Уже выглядит странно. Зачем пользователю одновременно 100 задач? Что за задачи?

LW>Ставить пользователей в очередь нельзя. Прокачивать CPU, RAM и сеть на сервере можно в пределах разумного.
LW>По уму, стоило бы писать на erlang,

Похожую модель можно на чем угодно с бацать. Если что можно те же зеленые потоки привлечь. Но все же сначала надо понимать характер задач. Что эти пользователи в таком количестве вычисляют?

Здравствуйте, VladD2, Вы писали:

LW>>100 пользователей запускают 100 параллельных задач, которые радостно ломятся на удалённый сервер, запуская на нём вычисления и передавая данные.

VD>Уже выглядит странно. Зачем пользователю одновременно 100 задач? Что за задачи?
Ставлю на то, что у пользователя есть грид, он на нем делает Select All а потом — Apply. Ну вот этот Apply отрабатывает точно так же, как и при выборе 1-2 записей из грида

Здравствуйте, VladD2, Вы писали:

VD>Уже выглядит странно. Зачем пользователю одновременно 100 задач? Что за задачи?
VD>Похожую модель можно на чем угодно с бацать. Если что можно те же зеленые потоки привлечь. Но все же сначала надо понимать характер задач. Что эти пользователи в таком количестве вычисляют?

Зачем — это вопрос к пользователям. Они купили себе 100 слотов, и имеют право использовать их по своему усмотрению. Моя задача — обеспечить стабильную работу сервера в такой ситуации.

Здравствуйте, LWhisper, Вы писали:

LW>Зачем — это вопрос к пользователям. Они купили себе 100 слотов, и имеют право использовать их по своему усмотрению. Моя задача — обеспечить стабильную работу сервера в такой ситуации.
Если задача стоит так, то в с10k ты уже уперся и тут начинается боль.
Общая рекомендация — кешировать и горизонтально масштабировать. Детали зависят от твоей специфики, дашь деталей — может что и присоветуем.
Возможно получится отделаться малой кровью, хотя мне думается что это маловероятно.

Здравствуйте, DeathKnight, Вы писали:

LW>>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

Наверное проще организовать очередь, и использовать пул потоков количество потоков равных количеству ядер или еще меньше?

Здравствуйте, LWhisper, Вы писали:

LW>Всем привет.

LW>В настоящий момент я запускаю на выполнение 10000 параллельных задач посредством new Thread(...).Start().
LW>Вначале они дерутся за процессорное время, но вскоре повисают на ожидании чего-либо — блокировок, ответа от сокета, просто в Thread.Sleep

LW>Существуют ли какие-либо рекомендации по оптимизации подобных сценариев? Исходим из того, что реально одновременно выполняться может не больше 128 потоков, остальное время мы вынуждены гонять контекст между ними. Но из-за вышеупомянутых задержек, 10000 потоков с постоянным переключением контекста, работают быстрее, нежели 128, которые большую часть времени жизни спят.

Конечно существуют. Основная рекомендация — не создавать потоки. Вообще забудь про thread.start. Забудь что у тебя есть потоки.
Используй асинхронный код, он сам заустит продолжение где надо и не будет заниматься фигней, при этом не съест потоков больше, чем в thread pool.