Нужно запустить на сервере более 2000 фоновых процессов. Какие подводные?
Есть около 100 датчиков, каждый из которых передаёт по интернету примерно по 20-25 значений примерно раз в полсекунды. Каждое из таких значений нужно получать отдельными процессами, потому что каждое значение надо обрабатывать индивидуально. Итого получается что на сервере, на котором это всё нужно получать, одновременно должно быть запущено до 2500 процессов (такой ужас будет временный - уже пишется сложное многопоточное приложение, которое обрабатывает всё и сразу, но сейчас пока так).
Один процесс - это минималистичное console-приложение на языке C#, зарегистрированное как сервис и не нагружающее систему - там только получение WebSocket-сообщений каждые полсекунды, простые вычисления и в редкие моменты сохранение небольшого файла на диск.
Сталкивался кто-нибудь с опытом запуска и управления таким количеством процессов? Какой инструментарий люди используют, может подходы какие есть отработанные? Насколько мощный сервер (хотя бы приблизительно) нужен, или может даже несколько? Может что-то Amazon, Azure или подобные крупные ребята предлагают для таких случаев? Неужели нужно будет осваивать контейнеризацию и оркестрацию? Или всё-таки разведка боем нужна - закупаться сервером наобум и тестировать?
вместо 2500 процессов будет 2500 потоков :)
чуть быстрее будет переключение контекста, чуть геморнее будет распиливание памяти между потоками, взаимодействие как повезет с архитектором.
память под исполняемый код в обоих случаях будет общая и места не займет.
в остальном один фих, только вид сбоку.
запустить на тест сотню процессов на имеющейся рабочей лошадке и посмотреть свезет или нет.
коль свезет нагрузить большим количеством. не свезет - уменьшить.
на основе опыта составить табличку "потребление памяти, процессора и прочих ресурсов от количества" с десятком значений по оси "количество процессов/потоков", с желательно большим диапазоном.
посмотреть на кривую и уже от нее плясать.
плюс стресовая нагрузка.
Такую архитектуру дизайнили лет 10 назад. В настоящее время (Reactive/Async/EventDriven) стараются делать просто 1 большой процесс который диспетчеризирует канал I/O и раздает вызовы бизнес-функциям. Или акторам как будет угодно. Вобщем если сведенья со всех датчиков вы получаете через один сетевой интерфейс и все 100 датчиков работают на одном сетевом протоколе - то вам имеет смысл подумать о таком дизайне.
2000 процессов выглядят трешово. Тем более что вы должны понимать что квантов времени им никто не даст одновременно. Всё равно внутри ядра они будут стоять в очередях.
Единственное пожалуй преимущество вашей архитектуры в том что можно стартовать и килять отдельно каждый процесс. Но является ли это таким уж полезным?
Román Mirilaczvili, поддакну майтону :) и скажу что ответить вопрощающему трудно, ибо вопрос философский, а не прикладной.
2500 потоков/процессов это конечно перегруз, цифра взята, на мой взгляд, бездумно.
но десяток/сотня воркеров + разумно созданная очередь входных данных вполне справятся.
опять же все подобные вопросы должен решать архитектор после вдумчивого изучения тех.задания и условий.
soundie
А что мешает отправить 20-25 метрик за один запрос?
И есть ли уверенность в том, что все датчики будут отправлять синхронизированно? Есть шанс того, что они будут отправлять метрики в разнобой, и, при этом, с заданной периодичностью.
