Comments 16
А это "перекладывание бумажек" отражается на цифрах потребления памяти в диспетчере задач? Если да, то это, возможно, ответ на претензии пользователей "почему процессы потребляют столько памяти?! сделайте меньше".
Причем, эти претензии чаще всего возникают даже тогда, когда свободной памяти ещё полно. Игнорируя тот факт, что незадействованная память - это память, простаивающая впустую. Если её можно задействовать для чего-то полезного (допустим, увеличить разные кэши: кэш ресурсов браузера, кэш файловых операций), то её нужно задействовать. Лишь бы приложения могли оперативно отдать эту память, когда системе она понадобится для чего-то более важного, например, для запуска ещё какого-то процесса. Можно провести пример с финансовой подушкой: если вы просто держите некоторую сумму денег под подушкой в ожидании "черного дня", который наступит неизвестно когда и вообще неизвестно наступит ли - это неэффективно. Разумнее их пустить в какое-то дело, откуда их можно при необходимости достаточно оперативно вывести.
В таком случае, всё логично: пользователи хотят всегда видеть свободную память, пользователи получили то, что хотели. А то, что они получили дебилизм (который визуально что-то делает, но на практике бесполезен и даже слегка вреден) - следствие того, что их хотелка была дебильной.
Проблема в том, что может они и должны оперативно отдавать эту память, но не отдают. Я неоднократно наблюдал, что если в диспетчере задач оперативки показывается мало, то это означает, что её реально мало, что при попытке запустить что-то требующее больше памяти гарантированно приведёт к активному свопу (в особо тяжких случаях вся система может встать колом и перестать реагировать на действия пользователя, гоняя данные между свопом и оперативкой много часов, пока её не грохнешь резетом). А запуск чего-то типа виртуальной машины, где виртуальная память не катит, а требуется физическая оперативка, и вовсе оказывается невозможным, память не выделяется.
Может быть, диспетчер задач показывает как раз реальное использование, вычитая ту часть памяти, которая может быть мгновенно отдана под нужды других программ? Но тогда придётся признать, что жалобы пользователей на высокое потребление оперативы более чем обоснованы. В общем, я уже много где читал эти мантры про то, что "память не должна простаивать пустой", но в реальной жизни мои наблюдения оказываются в точности противоположными.
У винды уже много лет сохраняется "фича" - засовывание в оперативку огромных файлов при малейшем к ним обращении. Т.е. это (как минимум до десятки) на всех версиях можно посмотреть примерно так: запускаем любое кино, выключаем, запускаем RamMap и смотрим вкладку File Summary - видео файл будет там видно. Причем там будет прям гигабайтами забито.
И ладно бы - мало ли зачем файл вдруг повторно понадобится. Но по какой-то причине ос считает эти данные более приоритетными, чем личные данные программ. И в условиях недостатка памяти (<16 гигов оперативки, программами занято 80%+ памяти) в своп почему-то начинают улетать именно программы и их данные. А не очищаться кешированные бесполезные файлы. А еще эти кешированные файлы почему-то сами не чистятся с течением времени.
Вот тут как раз очистка Standby-list'а и помогает на некоторое время. Пока ос опять какое-нить кино не закеширует.
Фича ещё и сгубляется шаманской работой из prefetcher'ов всех поколений. Которые грузят в ОЗУ вообще чёрте что, вроде просмотренного вчера фильма. И не просто в ОЗУ, они ещё и копии всего загружаемого на диске делают.
Там полнейшее безумие.
Так ваши фильмы - это отображаемые на память файлы и после закрытия видео память уходит в Standby и будет выделена другим процессам при нехватке Free памяти.
И конечно ссылки на файл будут в памяти, чтобы при повторном открытии не пришлось заново перечитывать файл с диска. Удобно же.
Так я и не говорю, что это плохо. Я говорю, что там или баг, или проблемы с логикой. Потому что файлы кеширует в ущерб программам - вытесняя их в своп. И даже если потом к этим программам обращаться, то этот кеш не чистит и программы теперь начинают драться за остаток памяти, постоянно улетая в своп. А бесполезный видео файл, просмотренных 2 дня назад - так и будет занимать память.
Всё это особенно хорошо видно в условиях нехватки памяти. Ну не знаю, если на 6-8 гигах оперативки работать, занимая её на 90%.
Да не будет файл висеть в памяти, если закрыт просмотр. Если он висит - значит баг уже в приложении просмотра.
Да и что значит в ущерб программам? При конкуренции за память, предпочтение отдаётся активным процессам.
Ну это факты, с которыми я лично сталкивался много лет. Т.е. да, по логике, кешированные файлы должны вовремя вытесняться и всё это должно быть незаметно. А по факту, винда почему-то их очень "любит" и хранит в памяти до упора, сутками, при полном отсутствии к ним обращений в течение этого времени.
При конкуренции за память, предпочтение отдаётся активным процессам.
Ага. В идеале. А по факту - часть памяти занято кешированными файлами и активным процессам ее не хватает, поэтому они идут в своп. С появлением ССД это стало не так сильно заметно, но всё равно подлагивания, например, вкладок у хрома было видно (у меня их много).
В общем, я уже много где читал эти мантры про то, что "память не должна простаивать пустой", но в реальной жизни мои наблюдения оказываются в точности противоположными.
Не знаю как там во всяких Linux и серверных версиях, но в "бытовых" Windows ничего не простаивает. Вся свободная оперативная память идёт на дисковый кэш. Значение Available в Task Manager стабильно равно значению Cached. И RAMMap всё показывает соответственно.
Task Manager'ом я перестал пользоваться ещё со времён XP, так что сорри, с ним я не имею накопленных наблюдений. Сам пользуюсь Process Explorer'ом и Process Hacker'ом, и ориентируюсь на их показания занятости физической оперативки. Не могу с уверенностью сказать, что именно они меряют, так как в разных типах кэшей, маппинга и прочих особенностях управления памятью сам чёрт ногу сломит. Но зависимость прослеживается совершенно чётко: если они показывают, что свободной оперативки мало, то можно быть уверенным: когда она потребуется, никто мне волшебным образом её не освободит, а будет жуткий своппинг и будут ошибки выделения памяти. Конечно, какая-то часть задействованной другими программами памяти, если она не используется активно, может уйти в своп, и это освободит некоторый объём. Но это всё равно вызывает тормоза и никоим образом не соответствует распространённым уверениям, что "Хром на самом деле ничего не сожрал, стоит только намекнуть, как он в мгновение ока всё вам радостно вернёт".
А что вы называете свободной оперативкой? Если в системе есть Free память, и она никак не используется системой, то значит, что её избыток. Ну и когда требуется память, то да, в первую очередь отдаётся из списка Free, потом Zeroed, и потом уже Standby. И разумеется, что Active вам никто не отдаст. И вот этот показатель как раз и является важным - сколько на самом деле памяти используется в работе.
Я (как и большинство не слишком опытных пользователей) просто открываю диалог сводной информации, и вижу там общую сводку в категории Physical memory: Current — столько-то, Total — столько-то. И я вижу, что когда хромоподобные браузеры (да и любые другие программы) начинают жрать память, значение Current начинает увеличиваться. И я неоднократно наблюдал, что когда значение Current слишком приближается к Total, это означает проблемы.
Я не изучал детально, как конкретно Process Explorer и Process Hacker подсчитывают объём потребления физической памяти. Но по опыту выяснил, что это адекватный параметр, позволяющий оценить реальное состояние системы. Так что с практической точки зрения оно не столь уж и существенно, какие конкретно виды страниц и кэшей там учитываются и каким образом. Главное результат.
Реальной проблемой это становится, когда неопытные пользователи начитаются советов в интернете и для якобы увеличения производительности начинают отключать файл подкачки. Надеюсь, это не ваш случай.
Плюс рекомендация иметь на диске С запас свободного места в 15% (отсюда и окраска в синий-красный цвет полоски заполненности) тоже имеет под собой некоторые весомые причины.
Ну и вообще, если в процессе работы за ПК Current близок к Total - это идеальная ситуация. Значит память утилизируется полностью и достигнут баланс.
Разумеется, своп у меня включён. Хотя бы по той причине, что в случае BSOD'а без свопа не создаётся дамп, по которому можно попытаться найти источник проблемы.
Касательно "идеальной ситуации" позволю себе не согласиться. То есть, если абсолютно все нужные программы уже запущены, загрузили все нужные им данные и спокойно работают, то да, это норма. Но в реальной жизни так не бывает. Разве что на каких-то серверах, которые что-то там молотят, и их никто не трогает. А пользователю обычно нужно запускать другие программы, загружать в память новые данные. И если вся память уже занята, то новым программам негде развернуться.
Похоже, что данный баг объясняет невероятно медленную работу достаточно большого числа всяких установщиков и патчеров под Windows. В том числе и производства самой MS.
А как работают процессы, которые большие by design? SQL server, например?
Баг памяти Windows, которому не менее восьми лет