[Iska]

__sa__nya, Вы на WinRAR'е просто тренируетесь, я понимаю?

[__sa__nya]

__sa__nya, Вы на WinRAR'е просто тренируетесь, я понимаю? »

- Да, верно, я просто пытаюсь понять логику работы.

[Iska]

__sa__nya, я, конечно, не специалист в этом вопросе, но как именно Вы определяете, что «он жрет 95 %», что это означает? Сколько на стенде всего ядер? Вы помните, что WinRAR умеет использовать их все параллельно? Не влияет ли как то этот факт на результаты наблюдения?

[__sa__nya]

но как именно Вы определяете, что «он жрет 95 %», что это означает? »

- запускаю процесс архивирования файла, смотрю в диспетчере задач нагрузку на процессор в %, она "гуляет" от 80 до 98 %, чаше выше 90.
На стенде 2 ядра. Параллельное использование ядер (как я понимаю) не влияет, т.к. если в WSRM установлено в общем ограничение на процессорное время, например в 10 %, то он и будет (должен) держать приложение в этих рамках, но по факту не держит.

Здесь прочитал что:

Диспетчер системных ресурсов Windows управляет ресурсами процессора только в том случае, когда суммарная нагрузка на процессор превышает 70 процентов. Это означает, что он не будет активно ограничивать ресурсы, которые могут использоваться каждым потребителем, при низкой нагрузке на процессор.

Подумал, что из-за этого не ограничивает. Изменил условия:
1. Скопировал на сервер Everest,
2. Удалил политику для Winrar'a
3. Создал политику на ограничение в 10 % процессорного времени для Everest'а.

В теории, как понял я, если, например на сервере идет нагрузка на проц больше 70 %, и часть этой нагрузки - одна из программ, для которой установлено ограничение в % меньше чем 70 (порог), то должен вмешиваться диспетчер ресурсов, и снижать нагрузку на процессор для приложения на которое установлено ограничение.
Проверяю: запускаю архивирование файла Winrar'ом, он начинает жрать 90 %, в Everest'е запускаю "Тест стабильности системы" и выбираю тесты связанные с процессорами - Everest начинает забирать от 30 до 70 % процессора, суммарная нагрузка на процессор 100 %. WSRM нагрузку на процессор до 10 % со стороны Everest'а никак не понижает.

В общем, либо он как-то хитро настраивается, либо этот компонент реализован в ОС криво и по факту не работает.

[Iska]

Именно по WSRM я Вам, увы, ничего не подскажу.

[__sa__nya]

Iska, разобрался. Как говорится - "Русский человек начинает читать инструкцию тогда, когда понимает что что-то сломал" :-).
В консоли WSRM устанавливаешь предел ресурсов для приложения. Я думал что это тот предел, за который приложению не разрешается выходить, но почитав справку понял, что наоборот - те ресурсы, которые указываешь, они наоборот гарантируются приложению, т.е. логика полностью наоборот в отличие как я думал:

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

Проверил: создал политику для WInRar'а с гарантией 60 % процессорного времени, отключил диспетчер ресурсов, запустил архивирование файла Winrar'ом, запустил тест стабильности Everest - Everest - 98 %, Winrar 3 %, включил политику - Winrar от 45 до 62 %.
В общем всем спасибо за помощь.

Если резюмировать, в диспетчере ресурсов Windows (WSRM) при создании своих политик, указывающих на конкретные приложения, предел процессора - не ограничение для процесса, а гарантированный мимимум для него, а вот указание предела оперативной памяти, как раз ограничение.

[Iska]

__sa__nya, ничего, бывает. Главное, что таки разобрались. Я теперь вот тоже новое узнал благодаря Вам. Хотя пользовать навряд ли когда придётся .