none
Увеличение размера файла pagefile.sys RRS feed

  • Вопрос

  • Похожая ситуация описана в http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/8129f5dc-9af0-4764-9666-d81d651961bb.

    Периодически сервер Windows server 2003 64 Standard останавливается по причине нехватки памяти.

    Первоначально, pagefile был на системном разделе и там действительно могло не хватать дискового пространства. Я перенёс pagefile на другой раздел и на другой физический диск. На некоторое время работа системы стабилизировалась. На сервере 4 Гб RAM, управление pagefile было "Размер по выбору системы". После перезагрузки pagefile стартовал с размера 4 Гб. Когда размер файла достигал 6 Гб (всего 10 Гб виртуальной памяти) - система зависала. Я увеличил стартовый размер до 6 Гб и вручную установил предельный размер файла в 24 Гб. Результат остался прежний. Когда размер виртуальной памяти достигает 10 Гб, система выбрасывает на консоль стандартное сообщение о том, что закончилась виртуальная память и будет увеличен размер pagefile, после чего виснет. В системных журналах нет сообщений об ошибках, кроме того они перестают заполняться в момент зависания. Максимум, что из них можно получить - это когда система зависла, с точностью примерно 5-10 минут.

    Всвязи с этим несколько вопросов:

    1. Нет ли известных ошибок, которые препятствуют автоматическому увеличению pagefile свыше 6 Гб?

    2. Не обращается ли сервер к контроллеру домена в момент увеличения размера pagefile?

    3. С помощью каких средств можно дополнительно проанализировать эту неисправность?

     

     

    23 сентября 2010 г. 5:55

Ответы

  • После исследования ОС и её работы были выявлены 2 причины, которые приводили её к столь странному поведению. Оба случая связаны с некорректной работой дешёвых принтеров в терминальной сессии сервера.

    Первым был обнаружен принтер HP M1319f MFP. Это МФУ подключено к компьютеру с 32-х разрядной Windows XP, к нему открыт общий доступ через сеть. Пользователи, подключенные к этому принтеру, работают в терминальных сессиях нескольких серверов. Соответственно переадресовывается и принтер. Если команда на печать подаётся из терминальной сессии 32-х разрядного сервера, то всё нормально. Если команда на печать подаётся из терминальной сессии 64-х разрядного сервера, то происходит следующее. Обработчик печати запускается, печать корректно выполняется, но обработчик не завершает свою работу и остаётся в памяти терминальной сессии. Затем, каждые 10 секунд он "хапает" себе 4К памяти RAM и 4К в pagefile. Это примерно 1 МБ в час. Если пользователи отпечатали за день 100 страниц, то нерациональный расход памяти составляет более 2 ГБ в сутки. Это была основная причина, по которой ОС была вынуждена увеличивать размер pagefile. Скорее всего ОС корректно проводила эту процедуру. Но очень часто она сочеталась со второй причиной, из-за которой создавалась ситуация, когда ОС "не отвечала на внешние воздействия", иногда по несколько часов, а иногда зависала полностью.

    Вторая причина тоже связана с драйвером принтера. Принтер Xerox 3140 был подключен к серверу. Затем его физически отключили от сервера, но значок принтера и драйвер на сервере остались. В сети предприятия ещё несколько таких принтеров. Иногда пользователи ошибались и отправляли своё задание на печать на принтер, который настроен на сервере, но физически отсутствует. Задание попадало в очередь печати принтера, а панель управления принтером докладывала пользователю о невозможности выполнить печать, но не закрывала свой процесс. Затем этот процесс 20 раз в секунду открывал новые дескрипторы, но не закрывал их. В результате одно ошибочно отправленное на печать задание открывало примерно 70 000 новых дескрипторов в час. Около 1 500 000 в сутки. Сервер начинал заметно терять производительность когда количество открытых дескрипторов приближалось к 1 000 000. Пользователи жаловались на медленную работу программ, хотя процессоры при этом были нагружены всего на несколько процентов, а свободной памяти было 200-400 МБ. Сбойный процесс при этом, практически, не нагружал процессоры сервера и расходовал суммарно менее 10 МБ памяти. Завершение такого сеанса по команде пользователя или сброс администратором приводили к длительным периодам, когда ОС "не отвечала на внешние воздействия". Если в терминальном сеансе пользователя успело открыться 100 000 дескрипторов, то завершение такого сеанса не вызывало заметного зависания ОС в любом случае. Если завершался сеанс с 400 000 дескрипторов, то возникали 2 варианта. Если к моменту закрытия такого сеанса он был единственным активным в системе, то сервер зависал примерно на 2-3 минуты, если кроме этого сеанса, в системе были активны 8-10 других сеансов, то зависание длилось 10-15 минут. При этом сервер не отвечал никому. Один раз сервер находился в таком состоянии около 10 часов. При этом в журналах системы нет никаких сообщений. Просто перерыв в записях на несколько минут или часов, в зависимости от количества дескрипторов, открытых к моменту завершения сеанса пользователя. Если сбойный сеанс пользователя не закрывался 10-12 суток, то ОС останавливалась из-за ограничения дескрипторов, открытых одним процессом.

    Надеюсь это будет кому-то полезно.

    • Помечено в качестве ответа Serega I 9 октября 2010 г. 10:41
    9 октября 2010 г. 10:41

Все ответы

  • Какой из процессов больше всего использует файл подкачки?

    Можно посмотреть счетчик process\pagefile bytes  - all instances

    23 сентября 2010 г. 6:02
    Отвечающий
  • Возможно, заканчивется память из невыгружаемого пула, т.е. это не связано с файлом подкачки...

    Из средств: processexplorer, poolmon.

    И немного теории-практики:

    http://blogs.technet.com/b/mark_russinovich/archive/2009/05/06/3236407.aspx

    http://blogs.technet.com/b/mark_russinovich/archive/2008/11/17/3182311.aspx

    23 сентября 2010 г. 9:27
  • Какой из процессов больше всего использует файл подкачки?

    Можно посмотреть счетчик process\pagefile bytes  - all instances


    Мне привычнее смотреть в ProcessExplorer. Он одновременно показывает сколько процесс занимает в памяти и в Pagefile.

    Все процессы занимают разумное количество виртуальной памяти, но когда процессов становится много, память рано или поздно заканчивается.

    Сервер используется, как сервер терминалов. Он входит в домен, но как рядовой сервер. Все доменные службы на других серверах. Основную нагрузку на сервер дают программы 1С 7 и 8 версии. 7 версия 1С ведёт себя "культурно". 25-30 Мб RAM и 30-40 Мб в Pagefile. Она всегда себя так вела. 8 версия 1С (точнее 8.1) "жрёт" память бессовестно. Сразу после запуска процесса 110-120 Мб RAM и 130-150 в Pagefile и, обычно, потихоньку растёт. К сожалению, это штатная работа 8 версии 1С в файловом режиме.

    Проблема не в том, что какое-то приложение или процесс расходуют виртуальную память, а в том, что система определяет, что памяти не хватает, сообщает что добавит размер Pagefile и виснет. Система добавляла размер Pagefile с 4 до 6 Гб. Я видел Pagefile (при стартовом размере 4 Гб) 4.6 Гб, 5,2 Гб, 5.8 Гб. Но ни разу не видел его больше 6 Гб. Наверное можно сделать стартовый размер Pagefile заметно больше 6 Гб. Но это уже уход от проблемы, а не её решение.

     

    23 сентября 2010 г. 13:53
  • Возможно, заканчивется память из невыгружаемого пула, т.е. это не связано с файлом подкачки...

    Из средств: processexplorer, poolmon.

    И немного теории-практики:

    http://blogs.technet.com/b/mark_russinovich/archive/2009/05/06/3236407.aspx

    http://blogs.technet.com/b/mark_russinovich/archive/2008/11/17/3182311.aspx


    Вторая ссылка более-менее знакома. А вот первая ссылка, где описаны ограничения на выгружаемую-невыгружаемую память, в IE 8 выглядит отвратительно.

    Таблицы существенно "подрезаны" с правого края. Я вижу ограничения для 32-х битных систем, но для 64-х битных вижу только "минимум (4* невыг", а дальше сплошная загадка. В каком браузере лучше просмотреть эти ссылки?

     

    23 сентября 2010 г. 14:02
  •  

    Вторая ссылка более-менее знакома. А вот первая ссылка, где описаны ограничения на выгружаемую-невыгружаемую память, в IE 8 выглядит отвратительно.

    Таблицы существенно "подрезаны" с правого края. Я вижу ограничения для 32-х битных систем, но для 64-х битных вижу только "минимум (4* невыг", а дальше сплошная загадка. В каком браузере лучше просмотреть эти ссылки?

     

    минимум ( 4 * невыгружаемого пула, 128ГБ) Двумя абзацами выше написано.

     

    23 сентября 2010 г. 14:59
  • После исследования ОС и её работы были выявлены 2 причины, которые приводили её к столь странному поведению. Оба случая связаны с некорректной работой дешёвых принтеров в терминальной сессии сервера.

    Первым был обнаружен принтер HP M1319f MFP. Это МФУ подключено к компьютеру с 32-х разрядной Windows XP, к нему открыт общий доступ через сеть. Пользователи, подключенные к этому принтеру, работают в терминальных сессиях нескольких серверов. Соответственно переадресовывается и принтер. Если команда на печать подаётся из терминальной сессии 32-х разрядного сервера, то всё нормально. Если команда на печать подаётся из терминальной сессии 64-х разрядного сервера, то происходит следующее. Обработчик печати запускается, печать корректно выполняется, но обработчик не завершает свою работу и остаётся в памяти терминальной сессии. Затем, каждые 10 секунд он "хапает" себе 4К памяти RAM и 4К в pagefile. Это примерно 1 МБ в час. Если пользователи отпечатали за день 100 страниц, то нерациональный расход памяти составляет более 2 ГБ в сутки. Это была основная причина, по которой ОС была вынуждена увеличивать размер pagefile. Скорее всего ОС корректно проводила эту процедуру. Но очень часто она сочеталась со второй причиной, из-за которой создавалась ситуация, когда ОС "не отвечала на внешние воздействия", иногда по несколько часов, а иногда зависала полностью.

    Вторая причина тоже связана с драйвером принтера. Принтер Xerox 3140 был подключен к серверу. Затем его физически отключили от сервера, но значок принтера и драйвер на сервере остались. В сети предприятия ещё несколько таких принтеров. Иногда пользователи ошибались и отправляли своё задание на печать на принтер, который настроен на сервере, но физически отсутствует. Задание попадало в очередь печати принтера, а панель управления принтером докладывала пользователю о невозможности выполнить печать, но не закрывала свой процесс. Затем этот процесс 20 раз в секунду открывал новые дескрипторы, но не закрывал их. В результате одно ошибочно отправленное на печать задание открывало примерно 70 000 новых дескрипторов в час. Около 1 500 000 в сутки. Сервер начинал заметно терять производительность когда количество открытых дескрипторов приближалось к 1 000 000. Пользователи жаловались на медленную работу программ, хотя процессоры при этом были нагружены всего на несколько процентов, а свободной памяти было 200-400 МБ. Сбойный процесс при этом, практически, не нагружал процессоры сервера и расходовал суммарно менее 10 МБ памяти. Завершение такого сеанса по команде пользователя или сброс администратором приводили к длительным периодам, когда ОС "не отвечала на внешние воздействия". Если в терминальном сеансе пользователя успело открыться 100 000 дескрипторов, то завершение такого сеанса не вызывало заметного зависания ОС в любом случае. Если завершался сеанс с 400 000 дескрипторов, то возникали 2 варианта. Если к моменту закрытия такого сеанса он был единственным активным в системе, то сервер зависал примерно на 2-3 минуты, если кроме этого сеанса, в системе были активны 8-10 других сеансов, то зависание длилось 10-15 минут. При этом сервер не отвечал никому. Один раз сервер находился в таком состоянии около 10 часов. При этом в журналах системы нет никаких сообщений. Просто перерыв в записях на несколько минут или часов, в зависимости от количества дескрипторов, открытых к моменту завершения сеанса пользователя. Если сбойный сеанс пользователя не закрывался 10-12 суток, то ОС останавливалась из-за ограничения дескрипторов, открытых одним процессом.

    Надеюсь это будет кому-то полезно.

    • Помечено в качестве ответа Serega I 9 октября 2010 г. 10:41
    9 октября 2010 г. 10:41
  • Надеюсь это будет кому-то полезно.
    конечно будет, Сергей - отличный и правильный пример исследования проблемы: от себя дополню, что очень часто даже простое сосуществование драйверов HP и Xerox на одном принтсервере очень часто вызывает массу проблем
    10 октября 2010 г. 6:18
    Отвечающий