У меня есть сервер Solaris, который должен запускать критичное ко времени приложение как можно быстрее, хотя установка для него класса приоритета RT не кажется хорошей идеей, так как ему может потребоваться 100 ЦП на длительное время.
Я хотел бы использовать время простоя процессора для работы с другими процессами, но этот процесс не должен получать время процессора вообще, если критичному по времени есть что-то делать. Как я могу добиться этого, используя nice -19, не выделяет 100% процессора для критического по времени.
В проекте планирования Solaris невозможно установить жесткие ограничения, которые вы ищете. Ближайшие варианты:
Предоставленный ответ @jlliagre приблизит вас, чем стандартные значения по умолчанию для модели планирования, но он по-прежнему не предотвращает получение некритическим процессом процессорного времени.
Если у вас больше процессоров / ядер, чем количество потоков критического процесса, то RT легко удовлетворит ваши потребности. В противном случае, если вам не нужно использовать систему каким-либо другим способом, RT может быть не очень хорошей идеей. Вы можете легко оказаться в ситуации, когда вы даже не можете войти в систему из-за того, что критический процесс не оставляет для него никакого ЦП.
Запустите второе приложение с фиксированным классом приоритета и с самым низким из возможных приоритетов. Если он уже запущен, вы можете установить его, используя его pid:
priocntl -c FX -m 0 -p 0 -s -i pid <pid>
Или сделайте это во время запуска:
priocntl -c FX -m 0 -p 0 -e command [arguments ...]
Редактировать:
Обратите внимание, что класс планирования FX не следует путать с классом RT. Хотя класс приоритета RT (реального времени) также является классом с фиксированным приоритетом, процессы, которым предоставляется приоритет RT, будут вытеснять системные потоки (то есть ядро), поэтому их следует использовать только с процессами с относительно короткими периодами вычислительной активности. Класс RT категорически не рекомендуется для процесса, требующего 100 потоков ЦП в течение длительного периода времени, подобного описанному вами. Эта проблема не существует с классом FX, диапазон приоритетов которого (по умолчанию) такой же, как и у обычного режима разделения времени.
Как отметил в своем ответе Едрик, установки для процесса низкого приоритета значения 0 недостаточно, чтобы гарантировать, что он вообще не будет работать, когда активен высокий приоритет.
Причина в том, что последний находится в классе разделения времени, планировщик заметит, что процесс некоторое время ждал, поэтому снизит фактический приоритет критического процесса до 0, допуская небольшие всплески активности от процесса с низким приоритетом.
Чтобы избежать этой ситуации, вы можете установить критический процесс для класса FX со средним приоритетом. В таком случае он никогда не уступит другому:
priocntl -c FX -m 30 -p 30 -c critical_command ...