процессы vs треды

state7401281

дела обстоят так:

на машине (четырехядерный intel Q9400, win2k3 server x64) стоит серверное приложение (~20 клиентов одновременно оперативка/винт/сеть быстрые
серверная часть самописная .net 3.5 имеет ~135 тредов и грузит проц на ~25-35%, но два ядра грузит заметно сильнее
возможно ли получить приимущество если побить сервер на ~20 процессов (1 процесс на клиента (4 треда) + еще 1 на всех (50-60 тредов или не стоит тратить время?

agaaaa

а) с чего ты взял, что разбиение на процессы повысит производительность? или ты о стабильности?
б) почему так много потоков при 20 клиентах?
в) профайлер запускать не пробовал?

katrin2201

Учитывая, что все ядра загружены не полностью, то не думаю, что дальнейшее распараллеливание даст ощутимое улучшение. Я бы не стал заморачиваться.
Зато еще можно сказать, что добавятся доп. расходы на доп.процессы, плюс так как у ядер кеш разный, раскидав приложение сильнее по ядрам, может быть нагрузишь сильнее память.
Общего ответа тут нет - надо анализировать код/попробовать.

okis

У тебя пул процессов/тредов? То есть при каждом ли запросе создаётся новый тред? Если да, то лучше не разбивать, т.к. процессы создаются гораздо медленней тредов.

state7401281

> а) с чего ты взял, что разбиение на процессы повысит производительность?
> или ты о стабильности?
> б) почему так много потоков при 20 клиентах?
> в) профайлер запускать не пробовал?
а) хз в этом и вопрос, но сама мысль возникла из-за неравномерной загрузки ядер
б) на клиента по 4 треда
- сетевой ридер/райтер
- препарсер запросов
- штука, которая разгребает очередь запросов/ответов, чтобы из-за асинхронности центрального модуля клиент не получал старьё (используются push-запросы - попросил один и получаешь пока не откажешься)
- совсем специальный тред, иногда завершается, иногда респавнится
центральный модуль -
общается с вендорами (4 треда как в клиенте + 2 дополнительно) вендоров 3 штуки, плюс еще он сам себе вендор
десяток сервисных тредов (биндят порты, разгребают блокировки ридер/райтер итд)
в) не знаю как это делать
ps: дядя, помоги прокачать игрушку

Dasar

реальная цель, кстати, какая?
уменьшить загрузку процессоров?
ускорить обработку запросов?
ps
сделать чтобы процессоры равномерно загружались - это не цель, т.к. такое нужно только ради красоты.

state7401281

> То есть при каждом ли запросе создаётся новый тред?
треды создаются/убиваются при подключение/отключение клиента
большинство тредов (~100) живут 10 часов, другие треды живут по ~500мс, но создаются раз в ~5 минут, общий трафик через все узлы ~150мбит/с

state7401281

> реальная цель, кстати, какая?
> уменьшить загрузку процессоров?
> ускорить обработку запросов?
> ps: сделать чтобы процессоры равномерно загружались - это не цель,
> т.к. такое нужно только ради красоты.
видимо первое, потому, что второе - это скорость обработки запросов + скорость системы, а скорость системы уже вылизана
вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковая
может ли это значить что где-то что-то сделано криво

agaaaa

В теории разделение на процессы должно только добавлять задержки, но никак не уменьшать их (разве только за счёт более быстрой отработки GC в каждом отдельном процессе).
Зачем 4 треда из описания их действий не понятно. Нужно описание того, какие полезные задачи они делают асинхронно и как эти задачи синхронизуются между собой.
Профайлер есть только в VS Team System. Ну или сторонний какой-нибудь можешь поискать.

katrin2201

В теории разделение на процессы должно только добавлять задержки
Какая-то странная у тебя теория...

agaaaa

Попробуй запустить без отладчика и посмотреть загрузку ядер.

agaaaa

Почему странная? Вместо общей памяти придётся использовать IPC.

state7401281

> Зачем 4 треда из описания их действий не понятно
эмпирически это снизило загрузку, увеличило пропускную способность
про отладчик - ценная мысль, попробую

Marinavo_0507

вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковая
может ли это значить что где-то что-то сделано криво
думаю, нужно нагрузочное тестирование проводить
если например при росте нагрузки производительность (в запросах в секунду) выйдет на плато, а при этом останутся недогруженные ядра, то что-то явно криво

katrin2201

Там довольно много всяких если.
Потому что если бы разделение на процессы всегда давало только минус - то, согласись, никто бы никогда этим не заморачивался.

Dasar

вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковая
может ли это значить что где-то что-то сделано криво
и так, и так может быть, может все нормально, может и кривовато.
(если не вдаваться в подробности, то)пока у тебя процессоры недогружены, планировщик имеет право как попало загружать ядра
правильно говорит, что посмотреть стоит "что происходит, когда система начинает нагружаться еще больше и выходит на максимальную производительность"

Dasar

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

state7401281

с нагрузкой - проблемы, клиенты занимаются сиблингом вендоров, и для того, чтобы создать нагрузку, вендоры должны поставить что-то очень не синхронное, создать прецидент сложно, так как вендорам это экономически не выгодно :(

Serab

Ну не факт. Минус будет, если необходимо много синхронизации, а так потоки все равно прерываются системой. Даже более того: если в системе больше "наших" потоков, то им будет доставаться больше времени, но это все капли в океане, естественно, так как другие потоки в основном бездействуют.

Dasar

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

Serab

Я же говорил, если не нужна синхронизация потоков. Ты же хочешь, чтобы один после другого выполнялся. Поправь, если что не так.

Dasar

убрал спорный момент

Marinavo_0507

клиенты занимаются сиблингом вендоров
не слышал про такой вид сексуальных извращений :blush: это как?

shudrik

(~20 клиентов одновременно)
~135 тредов

в винде context switching включается в proc usage?

state7401281

не знаю, но это может быть красной линией на графике?

klyv

красной линией - ядерное время.
Оставить комментарий
Имя или ник:
Комментарий: