Могу ли я запретить ZeroMQ занимать файловые дескрипторы?

zeromq file-descriptor distributed-system

353 просмотра

1 ответ

145 Репутация автора

У меня есть настройка, в которой главный процесс настраивает, ZMQ_ROUTERа затем разветвляет множество дочерних процессов, которые затем подключаются к этому маршрутизатору.

Всякий раз, когда ребенок zmq_connect()является ведущим, один файловый дескриптор занят.

Это, однако, ограничивает количество взаимодействующих процессов количеством разрешенных файловых дескрипторов (на процесс). Для меня (Linux) это в настоящее время просто 1024.

Это слишком мало для моего предполагаемого использования (симуляция нескольких агентов / роя).


Ответ :

Вы не можете, кроме случаев использования межпотокового типа сокета (используя inproc://транспортный класс). Все остальные протоколы используют один файловый дескриптор для каждого соединения.

Один новый подход к сокращению количества необходимых файловых дескрипторов на приложение, если у этого приложения есть несколько сервисов (например, tcp://<address:port>можно установить несколько подключений), заключается в использовании свойства ресурса свойства ресурса , которое позволяет объединять несколько сервисов в один конечная точка.

Автор: alex Источник Размещён: 19.07.2016 06:29

Ответы (1)


3 плюса

22056 Репутация автора

Рой первый:

Прежде всего, разумное решение для огромного множества агентов требует как гибкости (в разработке структуры роя для добавления функций), так и эффективности (как для масштабируемости, так и для скорости ), чтобы достичь максимально возможного времени выполнения моделирования, несмотря на PTIME& PSPACEпрепятствия с возможным риском проникновения в EXPTIMEзону в более сложных схемах межагентской связи.


Эффективность следующая:

В первый момент я предпочел использовать и настроить немного более легковесную платформу сигнализации / обмена сообщениями на основе POSIX nanomsg- младшую сестру ZeroMQот Мартина СУСТРИКА, одного из отцов ZeroMQ, - где Context()без дизайна плюс Дополнительные функции SURVEYи BUSархетип обмена сообщениями особенно привлекательны для роев с помощью ваших собственных программно-разработанных протоколов обмена сообщениями / сигнализации для конкретных проблемных областей: введите описание изображения здесь


100k + с file_descriptorс

Ну, тебе нужна смелость. Выполнимо, но в конечном итоге, это потребует усилий в ядре, настройке параметров системы, и вы будете платить за такой масштаб за счет увеличения накладных расходов.

Эндрю Хаккинг объяснил как «за», так и против «только» увеличение fdколичества (не только на стороне ядра настройки и конфигурации системы).

Другими факторами, которые следует учитывать, является то, что, хотя некоторые программы могут использовать sysconf(OPEN_MAX)для динамического определения количества файлов, которые могут быть открыты процессом, многие программы по-прежнему используют Cбиблиотеку по умолчанию FD_SETSIZE, которая обычно составляет 1024 дескриптора и, следовательно, никогда не может иметь больше, чем эта. многие файлы открываются независимо от административно определенного верхнего предела.

Эндрю также обратил ваше внимание на это , что может послужить окончательным отчетом о том, как настроить систему для соединений 100–200 тыс .


Имеют ли какой-то реальный смысл для моделирования роя статические весы свыше 100 тыс. На хост?

Хотя все еще «технически» выполнимо, существуют и другие ограничения - даже nanomsgне удастся продвинуть больше, чем 1.000.000 [MSGs/s]достаточно, что достаточно для большинства приложений, которые не могут идти в ногу с этой собственной скоростью отправки сообщений. В некоторых ~6 [us]цитатах приводятся некоторые данные 3-4 [us]о задержках передачи между ядрами ЦП и ЦП, и если разработанное пользователем приложение обработки роя не может выполнить цикл отправки при некоторых показателях, потолок производительности близко не может вызвать проблему.


Как масштабировать выше этого?

Распределенная многоузловая обработка - это первое измерение, которое атакует статический масштаб роя. Далее будет необходимость ввести RDMA-инъекцию, чтобы избежать узкого места производительности при любой обработке стека при реализации распределенной передачи сообщений / сигнализации. Да, это может перевести вашу систему Swarm в зону задержек наносекундного масштаба, но за счет создания высокопроизводительной высокопроизводительной вычислительной инфраструктуры (что было бы отличным проектом, если ваш спонсор проекта может скорректировать финансирование такого мероприятия - + пожалуйста, дайте мне знать, если да , было бы более чем интересно присоединиться к такой лаборатории роу интеллекта HPC ), но стоит знать об этом значении, прежде чем принимать решение об архитектуре и знать конечные ограничения - ключ к успеху с самого начала.

Автор: user3666197 Размещён: 21.07.2016 04:12
Вопросы из категории :
32x32