Почему моя таблица страниц занимает так много памяти?

Мой 64-битный ПК с Windows 7 очень вялый. Я заметил в диспетчере задач, что мое использование памяти составляет около 100% - однако использование каждого процесса не соответствует общему объему 6 ГБ (Firefox показывает около 500 МБ, остальные гораздо меньше). Я скачал RAMMap и обнаружил, что таблица страниц занимает значительный объем памяти (2,5 ГБ).

Я гуглил это и ничего не получил - очевидно, таблица страниц может стать фрагментированной. Очевидно, я перезагружу машину и посмотрю, поможет ли это. Но есть ли лучший способ это исправить?

РЕДАКТИРОВАТЬ: перезагрузка, и таблица страниц до 30 МБ.

РЕДАКТИРОВАТЬ 2: После нескольких дней безотказной работы использование таблицы страниц снова растет. В этом ответе я следовал инструкциям @ magicandre1981, чтобы найти источник использования таблицы страниц. К сожалению, я нарисовал пробел - таблица страниц используется "Неизвестно"!

У кого-нибудь есть яркие идеи?

Мне нужно прокомментировать комментарии к вопросу, особенно путаницу между «таблицей страниц» и «файлом страницы». Это не ответ, но он не помещается в пространство, оставленное для комментариев.

«Таблица страниц» действительно очень отличается от файла подкачки. Имея п МБ оперативной памяти , используемой для таблиц страниц не означает , что вы используете п МБ пространства файла подкачки. И хотя некоторые записи таблицы страниц (PTE, из которых состоят таблицы страниц) ссылаются на содержимое файла подкачки, не все.

Таблицы страниц - это структуры в памяти, которые используются MMU ЦП для преобразования адресов с виртуальных адресов (опять же, не файлов страниц) в физические адреса, а ОС - для отслеживания виртуального адресного пространства и помощи в устранении ошибок страниц. Таблицы страниц состоят из записей таблицы страниц (PTE). Каждый PTE занимает 8 байтов и определяет 4K байтов виртуального адресного пространства - то есть одну виртуальную страницу. Примерно один PTE для каждой несвободной страницы виртуального адресного пространства.

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

Каждый PTE имеет «действительный» бит. Для «действительных», то есть «резидентных» страниц, PTE содержит номер физической страницы, который соответствует номеру виртуальной страницы, который связан с PTE; это используется непосредственно MMU.

Для «недействительных» страниц MMU вызывает ошибку страницы, и тогда PTE имеет много возможных форматов и интерпретаций.

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

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

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

Таблицы страниц организованы в древовидную структуру. Существует разное такое дерево или набор таблиц страниц для каждого процесса - это то, что позволяет каждому процессу определять свой собственный экземпляр виртуального адресного пространства. Таблица страниц в корне дерева должна постоянно находиться в оперативной памяти. Другие доступны для просмотра страниц; они даже отсутствуют, если они соответствуют большим (минимум 2 МБ) областям неопределенного или свободного виртуального адресного пространства.

Записи таблицы страниц в таблицах на «листьях» дерева соответствуют страницам виртуального адресного пространства. PTE в таблицах более высокого уровня - те, которые ближе к корню (и сам корень) - сообщают, где находятся следующие таблицы нижнего уровня (если они вообще существуют).

Число, отображаемое RAMmap, представляет собой физическую память (RAM), занятую всеми резидентными (in-RAM) таблицами страниц для всех процессов плюс ОС.

Здесь важно то, что в системе OQ было 2,5 ГБ оперативной памяти, связанной с таблицами страниц. Это означает, что, как минимум, определено 2,5 ГБ таблиц страниц. Так как таблицы страниц сами по себе являются страницами, виртуальный размер может быть намного больше, чем физический размер, и это все, что RAMmap может показать нам. Но предположим, что это «только» 2,5 ГБ. При восьми байтах на PTE это около 320 миллионов PTE. Поскольку каждый PTE определяет одну страницу - 4 Кбайт - виртуального адресного пространства, это означает, что более 1,2 терабайта виртуального адресного пространства определяются таблицами страниц в памяти .

Это не невозможно, но это довольно много.

Для справки, в моей системе atm у меня около 125 МБ ОЗУ в таблицах страниц. Это будет означать только около 65 ГБ виртуального адресного пространства. Мое фактическое виртуальное использование намного выше (125 ТБ только для процессов), но это потому, что большинство таблиц страниц не находятся в оперативной памяти. «Большие страницы», еще одна вещь, о которой я не должен здесь говорить, также может помочь объяснить различные соотношения между размером таблиц страниц и размером используемого виртуального адресного пространства.

Итак, чтобы найти виновника, я бы сначала посмотрел в системном мониторе в категории «Процесс» процессы с высоким значением счетчика «Виртуальные байты».

Lenovo "RapidBoot Shield" был виновником для меня.

После недели без перезагрузки мой «Page Table» использовал 4GB +. Оказалось, что каждый завершенный процесс зависал с использованием 20 КБ ОЗУ (4 КБ, 16 КБ Page Table), как показано на вкладке «Процессы» в RamMap, и их было ~ 200 000!

Перезагрузка сократила список, но он снова начал расти. Его можно было воспроизвести, открыв блокнот, убив его и заметив, что он остается в списке процессов RamMap.

Основываясь на предложениях по этому техническому обсуждению, я удалил «RapidBoot Sheild», перезагрузил машину, и после этого процессы больше не останавливались, когда были убиты. Задача решена!

В моем случае это были драйверы фильтров Aksdf.sys и Hardlock.sys от драйверов Aladdin Knowledge Systems Aladdin . Мне удалось найти этот ответ с помощью RAMMap также. Он отображал память, занятую завершенным процессом. Процессы были удалены из списка процессов Windows, но сохранены в карте памяти. Кажется, что драйверы препятствуют полному завершению процессов.

Я спросил об этом свой отдел ИТ, и они были ошеломлены. В итоге я использовал DriverEasy для обновления драйверов. Те, которые, казалось, имели значение, как ни странно, были драйверами монитора. Раньше у меня были стандартные драйверы Windows "Generic PnP Monitor". Но когда я обновил их до правильной марки и модели моих мониторов, проблема, казалось, ушла.

Откройте вкладку «Процессы» в RamMap и выполните сортировку по имени. Ищите подозрительно большое количество того же процесса. На моей машине виноват "SynTPEnh.exe" (часть драйвера тачпада). После недели безотказной работы он накопил десятки тысяч записей в таблице страниц, каждая размером 32 КБ.

Мой размер таблицы страниц составлял 1 ГБ, после перезагрузки - всего 50 МБ.