оценка использование памяти
 

насколько адекватно Windows 10 (1909) оценивает загрузку оперативной памяти?
Если штатные средства ос делают это не очень адекватно (так ли это на самом деле?) - какими средствами лучше пользоваться
Запускаю программу (игру) по всей видимости расходующую немало памяти. Диспетчер задач показывает что запас памяти еще есть

Но фактически, система работает не стабильно. Браузер начинает часто показывать "опаньки".. а при дальшнейшей загрузке памяти (например открытие новых вкладок) - Windows может показать чёрный экран, всё замирает, перезагружается "Проводник" и система "пытается восстановиться". При этом диспетчер задач показывает, что "запас по памяти" всё еще имеется.

Допустим, имеется физические проблемы с модулями памяти (одним, установлен модуль 8 гб).
Может ли быть такое, что заполнение этого модуля происходит не хаотически. И сбой наступает именно при использовании конкретного сегмента памяти? И так совпадает, что пока я не загружаю память "на всю катушку" - сбоя не происходит. Так как остальные программы используют меньшие объёмы памяти и они попросту "не дотягиваются" до проблемного сегмента. Типа, дёготь в бочке мёду лежит почти на самом дне. И чтобы до дёгтя добраться - надо потребить почти всю бочку. А пока черпаешь мёд с поверхности - никакого дёгтя не попадается. Так и у меня - пока я не пользуюсь программами, требующими много памяти - сбоев не происходит.
Прогоны MemTest не обнаруживают наличие ошибок.
спасибо

Под адекватностью что подразумевается? Соответствуют ли заявленные цифры реальному положению дел? Да, соответствуют.

Да, это один из самых распространенных сценариев. Именно поэтому, собственно, на ПК с глючной памятью может загружаться ОС и она даже будет работать, но возникновение ошибок в ходе длительной эксплуатации неизбежно. Также часто сбойную память выявляют различные приложения (тяжелый софт, современные игры), которые потребляют много RAM и именно они начинают вылетать \ зависать первыми при неисправной RAM.

К сожалению, синтетика не всегда способна на 100% эмулировать нагрузку на железо. Иначе бы, как вы понимаете, в мире в принципе не существовало бракованных комплектующих, которые глючат после покупки прямо "из коробки".

Теоретически MemTest и ему подобные тесты могут выявить сбойные модули памяти, если их оставить крутиться на несколько суток, но смысла в этом мало. Если речь о том, как продемонстрировать дефект памяти в магазине, чтобы сдать ее по гарантии, то можете попробовать упаковать большой объем данных с большим словарем. Скажем, WinRAR при выставлении размера словаря в 512 - 1024Мб легко слопает все ваши 8 гигов оперативки. Можете провести эксперимент. Если упаковка большого объема (20-30Гб) закончится неудачей, то вот вам и способ демонстрации дефекта.

спасибо за развёрнутый ответ. Надеюсь, ситуация именно такова. Вопреки сценарию, когда Диспетчер задач показывает цифры не реального положения дел, например: https://habr.com/ru/post/435678/, еще
Выходит так.. что диспетчер и монитор показывают довольно противоречивые данные..

С точки зрения монитора ресурсов - 3,7 ГБ у меня как бы есть, но как бы нет (не доступны)

значит успешные тесты всё-таки существуют.. просто еще никто не создал качественный софт..

Интересную методику предложили.. правда я решил попробовать 7Zip вместо WinRAR, это же допустимо?
7Zip не давал использовать размер словаря 192 МБ и выше, сообщал о нехватке памяти.
А при использовании размера 128 МБ память удавалось загрузить до 7 гб. Система вела себя стабильно, хотя это был всего один небольшой тест. Жаль что при этом тесте дополнительно и HDD впустую расходуется.

У любого процесса есть Working Set (Рабочий набор). Этот самый Working Set делится на две части: Private и Shared. В чем отличия? Private - это объем памяти, которое приложение юзает единолично и никого туда не пускает. В русский версии Windows этот термин (Private) перевели дословно, в результате получился "частный рабочий набор", что звучит для неподготовленного юзера крайне непонятно, но... Технический английский на русский вообще хреново переводится. Поэтому получилось то, что получилось. Соответственно, Shared - это тот объем памяти, которое формально относится к приложению, но по факту может использоваться другими приложениями. Например, какие-то общие dll'ки и прочая дребедень. В русский версии Shared перевели как "общий".

Есть еще Commit Size. Это изначально запрошенный приложением объем памяти под свои нужды, но с Working Set'ом он обычно не совпадает, причем как в одну, так и в другую сторону, то бишь Working Set может оказаться как больше Commit Size, так и меньше. В русской версии Commit Size перевели как "выделенная память", что тоже мало о чем говорит простым смертным. Ну хотя оно им как бы особо и не надо.

Показывать всё лучше на картинках, поэтому наглядно:


Как видим, Диспетчер задач на первой своей вкладке показывает именно Private Working Set, что (по сути) является наиболее актуальным и правильным индикатором того, сколько памяти приложение юзает для себя единолично и которой ни с кем делиться не желает. Автор той статьи либо сам не понимает что пишет, либо одно из двух. Он нашел тот самый Commit Size, понял что он ни разу не совпадает с Working Set'ом, ужаснулся и побежал разоблачать.

Архиватор при упаковке файлов очень активно гоняет данные по памяти туда-сюда, поэтому при глючной памяти машина может работать достаточно стабильно, но при этом установка программ и игр будет сопровождаться массой глюков, потому как любая установка - это, по сути, распаковка сжатых данных. Тот же MemTest много сценариев последовательно прогоняет в рамках цикла тестирования: последовательное чтение, случайное чтение и т.д. Но это помогает выявить только явно сбойные модули памяти, которые по тем или иным причинам всегда повреждают хранящуюся в них информацию. В случае же реальной работы компьютера (игры, программы, браузер и т.д.) идет поистине непредсказуемое перемещение \ добавление \ удаление данных. Ни один тест все эти комбинации вам не воспроизведет. Точнее, технически это возможно, но тогда каждый прогон занимал бы много-много дней, что при массовом производстве памяти попросту лишено экономической целесообразности. Проще потом отдельным людям глючные планки поменять, чем каждую по месяцу тестировать.

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

Если про физическую, то он показывает, что свободно 100 Mб: из 8-ми Гб используется службами и приложениями - 5,7 Гб и под кэшированные данные - 2,2 Гб (итого 7,9 Гб).
Естественно при такой загрузке ОЗУ будут "опаньки". С файлом подкачки ничего не делалось?

Не-а. То, что в Диспетчере задач называется кэшированием - это использование памяти под различные старые данные, которые (теоретически) могут пригодиться в будущем. Т.е. спустя N часов на любом ПК вся память будет "занята" под кэш. И это логично: нет ни малейшего смысла держать память именно свободной, лучше использовать ее под хранение чего-то полезного, пускай даже вероятность обращения к таким данным не слишком высока. В идеале если, то 100% памяти должно быть занято.

Собственно, Windows в этом плане действительно очень хорошо устроена и кэширование работает просто превосходно. Вот пример с моего домашнего ПК:


Как видим, приложения в общей сумме запросили под свои нужды 5,7Гб RAM (Commit Size), однако по факту им требуется лишь 3,9Гб (Working Set). Оставшиеся 8,1Гб памяти доступны для использования, ну а пока они не нужны, то полностью используются под кэш (всё те же 8,1Гб строкой ниже). При этом, разумеется, ни о каких "опаньки" и прочих неприятностях речи не идёт, всё работает как обычно.

Цифирь 5,7/14,0 относится к виртуальной (страничной) памяти (текущей/максимальной). Обратите внимание на ту же цифирь в на скрине ТС: 7,8/9,0 - количество текущей виртуальной памяти практически равно количеству ОЗУ. Расширение памяти может быть за счет файла подкачки. Но некоторые браузеры на движке хромиум не очень то любят свопить данные.

Следуя этой логике, получается что Google Chrome, Яндекс.Браузер и прочие клоны браузера Chromium должны падать у всех людей по всему миру, когда реальная оперативка заканчивается и система вынуждена более или менее активно юзать файл подкачки. Но очевидно, что это не так. Иначе бы вонь поднялась на весь интернет, что Chrome падает при попытке использования виртуальной памяти.

Собственно, вот очередной скриншот с моей машины:



Специально забил память, включив две виртуальные машины. И стал ждать. Индикатор выделенной памяти болтался на отметке в 13,7Гб, но всё было нормально. По крайне мере, Chrome с открытыми вкладками (всего 8 шт.) падать не желал категорически. В итоге мне надоело ждать, я его свернул и переключился на Firefox. Но на фоне Десятка в одной из виртуальной машин нашла обновления и слопала последние 300 метров Commit Limit'a. После чего рухнула вкладка... в Firefox. :)

Впрочем, как говорится, результат немного предсказуем. ))) Наверное, если подождать и более активно поюзать Chrome при такой жесткой нехватке памяти, то да, он тоже упадет, но это же не по его вине произойдет, а просто потому, что Commit Limit действительно исчерпан.

Но вообще, пожалуй, мысль интересная. Peutrov, попробуйте поднять максимальный размер для виртуальной памяти хотя бы до 2Гб. Ну или на Firefox переходите, он меньше памяти потребляет, как правило.

Это и было в прошлом и сейчас бывает, особенно при просмотре видео. Достаточно забить соответствующие тэги в поисковике: MEMORY_MANAGEMENT синий экран при использовании google chrome. Сейчас падений меньше, по-видимому что-то исправили, но память хромиум продолжает активно кушать (имеется ввиду, что кэшируется много данных).

я добавил пару планок.. (8+2+2 гб), но похоже что система использует только 4 ГБ:

это аппаратная ошибка?
Отчёт cpu id: https://cloud.mail.ru/public/5Ndv/3XD9feWYz

Peutrov, С настройками в msconfig не игрались часом?

нет, не игрался.

Как узнал о существовании утилиты "Autoruns" вообще перестал открывать это окно настроек..

Т.е. включил dual channel mode (двуканальный режим).
Если в одном из каналов только 2 Гб, то такое возможно.
Нет. В идеале надо чтобы в каждом канале был одинаковый объём ОЗУ. Тогда ничего не будет аппаратно резервироваться.

Peutrov, А попробуйте пока посидеть на новых планках памяти. А свою на 8Гб выньте и на полочку положите. Посмотрим как это скажется на работоспособности ПК.