когда-то уже делился инфой, но не лишним будет повторить пройденное

>Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl

параметр

>Win32PrioritySeparation

в Windows есть такая штука как квант времени, который выделяется процессам. его длительность можно чекнуть через утилитку консольную с сайта майкрософт под названием Clockres
https://learn.microsoft.com/en-us/sysinternals/downloads/clockres

выше я написал путь реестра. это значение меняется на соотношение 18:6 если выбран приоритет программ и 36:36 если отдавать предпочтение фоновым задачам

чтобы понять сколько времени винда отдаст процессу нужно умножить базовую длительность одного кванта на число квантов. например если 1 квант = 0.1 мс, то 36 квантов это 3.6 мс на один процесс. много это или мало? давайте сравним с привычным значением обновления герцовки монитора 60 Гц или 60 раз в секунду 1000 / 60 = 16 мс. получается, что на 1 процесс, а их может быть свыше сотни в серверной винде, где по дефолту приоритет отдан фоновым задачас на каждую задачу выделяется такое время какое в среднем требуется на вывод меньше 1 кадра в секунду. вау, кажется, что это довольно быстро. и да и нет. для монитора это конечно прекрасные значения, но не для псевдомногопоточности

когда у вас множество ядер конечно вам выгодно давать больше времени на каждое отдельное физическое ядро. например у вас 12-16 ядер и вы отдаёте на каждое из них больше квантов на 1 процесс. то есть за одно такое выделение группы квантов вы сразу охватите 16 процессов и это весьма эффективно, чем больше у вас ядер тем более выгодно

но возьмём для примера 4 ядра. за 3.6 мс в моём случае а у кого-то будет 36 мс, вы пройдётесь всего лишь по 4 процессам. то есть за 1 секунду по 277 процессам. конечно это не всё так плоско работает. когда у вас разные приоритеты и есть активный процесс и фоновые процессы, то в случае 18:6 отношения активный процесс получит больше времени, чем фоновые и конечно же это гораздо лучше чем вариант для серверных систем. но суть я думаю вы уже улавливаете.

чем меньшее у вас количество ядер, тем выгоднее сильнее дробить квантование и выделять минимально возможные группы, чтобы Windows могла за 1 единицу времени обрабатывать большее число процессов. в моём случае при установке отношения 6:6 получается, что не 277 процессов в секунду, а 1662 процесса в секунду.

а теперь про реальный опыт. я хорошо тестировал следующие варианты
А) 36:36
Б) 36:12
В) 18:6
Г) 6:6
Д) 12:12

среди тестов была как синтетика, которая показала небольшую разницу, а так же я запускал на фоне рендеринг одного видео с одним сетапом кодировки и в это же время спустя 30 секунд запускал CPU-Z. то есть при 100% нагрузке на процессор запускал синтетику и тут уже была большая разница. напомню у меня 4 ядра всего.

при А был самый низкий результат, при Г и Д самый высокий, а Б и В показали средние результаты. сразу скажу, что в играх распределение отличалось. там в лидерах был вариант В и Г, чуть хуже Д, затем Б и снова хуже всех А. собственно во всех статьях так и пишут, что А подходит для слабонагруженных процессов на серверах, когда давая больше квантов этим процессам есть выше вероятность, что они успеют завершить операцию и через семафор отдать управление раньше, чем закончатся выделенные кванты времени. таким образом снижается вдолгую экономится момент переключения контекста, что даёт на долю процента больше экономии энергии, что практически незаметно на 1 машине, но будет иметь значение на сервере из десятков тысяч машин определённо, но как по мне на домашнем компе есть гораздо более серьёзные способы экономии энергии, например правильно настроенные режимы энергосбережения и переключение на энергосбережение, когда вы отходите от компа или спите, но это другая тема.

так вот топами стали 3 варианта, а именно 6:6, 12:12, 18:6 (последний стоит по дефолту в прошке). вообщем-то вы можете ничего не менять, потому что разница по производительности между 18:6 и 6:6 на уровне 2% на моём 4 ядерном компе с частотой 4.1 ГГц. но есть один довод в пользу именно 6:6. дело в том, что активным процессом не всегда является тот процесс, которому стоит выделять больше квантов. то есть в теории звучит красиво. дадим активному процессу в три раза больше квантов. но в современном мире, когда чаще используются многопоточные и многопроцессорные приложения, может сложиться так, что один из процессов который система считает активным получит в 3 раза больше квантов, чем остальные, хотя они могут выполнять одну задачу. яркий пример браузер, когда у вас есть несколько процессов для рендеринга, обычно 2-4 процесса (HW) так вот они должны для лучшего профита получать равное количество времени, но я лично не знаю какой из многочисленных процессов браузера виндовс посчитает активным процессом, возможно тот у которого выше нагрузка, а может тот, что был запущен первым или тот, что отвечает за само окно, потому что как пишет Марк Русинович, к приоритету окна добавляется +2 если это окно находится в фокусе (то есть вы мышкой на него нажали и оно стало выше по приоритеу, даже если рядом окна такого же приоритеа например уровня normal, то оконо в фокусе будет считаться активным, а остальные по сути получат в 3 раза меньше времени на обработку относительно него).

ВАЖНО! когда вы лезите в дополнительные настройки системы в пункт быстродействие и например меняете файл подкачки, то вы прожимаете apply или ok. так вот неважно трогали вы круглешки или нет, в этот момент происходит перезаписывание параметра РЕЕСТРА. поэтому если вы что-то там меняли вам придётся зайти в реестр и заново выставить нужное вам соотношение квантования. либо вы можете просто сделать себе reg файл, на который кликом установите нужный вам приоритет отношений.

ВЫВОД

для небольшого числа ядер 2-8 ядер, не стоит ни в коем случае использовать отношение 36:36. лучшим вариантом будет значение 0x24 (36) то есть 6:6

при среднем количестве ядер например 12-20, разумно ставить 0x14 (20) а именно 12:12

если же у вас сервер с 20+ ядер и вам важно энергосбережение на протяжении многих лет стабильной работы, то можно ставить или 0x28 (18:18) или если у вас запредельно много ядер, то 0x18 (36:36)

разумеется значения вступают в силу только после перезагрузки

отличная статья на данную тему на русском языке (оттуда взята таблица)
https://wasm.in/blogs/kvantovaja-separacija-ili-razbiraemsja-s-win32priorityseparation.701/

и ещё более полезная статья Марка Русиновича тоже на ру
https://thelib.ru/books/russinovich_mark/2_vnutrennee_ustroystvo_windows_gl_5_7-read-7.html

если вы хотите попробовать, но вам лень лазить по реестру, можете в блокнот скопировать:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl]
"Win32PrioritySeparation"=dword:00000024

и сохранить как .reg файл

в случае, если вам что-то не понравится, то всегда можно вернуть заводские установки просто зайдя в доп настройки системы и прожать ок как на 2 пике

>>2291
ты можешь поставить и половину от оперативы, разница небольшая 16% всего лишь.

я замерял следующим образом. создавал файл подкачки с шагом 4 Гб (4, 8, 12, 16), перезагружался, запускал браузер, несколько приложений + игру (в тот момент это была rdr 2). после чего снижал общее количество доступной оперативной памяти по 1-2 Гб через создание рам диска, который отжирал текущее пространство и отслеживал поведение Windows.

во всех экспериментах, включая в том, где я полностью отрубал файл подкачки при пересечении 66% от общего числа доступной памяти винда начинала убивать прежде всего браузер. вкладки переставали адекватно отображать содержимое. иногда браузер подвисал, иногда продолжал работать, но каждый раз происходили ощутимые подвисания и лаги именно на этом.

этого не происходило при 12 и 16 гб, так как максимум опускал количество доступной оперативы (которая была занята приложениями также) до 7 Гб, ниже уже не имело смысла, так как вылетала или висла игра и освобождалось слишком много оперативы снова за счёт убийства процесса жрущего.

таким образом путём личного опыта, многократно подтверждённого я обнаружил точный коэффициент. это ровно 2/3 от общей памяти.

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

официальные лица майков на их сайте вообще советуют ставить файл подкачки x1.5-2 от ОЗУ. я не знаю откуда они берут эти значения, возможно из прошлого, когда у людей не было даже 4 Гб оперативы, но сегодня оптимальным для ПОЛНОГО использования ОЗУ и при этом экономии места на диске является именно размер файла подкачки 2/3 от вашей оперативы или проще говоря примерно 0.66 x ОЗУ

например для 8 гб оптимальный размер подкачки - 5 гб, для 16 гб - 10 гб, для 32 гб - 20 гб, но начиная с 32 гб файл подкачки можно ставить гораздо меньше (отключать полностью не рекомендую всё равно) даже если поставить например 1 гб подкачки на 32 гб, то вряд ли система съест сегодня 20 гб в обычных задачах. но есть конечно некоторые вещи, когда даже тогда следует иметь большой файл подкачки. например игра майкрософт флай сим, где мне пришлось выставлять 20 Гб файл подкачки просто чтобы игра не вылетала. так же HZD на релизе вылетала пока я не поставил 10 Гб подкачки, тогда у меня было выставленно по выбору системы и игра просто вылетала иногда сразу, иногда спустя некоторое время. после установки 10 Гб при моих 16 гб игра прекрасно работала без всяких проблем на ультра настройках.