Windows Server 2003 SP2 говорит правду о свободных записях таблицы системных страниц?

Question

У нас есть некоторые консольные приложения Win32, работающие на Windows Server 2003 с пакетом обновления 2, которые регулярно терпят неудачу с этим:

Ошибка 1450 (ERROR_NO_SYSTEM_RESOURCES): «Недостаточно системных ресурсов для завершения запрошенной службы.»

Вся найденная нами документация предполагает, что она связана с количеством бесплатных записей в таблице системных страниц заканчивается. У нас 16 ГБ ОЗУ на этих машинах и мы используем переключатель /3GB Operating System, чтобы сжать ядро ​​Windows до 1 ГБ и предоставить нашим процессам доступ к 3 ГБ адресного пространства. Это резко сокращает общее количество свободных записей таблицы страниц системы, поэтому в сочетании с интенсивным использованием MapViewOfFile (), возможно, неудивительно, что записи таблицы страниц ядра заканчиваются.

Тем не менее, при использовании системного монитора для просмотра счетчика записей таблицы системных страниц, значение при загрузке составляет около 36 000, а не выключается при запуске нашего приложения . Мне трудно поверить, что наше приложение, открывающее много больших отображенных в память файлов, никак не влияет на таблицу страниц ядра. Если мы не можем поверить счетчику, гораздо труднее проверить влияние любых изменений системы, которые мы делаем.

Существует многообещающая статья в Базе знаний, Средство Performance не точно отображает доступные записи в таблице свободных страниц системы в Windows Server 2003 , но в нем говорится, что проблема была исправлена ​​в пакете обновления 1, и мы уже находимся на Service Pack 2.

Кто-нибудь еще боролся или решил эту проблему?

Обновление: Я проверил! Sysptes в windbg (отладка ядра), и значение соответствует счетчику производительности, около 36 000. Я предполагаю, что это, скорее всего, означает, что на самом деле существует так много бесплатных записей в таблице страниц, и Windows говорит правду. Однако остается вопрос, почему мы получаем 1450 ошибок, если PTE не заканчиваются.

Дальнейшее обновление: Мы так и не поняли, почему произошли 1450 ошибок. Однако , вместо этого мы обновили ОС на этих серверах до 64-битной Windows. Это позволяет существующим 32-разрядным приложениям (без перекомпиляции) получать доступ к полному 4 ГБ виртуального адресного пространства и позволяет области памяти ядра с этими надоедливыми записями таблицы страниц быть настолько большой, насколько ей нравится. Я не думаю, что с тех пор у нас была ошибка 1450.

Answer 1

Можете ли вы попробовать команду windbg "! Sysptes", чтобы получить Системную информацию PTE? Я не уверен, что если вы сможете сделать это с помощью живой отладки ядра, возможно, вам придется получить дамп памяти.

Answer 2

MS имеет 2 способа , чтобы позволить 32-битной ОС «справляться» с оборудованием, имеющим 4 ГБ или более оперативной памяти.

Вариант 1: это то, что вы сделали с переключателем / 3GB в Boot.ini.

Вариант 1 Плюсы и минусы:

(CONS) Эта опция высасывает 1 ГБ из обычной 2 ГБ области ядра, что заставляет ОС бороться за выполнение требований как распределенного пула, так и выделения стека ядра. Таким образом, кто-то может подумать, что использование параметра / 3GB поможет им, но на самом деле этот вариант приводит к медленной смерти 32-битной ОС Windows.

(CONS) Но, это дает моему приложению 3 ГБ .... НЕПРАВИЛЬНО (следовательно, это CON) Подвох в том, что ТОЛЬКО приложение, которое было перекомпилировано от поставщика, должно быть "/ 3GB Switch в курсе "действительно можно использовать лишние 1 ГБ. Следовательно, использование ключа / 3GB в целом является ПЛОХОЙ J.O.K.E для всех.

Прочитайте эту ссылку, чтобы лучше написать:

http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

Вариант 2: Используйте переключатель / PAE в Boot.ini.

Вариант 2 Плюсы и минусы:

(PROS) Это действительно единственный вариант, если у вас более 4 ГБ ОЗУ. Он обманывает приложение, помещая полный объем памяти приложения в оперативную память. Обычно в оперативной памяти находится только память «Рабочий набор» приложения, а оставшиеся требования к памяти приложения попадают в файл подкачки Windows. Каковы требования к общей памяти приложения? - это называется «Виртуальный размер».

В моем мире у меня есть большой толстый продукт IBM на основе Java, с которым я имею дело. Сервер, на котором запущено «приложение», имеет 16 ГБ ОЗУ. Я просто добавляю ключ / PAE и наблюдаю (благодаря sysinternals Processes Explorer), запросы на подкачку приложений идут от 200 КБ / с до 4 МБ / с.

Вопрос: «Почему»?

Ответ: Все приложение находится в оперативной памяти.

Вопрос:"Знает ли приложение, что оно полностью работает в ОЗУ?

Ответ: Нет - он работает по тому же старому способу, которым он всегда выполнялся, «ДУМАЯ», что он имеет часть себя как память «Рабочего набора», живущая в ОЗУ и оставшаяся память приложения. требования идут в Windows Pagefile.

Да, это то, что щелкает ХОРОШО.

Обратите внимание: Microsoft сделала плохую работу, рассказывая кому-либо о великолепном варианте ОС Windows. Duh

Попробуйте и отправьте отчет в stackoverflow ....

Answer 3

Я не уверен, почему вы предполагаете, что ERROR_NO_SYSTEM_RESOURCES вызвано только из-за отсутствия свободных записей в таблице системных страниц? Насколько я знаю, такие общие коды ошибок используются для более чем одного типа ресурса. И на самом деле, первое попадание в Google предполагает, что нехватка файловой кеш-памяти также может быть причиной этого. (KB на ошибке XP, которая отключила этот режим ошибки).

В вашем случае я бы проверил "Счетчик ручек". Другая возможная проблема - фрагментация адресного пространства. Если вы хотите создать представление отображения файлов размером 1 ГБ, вам нужно 1 ГБ свободного адресного пространства, и оно должно быть смежным. Если вы сопоставите файл объемом 1 ГБ, файл объемом 800 МБ и файл объемом 1 ГБ, закройте файл объемом 800 МБ и откройте файл размером 900 МБ, файл объемом 900 МБ может не поместиться в оставленное отверстие.