процессы vs треды
а) с чего ты взял, что разбиение на процессы повысит производительность? или ты о стабильности?
б) почему так много потоков при 20 клиентах?
в) профайлер запускать не пробовал?
б) почему так много потоков при 20 клиентах?
в) профайлер запускать не пробовал?
Учитывая, что все ядра загружены не полностью, то не думаю, что дальнейшее распараллеливание даст ощутимое улучшение. Я бы не стал заморачиваться.
Зато еще можно сказать, что добавятся доп. расходы на доп.процессы, плюс так как у ядер кеш разный, раскидав приложение сильнее по ядрам, может быть нагрузишь сильнее память.
Общего ответа тут нет - надо анализировать код/попробовать.
Зато еще можно сказать, что добавятся доп. расходы на доп.процессы, плюс так как у ядер кеш разный, раскидав приложение сильнее по ядрам, может быть нагрузишь сильнее память.
Общего ответа тут нет - надо анализировать код/попробовать.
У тебя пул процессов/тредов? То есть при каждом ли запросе создаётся новый тред? Если да, то лучше не разбивать, т.к. процессы создаются гораздо медленней тредов.
> а) с чего ты взял, что разбиение на процессы повысит производительность?
> или ты о стабильности?
> б) почему так много потоков при 20 клиентах?
> в) профайлер запускать не пробовал?
а) хз в этом и вопрос, но сама мысль возникла из-за неравномерной загрузки ядер
б) на клиента по 4 треда
- сетевой ридер/райтер
- препарсер запросов
- штука, которая разгребает очередь запросов/ответов, чтобы из-за асинхронности центрального модуля клиент не получал старьё (используются push-запросы - попросил один и получаешь пока не откажешься)
- совсем специальный тред, иногда завершается, иногда респавнится
центральный модуль -
общается с вендорами (4 треда как в клиенте + 2 дополнительно) вендоров 3 штуки, плюс еще он сам себе вендор
десяток сервисных тредов (биндят порты, разгребают блокировки ридер/райтер итд)
в) не знаю как это делать
ps: дядя, помоги прокачать игрушку
> или ты о стабильности?
> б) почему так много потоков при 20 клиентах?
> в) профайлер запускать не пробовал?
а) хз в этом и вопрос, но сама мысль возникла из-за неравномерной загрузки ядер
б) на клиента по 4 треда
- сетевой ридер/райтер
- препарсер запросов
- штука, которая разгребает очередь запросов/ответов, чтобы из-за асинхронности центрального модуля клиент не получал старьё (используются push-запросы - попросил один и получаешь пока не откажешься)
- совсем специальный тред, иногда завершается, иногда респавнится
центральный модуль -
общается с вендорами (4 треда как в клиенте + 2 дополнительно) вендоров 3 штуки, плюс еще он сам себе вендор
десяток сервисных тредов (биндят порты, разгребают блокировки ридер/райтер итд)
в) не знаю как это делать
ps: дядя, помоги прокачать игрушку
реальная цель, кстати, какая?
уменьшить загрузку процессоров?
ускорить обработку запросов?
ps
сделать чтобы процессоры равномерно загружались - это не цель, т.к. такое нужно только ради красоты.
уменьшить загрузку процессоров?
ускорить обработку запросов?
ps
сделать чтобы процессоры равномерно загружались - это не цель, т.к. такое нужно только ради красоты.
> То есть при каждом ли запросе создаётся новый тред?
треды создаются/убиваются при подключение/отключение клиента
большинство тредов (~100) живут 10 часов, другие треды живут по ~500мс, но создаются раз в ~5 минут, общий трафик через все узлы ~150мбит/с
треды создаются/убиваются при подключение/отключение клиента
большинство тредов (~100) живут 10 часов, другие треды живут по ~500мс, но создаются раз в ~5 минут, общий трафик через все узлы ~150мбит/с
> реальная цель, кстати, какая?
> уменьшить загрузку процессоров?
> ускорить обработку запросов?
> ps: сделать чтобы процессоры равномерно загружались - это не цель,
> т.к. такое нужно только ради красоты.
видимо первое, потому, что второе - это скорость обработки запросов + скорость системы, а скорость системы уже вылизана
вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковая
может ли это значить что где-то что-то сделано криво
> уменьшить загрузку процессоров?
> ускорить обработку запросов?
> ps: сделать чтобы процессоры равномерно загружались - это не цель,
> т.к. такое нужно только ради красоты.
видимо первое, потому, что второе - это скорость обработки запросов + скорость системы, а скорость системы уже вылизана
вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковая
может ли это значить что где-то что-то сделано криво
В теории разделение на процессы должно только добавлять задержки, но никак не уменьшать их (разве только за счёт более быстрой отработки GC в каждом отдельном процессе).
Зачем 4 треда из описания их действий не понятно. Нужно описание того, какие полезные задачи они делают асинхронно и как эти задачи синхронизуются между собой.
Профайлер есть только в VS Team System. Ну или сторонний какой-нибудь можешь поискать.
Зачем 4 треда из описания их действий не понятно. Нужно описание того, какие полезные задачи они делают асинхронно и как эти задачи синхронизуются между собой.
Профайлер есть только в VS Team System. Ну или сторонний какой-нибудь можешь поискать.
В теории разделение на процессы должно только добавлять задержкиКакая-то странная у тебя теория...
Попробуй запустить без отладчика и посмотреть загрузку ядер.
Почему странная? Вместо общей памяти придётся использовать IPC.
> Зачем 4 треда из описания их действий не понятно
эмпирически это снизило загрузку, увеличило пропускную способность
про отладчик - ценная мысль, попробую
эмпирически это снизило загрузку, увеличило пропускную способность
про отладчик - ценная мысль, попробую
вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковаядумаю, нужно нагрузочное тестирование проводить
может ли это значить что где-то что-то сделано криво
если например при росте нагрузки производительность (в запросах в секунду) выйдет на плато, а при этом останутся недогруженные ядра, то что-то явно криво
Там довольно много всяких если.
Потому что если бы разделение на процессы всегда давало только минус - то, согласись, никто бы никогда этим не заморачивался.
Потому что если бы разделение на процессы всегда давало только минус - то, согласись, никто бы никогда этим не заморачивался.
вопрос на самом деле - из-за чего может быть так, что загрузка процессоров не одинаковаяи так, и так может быть, может все нормально, может и кривовато.
может ли это значить что где-то что-то сделано криво
(если не вдаваться в подробности, то)пока у тебя процессоры недогружены, планировщик имеет право как попало загружать ядра
правильно говорит, что посмотреть стоит "что происходит, когда система начинает нагружаться еще больше и выходит на максимальную производительность"
Там довольно много всяких если.разделение на процессы и треды всегда дает минус (вопрос только на сколько существенный кроме случая когда разделение на треды(процессы) делается для того, чтобы по максимуму использовать ресурс, который поддерживает параллельное использование.
Потому что если бы разделение на процессы всегда давало только минус - то, согласись, никто бы никогда этим не заморачивался.
т.е. если у нас процессора два, то деление на два треда будет давать плюс, деление еще на два (в итоге четыре уже будет давать минус по сравнению с двумя тредами.
ps
все это утверждается при условии, что в рамках одного треда мы умеем выполнять несколько потоков управления (хотя бы через очередь сообщений)
с нагрузкой - проблемы, клиенты занимаются сиблингом вендоров, и для того, чтобы создать нагрузку, вендоры должны поставить что-то очень не синхронное, создать прецидент сложно, так как вендорам это экономически не выгодно 
Ну не факт. Минус будет, если необходимо много синхронизации, а так потоки все равно прерываются системой. Даже более того: если в системе больше "наших" потоков, то им будет доставаться больше времени, но это все капли в океане, естественно, так как другие потоки в основном бездействуют.
Ну не факт. Минус будет, если необходимо много синхронизацииминус будет при любых переключениях вызванных вызовом IO, внешних программ и т.д.
допустим у тебя один проц и два треда, каждый из которых хочет отработать по полкванта
планировщик отработает первый тред, потом оставщиеся полкванта отдаст какому-нибудь левому треду,
а второй тред получит свои полкванта - только при наступлении нового кванта.
в итоге, получили лишнюю паузу в полкванта.
если же это все делалось в одном треде, то такого бы не произошло.
Я же говорил, если не нужна синхронизация потоков. Ты же хочешь, чтобы один после другого выполнялся. Поправь, если что не так.
убрал спорный момент
клиенты занимаются сиблингом вендоровне слышал про такой вид сексуальных извращений
это как?(~20 клиентов одновременно)
~135 тредов
в винде context switching включается в proc usage?
не знаю, но это может быть красной линией на графике?
красной линией - ядерное время.
Оставить комментарий
state7401281
дела обстоят так:на машине (четырехядерный intel Q9400, win2k3 server x64) стоит серверное приложение (~20 клиентов одновременно оперативка/винт/сеть быстрые
серверная часть самописная .net 3.5 имеет ~135 тредов и грузит проц на ~25-35%, но два ядра грузит заметно сильнее
возможно ли получить приимущество если побить сервер на ~20 процессов (1 процесс на клиента (4 треда) + еще 1 на всех (50-60 тредов или не стоит тратить время?