Чтобы сбалансировать потребление ЦП пользователями на общем вычислительном сервере, я бы подумал, что было бы очень полезно, если бы можно было:
Идея состоит в том, что пользователь может вызывать столько вакансий, сколько хочет. Но если есть другие пользователи, его приоритет будет падать в зависимости от того, сколько он просит. Таким образом, A может использовать все 32 ядра одновременно. Затем приходит другой пользователь B и запускает только 1 задание. Теперь A должен получить более низкий приоритет, чем B. Затем приходит C и запускает 8 заданий. Теперь у него должен быть приоритет между A и B. Однако на самом деле приоритет должен основываться не на количестве процессов, а на их общей нагрузке на ЦП - если это вообще можно определить.
Я предполагаю, что это может быть то же самое, что присвоить одну и ту же долю ЦП всем активным пользователям, если они используют ее, а остальное распределяют среди всех, кто хочет большего.
Как вы думаете, это вообще возможно?
Как вы думаете, это вообще имеет смысл?
Чрезмерно упрощенным подходом было бы вообще не квотировать их. В этой 32-процессорной коробке A + B + C - это 41 задание. Плюс некоторые, надеюсь, небольшие системные издержки для ядра. Однако не все зависит от ЦП, и есть узкие места в операциях ввода-вывода, памяти и т. Д. Таким образом, средняя нагрузка на самом деле не 41, время отклика и пропускная способность могут быть приемлемыми. Конечно, нет никаких средств управления, чтобы предотвратить дальнейшую загрузку, вызывающую проблемы с производительностью.
Возможно, ресурсы следует разделить пропорционально пропорции. Вот что например Планировщик справедливой доли в Solaris делает. Скажем, каждый из A B и C - это проекты в некоторых зонах из 32 основных пулов, и у каждого из них по 1000 долей. (Видеть Заметки Грега для практических примеров зон.) B и C будут работать на 100%, потому что они использовали меньше своей трети. Но A работает на 23 процессорах, потому что 1 + 8 необходимы, чтобы предоставить B и C их долю. Неравные доли возможны, если вы, администратор, придумаете схему их назначения.
Группы Linux пришли позже с чем-то похожим. Контрольные группы ЦП могут использоваться для реализации пропорциональных долей или определенных квот. Так распределяются срезы systemd и ресурсы ЦП Kubernetes.
Поскольку многие задачи ожидают выполнения, в идеале планировщик не оставляет ничего, что ожидает слишком долго, чтобы загрузить процессор. На микроуровне то, как работают очереди выполнения или эквивалентная работа, также имеет значение для работы системы.
Планировщик Linux CFS разделяет временные отрезки для каждой ожидающей задачи, что в этом отношении справедливо. Далее, первыми берутся те задачи, которые потратили меньше времени. Что имеет полезный эффект: приоритезация интерактивных вещей и ожидание ввода данных пользователем.
Приоритет, включая значение nice, является входом для решения планировщика. И он не полагается на квоты, искусственно ограничивающие использование, и это хорошо. Однако изменение приоритета, даже если для этого существует схема, имеет ограничения. Один общесистемный номер приоритета не помогает, когда у каждого пользователя есть задачи разного приоритета, но ему все равно нужно сохранять справедливую долю ресурсов.