Потратил несколько дней, изучая и настраивая кэширование.

Для начала надо сказать, что у меня windows и программы на SSD, файловая помойка и большие файлы на HDD.

Начнём с того как работает дисковый кэш. Исходя из статьи на оф сайте ms https://docs.microsoft.com/en-us/windows/win32/fileio/file-caching если включено кэширование файлов (пик 3) приложение отправляет запросы через посредника Cache Manager, который если файл ранее загружен в память берётся оттуда (ускорение чтения существенно, даже если SSD такая скорость быстрей у ОЗУ), если отсутствует загружается с диска и выдаётся приложению.

У меня 16 Гб ОЗУ, что по меркам сегодняшних дней и моего подхода к использованию ОС среднее значение, это не мало, но и не избыток. У меня может быть открыто несколько браузеров с десятком вкладок, несколько приложений, ещё и что-то загружается, либо рендерится на фоне. Всегда идут какие-то процессы и работа.

Если запускаю ещё и игру, то память забивается не меньше, чем на 60-70%, а если майнкрафт с модами может и под потолок. То есть ОЗУ мне нужна и тратить её например, чтобы кэшировать большие файлы игр или полноценные видео с HDD неразумно.

Поэтому я включил кэширование только на системном диске. На системном диске множество мелких файлов, библиотек, служб, а также часто используемых программ. Держать их в кэше на мой взгляд разумная идея. Несмотря на то, что кэширование включено только на системном диске, то в кэше набито около 9 Гб. Я открыл монитор ресурсов, в кэше именно файлы с диска C это в основном браузер, svhost службы и системные библиотеки. Не обращайте внимания на загрузку диска D я как раз провожу дефрагментацию.

Кстати о ней. HDD дискам она по прежнему необходима. Сегодня игры весят десятки гигабайт и подгрузка текстур или областей может быть замедлена, если эти огромные файлы разбиты по диску. Тут я не открыл ничего нового. Но вот отключение кэширования положительно сказывается на КАЧЕСТВЕ дефрагментации так как вместо обращения к Кэш Мэнеджеру программа обращается напрямую к диску и использует меньше ОЗУ во время своей работы. Любой дефрагментатор САМ кэширует скопированные файлы, чтобы после их записать. Безусловно кэширование системой ускорит дефрагментацию так как файлы будут писаться сначала в ОЗУ, но из-за такого подхода дефрагментатор не видит реальной картины. Он читает диск на который файл ещё не записан, так как кэш производит записи с интервалом (поэтому можно потерять данный при внезапном отключении электричества, кэш просто не успел записаться). Поэтому дефрагментатор видит пустую зону там где её нет и пытается произвести запись туда. Кэш менеджер в этом случае записывает не в строго указанную область, а в ближайшую свободную. То есть происходит промах, но из-за консолидации файлов сама отложенная запись происходит действительно быстрей, чем если записывать каждый файл поотдельности. Надеюсь вы поняли. Это тоже самое, когда вы копируете один файл на 10 Гб или копируете 10 тысяч файлов общим размером 10 Гб, запись в первом случае будет быстрей. Кэш по сути производит "склейку" и записывает разом их подряд.

Тем не менее, если у меня уже 9 Гб забито только системным кэшем на диске C, то нет никакого смысла имея 16 Гб ОЗУ врубать кэш на 2 разделе (там 1 ТБ), так как это приводит к замещению кэша файлами с диска D. То есть профит кэша падает. Об этом написано в статье по кэшированию в windows server, где написано, что в случае больших файлов, когда происходит частая перезапись в системный кэш это ухудшает производительность, а также операция очистки кэша, которая происходит при переполнение кэша также снижает производительность.

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

Если 2-ое полезная очистка, которая приводит к оптимизации, то первая это вынужденная мера и она может вытеснить используемые файлы, то есть снова вместо кэша будет использоваться диск, а также сама операция очистки, особенно частая сказывается на падении производительности. Это работает также как мусорный сборщик (garbage collector) в яве или в браузерах.

Третий момент, который нужно знать это Ленивая Запись. Суть в том, что windows при отсутствии особых комманд держит файлы в кэше и даже перезаписывает их там довольно продолжительное время. Опять же при внезапном отключении питания это может привести к потерям, но допустим у нас есть ИБП или же мы не сильно обеспокоены потерей данных. Это полезно для SSD. Так как перезапись происходит прямо в ОЗУ, а записывается только спустя время, мы можем сократить число записей при частой записи.

Это выгодно для всех логов, которые пишутся довольно часто, любая отладочная информация, браузеры, всё что часто пишет или менят файлы на диске. Но это практически ничего не даёт при ручном редком сохранении. Например это выгодно если у вас редактор автосохраняет каждое редактирование. Например вы пишите текст и сохраняется каждая буква, тогда кэширование не будет делать запись на диск каждый save а будет записывать изменения в system cache и спустя интервал уже делать запись на SSD. Но если у вас ручной save, то это не даст никакой разницы, так как пройдёт достаточно много времени между сохранениями и файл уже будет записан на диск.

>>2816
Что ещё вам нужно сделать, чтобы улучшить работу системного кэша.
1. Поставить 1 параметру Large System Cache в реестре (гуглите, если не знаете как это сделать). Это опция увеличивает размер кэша, что в случае использования только на системном диске полностью себя оправдывает. Вместо частой очистки, которая снижает производительность, выгрузка файлов будет более медленной, либо по необходимости, как я писал выше, когда требуется ОЗУ для текущих приложений.

2. Поставить 1 параметру DisablePagingExecutive . В нашем случае это приведёт к тому, что ядро системы, драйвера и прочие системно важные файлы не будут выгружаться на диск, несмотря на приоритет использования. Это безусловно положительно сказывается на общей производительности, но только если достаточно ОЗУ. Сами MS утверждают, что параметр следует включать при наличии 2ГБ ОЗУ и выше. Параметр древний так же как требования.

3. Задать файл подкачки равный 16 мб, либо по выбору системы. Отключение файла подкачки приводит к ошибкам в некоторых играх и приложениях даже если у вас достаточно ОЗУ. Также система более агрессивно выгружает из памяти приложения когда Pagefile полностью отключён. Это невыгодно, если вы имеете достаточно ОЗУ и хотите использовать оперативную память для ускорения производительности. 16 мб является минимальным размером, который будет использоваться, у выбора системы есть 1 минус. Размер превышающий 800мб используется для записи отладочной информации. Для SSD это означает, что файл подкачки будет всё равно перезаписываться отладочными файлами. Это практически ничтожно по сравнению с другими более агрессивными службами записи (больше всего записей создаёт журнал, поэтому кэширование на SSD ОБЯЗАТЕЛЬНО, несмотря на мифы, что кэш на SSD следует отключать, это вредно для SSD и менее производительно). Кэш для SSD не нужно включать только если он не является системным, на системном разделе журнал будет регулярно перезаписывать файлы на диск, кэширование существенно сокращает число этих записей на ваш SSD, перезаписывая чаще в ОЗУ и скидывая уже изменённые несколько раз логи на SSD спустя интервал, если файл был изменён.

Пара слов о Prefetch и Superfetch. Первая полезна так как собирает статистику подгружаемых файлов и запрашивает их до того как приложениею эти файлы понадобились. Например вы запустили фотошоп где требуется масса разных файлов, некоторые из которых подгрузились бы только когда вы воспользовались каким-то инструментом. Префетч в ходе использования программы уже знает, что это приложение требует таких-то файлов и подгрузит их заранее. Должен быть выбран параметр 3 префет обязательно должен быть включен для всех приложений.

Суперфетч вещь крайне вредная, если у вас нет избытка ОЗУ. Избыток на сегодня это это всё что больше 32 Гб. 64-128 Гб. Только в этом случае на сегодняшний день вы увидите профит от Суперфетч. Технология будущего, которая сегодня не работает из-за технических ограничений.

Суперфетч собирает уже статистику вашей работы за пк, собирает информацию когда и как часто вы запускаете те или иные приложения и по сути суперфетч загружает эти приложения за вас заранее. Это бы дало большой профит для игр, когда все игровые файлы, а игры весят 50-100 Гб сегодня подгружались бы в фоне, пока вы сидите в браузере своём и потом вы решили поиграть и игра моментально стартанула без загрузок. Но это невозможно по крайней мере на моих 16 Гб, во вторых это тратит ресурсы в фоне, сказываясь на текущей производительности, ну и у меня нет чёткого расписания, чтобы программа могла подстроиться. Я могу сегодня поиграть в одну игру, а через месяц в другую. Толку от суперфетч нет никакого. Поэтому суперфетч отключаем и ставим 0 напротив этого параметра.

Службу SysMain при это отключать не следует ни в коем случае. Это крайне полезная служба. Да она не будет анализировать работу и составлят расписание, если вы поставите 0 в реестре напротив суперфетч, НО SysMain также сжимает память в случае превышения вместо попытки записать в Pagefile.

Эта особенность появилась не сразу, поэтому многие не знают о ней и отрубают SysMain, хотя правильно оставлять её, но отключать супервыборку в реестре. Сжатие памяти это компоновка как в zip архивах, только в озу. Тем не менее, если у вас слабый процессор с 1-2 ядрами, службу смело можно отключать.

Узнать сколько памяти сжато вы можете в диспетчере задач наведя на полоску используемой памяти. Если у вас полно свободной памяти, windows не будет сжимать большие объёмы, она делает это сильней, когда используемая ОЗУ подходит к концу. При этом sysmain не будет сжимать уже сжатые файлы, только то, что хорошо и легко подвергается сжатию. Поэтому влияние на процессор хоть и будет при нехватке ОЗУ, но это гораздо лучше, чем сброс в Pagefile или килл процесс, который Windows произведёт, в случае если ОЗУ на исходе. SysMain даёт до 30% чуть более медленной ОЗУ за счёт сжатия, скорость которой напрямую зависит от мощности вашего CPU.

>>2817
Раз уж поделился настройкой кэша, подкину парочку сетевых твиков.

Не все знают, что в Windows есть ограничение на максимальное количество одновременных соединений, чего нет в серверной версии.

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

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

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

Очевидно, что мы хотим освобождать неиспользуемые коннекты раньше, чтобы они освобождались для новых соедений и не рвались активные соедения. Яркий пример вы играете в игру сетевую, при этом у вас запущен тимспик и браузер. Вы открыли много вкладок наоткрывались коннекты, но вы уже не смотрите вкладки, при этом в тимспике добавилось несколько людей и происходит обрыв в игре потому что потребовалось освободить коннекты, но после снова открылось уже новое соединение с игрой и браузерные наконец-то освободились, потому не переподключились сами по себе. Увы но это так работает.

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

В случае с клиентом, мы можем сократить ожидание до закрытия не используемого соедениянения до 30 секунд.

Делается это по адресу

>Компьютер\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

>TcpTimedWaitDelay = 30 (параметр DWORD, значение Decimal)

>TcpFinWait2Delay = 30 (параметр DWORD, значение Decimal)

Первый отвечает за закрытие закрытых соединений, второй полузакрытых. Это могут быть тысячи соединений, оставшихся в ходе работы торрента или месседжеров, браузеров и системных служб, игр и тп. Например кажды сид создаёт с вами соединение, которое система даже после закрытия держит ещё 4 минуты, но сид уже отлетел он вам ничего не даёт, ничего не получает, но виндовс будет держать соединение 4 минуты! 30 сек это минимальное значение, меньше не будет работать.

Параметры нужно создать самому, если нет.

Также будет полезно увеличить максимальное число доступных портов. Делается это тамже параметром

>MaxUserPort = fffe (шестнадцатеричные понятно)

Ограничения портов связаны с безопасностью, но это полезно при использовании многих программ.

Ну и в конце отключаем автотюнинг

>netsh int tcp set global autotuninglevel=disabled

Подробнее о нём читайте в сети. Если кратко это автоматическое замедление скорости якобы для стабилизации, но это работает плохо и после понижения скорость не возвращается длительное время. Особенно заметно будет в wifi сетях и на быстрых скоростях. И это не тоже самое, что автопонижение скорости в роутерах, это именно опция винды, которая может снизить скорость просто потому что решила, что это облегчит ей загрузку вот того процесса, освободив немного процессорного времени. Эта опция часто приводит к падению скорости при большой нагрузке на процессы, например вы играете в требовательную игру и внезапно ловите лаги или резкое падение скорости, когда процессор нагружен, хотя у вас сетевуха сама обсчитывает многие вещи, но Windows похуй на это, она считает, что снизив скорость освободит ресурсы.

Вот тут почитайте, если интересно
https://windowsnotes.ru/other/otklyuchaem-tcp-window-auto-tuning-v-windows-7-i-windows-server-2008/

Кстати настоящая ПОЛНАЯ дефрагментация скажем террабайтника забитого на 80% занимает несколько часов.

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

Сейчас почти все современные подобные программы вместо консолидации места и дефрагментации с записью "подряд" хитрят и собирают только файлы больше определённого размера и очень вольно относятся к заполнению. Очень часто остаются не заполненные места, что быстро приводит к новой фрагментации.

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

Поэтому я использую довольно олдовую программу MyDefrag, которая использует windows API и позволяет провести честную дефрагментацию. На первом пике результат спустя часов наверно 8. При этом там можно провести более быстрые дефрагментации, сортировать по имени, дате, можно смещать файлы в конец диска, но лучший и провеверенный временем способ это именно честная дефрагментация без всяких ухищрений. Она же даёт лучший результат в итоге.

Для этого нужно
1. Выбрать пункт дефрагментация и оптимизация
2. Убрать галку
3. Поставить Gap = 0% (gap это отступ от центра диска, оставляемый при возможности пустым. например если бы я поставил 30%, то файлы сместились бы к концу диска и новые файлы писались бы не после, а перед в более близкой к MFT зоне, что сокращает время отклика для файлов, но на современном железе и при условии что на диске много больших файлов важней их правильно дефрагментировать и убрать пустые места между файлами, чтобы повысить скорость чтения, ntfs в любом случае будет писать быстро хоть в начало диска, хоть в конец, а вот скорость чтения в конце диска явно хуже так как расстояние от MFT до самих файлов выше, но если эту разницу ты не почувствуешь при дефрагментации, то в ситуации, когда диск фрагментирован и твои файлы смещены в конец, производительность заметно ухудшается).
4. Запустить (приготовься что этот процесс отнимет большое время)

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

Я могу судить по скорости загрузки по тяжеловестным играм, таким как Fallout 4 с официальным HD текстур паком, который весит больше самой игры и HD оф паком текстур для ККД. Это две довольно весомые игры с ощутимыми загрузками. Обычная "быстрая" дефрагментация даёт эффект для них, но с полной дефрагментацией, которую я уже проводил когда-то и почему я готов тратить столько времени хотя бы раз в месяц (более 8 часов), само ускорение и выигрыш в скорости такой, что это стоит потраченного времени, тем более дефрагментация не мешает мне сидеть в интернете или использовать программы с системного диска. А вот записывать во время дефрагментации на диск или что-то запускать не рекомендую так как файлы либо могут оказаться заблокированы, либо при записи вы можете забить уже просчитанные места фрагментами файлов и по сути вам придётся заново запускать дефрагментатор, чтобы он пересчитал всё заново, иначе ваш перфекционист внутри будет негодовать, увидев оставшуюся фрагментацию.