Взглянув на различный фрагмент кода, который просматривает таблицу UID размером около 10 МБ и подставляет вторую таблицу, а также на результаты мониторинга производительности, я заметил, что как только я нажимаю «Выполнить», наблюдается постоянный рост количества сбоев страниц; это будет около 5000 / с минуту или около того, системный кэш постоянно падает. Интересно, что это также похоже на то, что цикл постепенно замедляется.
Я не разработчик, поэтому не могу помочь вам с первой частью вашего вопроса, извините, но как инженер я могу пролить свет на отношения между аппаратным и ОС.
Пожалуйста, поймите, что нет простого способа объяснить это без первого глубокого погружения в фундаментальные различия (и сходства) операционной системы и аппаратного обеспечения платформы. Но здесь идет:
Кроме того, это поможет вам узнать, что на самом базовом уровне вся Платформа представляет собой одну длинную лестницу уровней кеша, либо физический кеш для ЦП (L1, L2, L3, L4, RAM, HDD и т. Д.), Либо Виртуальный кеш уровни для процессов и памяти менеджера памяти. (Обработка частного рабочего набора, рабочего набора, режима ожидания и т. Д.).
Недостатки страницы бывают двух видов: мягкий и жесткий. Soft Page Fault происходит, когда процесс запрашивает страницу, которая не находится в это рабочий набор, AKA диапазон адресов, доступных для процесса . Страница обычно находится в оперативной памяти как часть «резервного» списка в диспетчере задач (кэшированные файлы).
Описание Standby вводит в заблуждение, потому что на самом деле все страницы, отображаемые ЦП, являются частью рабочего набора системы. Даже кешированные файлы.
Процессор знает местоположение запрашиваемой страницы в основном (RAM) или дополнительном (HDD) хранилище - RAM или HDD (уровни кэширования AKA - вы видите?). Это не заботится ни о чем другом.
Процессор не перемещает страницу, он перемещает указатель.
Итак, подведем итоги: мягкая неисправность разбивается на страницы в адресном пространстве процесса и выходит из него - например, рабочий режим установлен в режим ожидания и обратно. Это не очень большая проблема, хотя.
Hard Page Fault происходит, когда запрашиваемая страница не в оперативной памяти, но на странице файл с жесткого диска. Жесткие сбои страницы не возникают при выключении файла подкачки (очевидно).
Если Soft Faults при наличии свободной памяти можно уменьшить, увеличив размер рабочего набора (реестр и редактор объектов групповой политики), добавив ОЗУ или и то, и другое.
Я прочитал интересный пост с большим количеством голосов, который я сейчас не могу найти (но думаю, что он был размещен здесь) относительно файла подкачки, в котором пользователь указал, что на самом деле в Windows никогда не бывает «свободной» ОЗУ; он постоянно заполняется, все разбивается на страницы, а затем выгружается, если кому-то еще нужно место.
Не правда.
Всегда должна быть хотя бы некоторая свободная оперативная память для лучшей производительности, чтобы страницы можно было читать прямо с диска. В противном случае резервные страницы сначала должны быть удалены, а таблицы страниц обновлены. Это требует времени.
Если нет свободного, то машине требуется больше оперативной памяти.
Похоже, что существуют некоторые крайне неоднозначные мнения о том, следует ли включать файл подкачки.
Я пробовал как включить, так и отключить его, и вижу один и тот же шаблон при возникновении ошибок на странице.
Страница файл был требованием для Intel IA-32й / Intel-64 процессоров с 32 - битной адресными штырями в ОЗУ под управлением Windows x86 с PAE или Windows 64.
Файл подкачки был единственным способом, которым эти процессоры могли достигать адресов более 4 ГБ, на которые ОС была способна полностью.
Вопреки распространенному мифу, PAE в ОС означает расширение адреса страницы, а не расширение физического адреса. Расширение адреса страницы позволяет адресам, превышающим 4 ГБ, быть доступными для ОС, при условии, что ЦП имеет 36-битные внутренние регистры.
Если расширение адресов страниц включено на процессорах с 32-битными регистрами, все чертовски разрушается. 32/32 ЦП (32 внешних контакта / 32 внутренних регистра) могут достигать адресов до 4 ГБ.
Изменить: я добавил еще несколько случайных, но важных моментов, чтобы помочь прояснить общую картину ... надеюсь, я не переусердствовал.
E ** Примечание: ранее я неправильно назвал IA-64 x86-64, он должен был прочитать Intel-64 .
IA-64 - это х64.
** 32/36 (IA32e / Intel 64) AKA x86-64 может работать с сегментами размером более 4 ГБ, 2 × 4 ГБ. Один сегмент объемом 4 ГБ - это ОЗУ, а другой - файл подкачки. Первичное и вторичное хранилище. RAM ---> CPU: внешние адресные контакты, CPU ------> HDD: внутренние регистры данных.
36-разрядное расширение адреса страницы сокращает адресное пространство на процесс на IA32e / Intel64 до 3,5 ГБ, 512 МБ зарезервировано для каталога таблицы страниц ЦП, а дополнительные 4 бита используются для указателя каталога сегмента
Вы когда-нибудь задумывались, почему скомпилированные игры x87 никогда не используют более 3,6 ГБ? Это потому, что высокие указатели усекаются компилятором Intel. Остальные ~ 512 МБ отмечены как зарезервированные. На 64-битном оборудовании процесс около 500 МБ VAD постоянно помечается как свободное место.
Intel IA-32e / Intel-64 иначе известен как x86-64. x86-64: ЦП с 32 контактами в ОЗУ, поддерживающий страницы 4 ГБ с помощью внутренних регистров и файла подкачки на жестком диске.
Ничто из вышеперечисленного не влияет на оперативную память, между прочим, ЦП с 32 контактами не может обмениваться данными с модулями памяти с плотностью более 4 ГБ. Это аппаратное ограничение.
Это все равно что пытаться позвонить своему другу со стационарного телефона без телефонной линии - просто по телефону. :П
Расширение физического адреса - это номенклатура архитектуры ЦП Intel, относящаяся к контактам адреса ЦП в ОЗУ. Выше четко указано в документации Intel.
Файл подкачки никогда не требовался на процессорах с 36-битными адресными штырьками. (AMD64 / IA64)
Кстати, связанные статьи, такие как найденные в Википедии, Technet, MSDN и т. Д., Относящиеся к ограничениям памяти Windows и PAE, по большей части полностью ошибочны или вводят в заблуждение.
Microsoft являются худшими преступниками в этом отношении.
Мне любопытно, может ли это быть связано с установлением приоритетов памяти в более поздних версиях Windows. Я знаю, что могу повысить приоритет процесса в диспетчере задач, однако действительно ли это увеличивает приоритет выделения памяти, а не только приоритет потока процессора? Есть ли возможность постоянно устанавливать такие приоритеты без использования проприетарного программного обеспечения? Я понимаю, что Windows пытается помочь путем упреждающего кеширования данных в ОЗУ, однако, на самом деле, похоже, что это совсем не помогает с R. Есть ли способ выборочно форсировать или изменять профиль кеширования? Для более интенсивной работы с памятью я бы предпочел, чтобы не было кешированных файлов, которые я на самом деле не использую.
Надо кешировать как можно больше
Отличная статья, которая разоблачает много дезинформации: производительность кэша файлов и настройка .