Назад | Перейти на главную страницу

Динамическое ограничение того, какой процессор запускает новый процесс

Итак, я вкратце посмотрел на cgroups и numactl, но ни один из них, судя по информации, которую я нашел, не является тем, что мне нужно.

Мы используем программное обеспечение «fast-X», чтобы наши пользователи могли входить в свои графические сеансы по сети. у него есть ужасный недостаток: когда он начинает работать на системе с более чем 120 ядрами, производительность падает. Проблема в том, что наши большие дробильные машины представляют собой 240 основных систем.

Поэтому мне нужно найти способ, который мог бы динамически сказать: «О, кто-то запускает процесс fastx, ограничьте его этими ядрами X», поскольку numactl и cgroups, похоже, зависят от того, запускаете ли вы процесс с их помощью или принудительно перемещаете процесс. после того, как это началось, они мне не подходят ...

Для тех, кто не знаком с fastx, а их, вероятно, много, это, в основном, клиент удаленного рабочего стола / X11, который сохраняет сеанс пользователя и в целом (на 120-ядерных системах или меньше) имеет отличную производительность. Таким образом, пользователь будет подключаться к серверу через приложение Windows, которое затем автоматически запустит свой сеанс, поэтому мне нужно что-то на стороне сервера, которое будет автоматически ограничивать его, а не что-то, что нужно было бы принудительно запустить .

Пока я ничего не нашел, любая идея будет оценена по достоинству.

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

Если теоретически возможно сохранить достаточно маленькую очередь, пользовательский вход в систему может автоматически отправлять интерактивное задание в очередь, а затем запускать результаты в качестве консоли входа пользователя в fastx. Можно даже настроить механизм, который ограничивает пользователей определенными группами процессоров, чтобы гарантировать, что ни одному пользователю не будет разрешено слишком много ресурсов. Однако, если очередь становится слишком большой, пользователям придется ждать, пока станут доступны ресурсы.

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

Хотя это не совсем похоже, есть пример расписания Fastx на кластере Biowulf в NIH. Похоже, они используют пакетный сценарий PBS для запуска заданий через планировщик, поэтому некоторые концепции можно использовать повторно.

Этот пример из Корнелла также, похоже, демонстрирует использование Fastx с PBS, так что похоже, что что-то было сделано раньше. Хотя этот пример, по общему признанию, немного устарел.