[Avatar-Lion]

Диспетчер задач показывает цифры не реального положения дел »

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

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

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

Скрытый текст

1) AIMP запускается и запрашивает для себя порядка 53Мбайт RAM (Commit Size, он же Выделенная память)
2) AIMP запустился и освоился, но реально использует только около 14Мбайт RAM (Working Set, он же Рабочий набор)
3) AIMP для себя любимого занял лишь 3Мбайта RAM (Private Working Set, он же Частный рабочий набор), оставив 11 метров оперативки доступной другим приложениям (Shared Working Set, он же Общий рабочий набор)

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

значит успешные тесты всё-таки существуют »

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

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