Недавно у нас возникла проблема на нашем живом сервере, из-за которой наше веб-приложение перестало отвечать. Все, что мы получали, это 503 ошибки, пока мы не перезагрузили сервер, и все было в порядке. В конце концов я проследил его до httperr.log и обнаружил множество ошибок 1_Connections_Refused.
Дальнейшее расследование показало, что мы достигли предела невыгружаемого пула. С тех пор мы отслеживаем память невыгружаемого пула с помощью Poolmon.exe и считаем, что идентифицировали тег, вызывающий проблему.
Tag Type Allocs Frees Diff Bytes Per Alloc
Even Nonp 51,231,806 50,633,533 684,922 32,878,688 48
Если мы используем poolmon.exe / g, он показывает подключенный драйвер как [<unknown> Event objects].
Это в значительной степени нет помочь вообще. Моя команда потратила много времени на изучение этой проблемы и не смогла найти способ сузить ее до конкретного приложения или услуги. Мне кажется, что большинство людей решают проблему, убивая процессы на машине, пока не увидят сброс невыгружаемой памяти. Это не совсем то, что вы хотите видеть при работе на производственной машине.
Если я открою диспетчер задач и просмотрю список процессов. Я вижу MailService.exe со значением NP Pool 105 КБ, это на 36 КБ выше, чем значение процесса, указанного вторым. Поскольку в прошлом у нас были некоторые проблемы с нашим почтовым сервером (которые могут быть связаны или не связаны с этой проблемой), я чувствую, что это вызывает проблему.
Однако, прежде чем мы перейдем к перезапуску служб, я хотел бы иметь немного больше уверенности, чем просто «внутреннее ощущение».
Я также пробовал использовать poolmon.exe / c, но это всегда возвращает ошибку:
unable to load msvcr70.dll/msvcp70.dll
и он не создает localtag.txt. Моему коллеге пришлось загрузить файл pooltag.txt из Интернета, потому что мы не можем понять, где он находится. У нас не установлен отладчик win или Win DDK (что я вижу). Возможно, указанная выше ошибка возникает из-за того, что ни один из них не установлен, но я не знаю.
Наконец я попробовал:
C:\windows\system32\driver\findstr /m /l Even *.sys
Это вернуло довольно большой список файлов .sys и, опять же, не помогло решить возникшую проблему.
Итак, мой вопрос таков: Есть ли другой способ сузить причину этой утечки памяти?
ОБНОВИТЬ:
Как предлагается ниже, я регистрировал невыгружаемые байты пула в течение последнего дня или около того, чтобы увидеть, идет ли какой-либо процесс вверх. По большей части все процессы кажутся довольно статичными в их использовании. Двое из них, похоже, немного прибавили. Я буду следить за этим в течение следующих нескольких дней.
Я также забыл упомянуть ранее, что ни один из процессов, похоже, также не использует чрезмерное количество дескрипторов.
ОБНОВЛЕНИЕ 2:
Я следил за этим последние пару недель. Как пул невыгружаемых байтов для отдельных процессов, так и общий пул невыгружаемых байтов оставались относительно стабильными в течение этого времени. За это время была обновлена Windows и перезагружен сервер, поэтому мне интересно, решило ли это проблему. Я определенно не вижу последовательного роста пула невыгружаемых байтов сейчас, как это было до этого.
Я наблюдаю за этим около 6-7 недель и наконец могу дать окончательный ответ на проблему.
Во-первых, невыгружаемые байты для отдельных процессов на самом деле не сказали мне ничего полезного, поскольку все они казались довольно статичными в их использовании. Были всплески, но впоследствии использование всегда возвращалось к исходному уровню.
Общий объем невыгружаемой памяти в байтах тоже некоторое время был статическим, но затем начал постепенно увеличиваться, а затем резко увеличиваться. После всплеска примерно половина памяти была освобождена, а затем она снова оставалась статичной (на более высоком уровне) некоторое время, пока образец не повторился. Глядя на график, я заметил, что эти всплески казались довольно равномерными и, как оказалось, происходили с интервалом в 2 недели и всегда в воскресенье.
Итак, следующий вопрос был: что происходит каждые две недели по воскресеньям? Я заглянул в Средство просмотра событий, и каждый раз, когда происходил всплеск McAfee был запущен. Я также думаю, что, часто заходя на сервер для отслеживания проблемы, мы непреднамеренно усугубили проблему, потому что у McAfee есть сканер в реальном времени, и я считаю, что это привело к меньшему увеличению, которое мы наблюдали.
Я думаю, что запланированные задачи сканирования также объясняют, почему мы увидели увеличение памяти NP, прикрепленное к тегу объектов событий в PoolMon, а не к конкретному тегу McAfee. Это было главным, что действительно привело нас по садовой дорожке.
Теперь, когда мы наконец знаем, что вызывает утечку, мы можем что-то с этим сделать. Невероятно, что на это ушло столько времени.
ОБНОВИТЬ: Просто как последнее примечание. McAfee's был обновлен на выходных, и это полностью решило нашу проблему невыгружаемой памяти.
ОБНОВЛЕНИЕ 2: Поскольку я только что проголосовал за это, я добавлю к этому еще одно обновление. Первоначально обновление McAfee, казалось, решило нашу проблему, то есть мы больше не видим массовых скачков в NP-памяти через регулярные промежутки времени. Я также заметил, что после обновления кажется, что McAfee больше не записывает журналы в Средство просмотра событий по умолчанию, которое скрывается при активном сканировании.
Но мы все еще наблюдаем постепенное увеличение использования памяти NP. Дошло до того, что теперь нам нужно перезагружать сервер каждые 2 недели или около того. Это так плохо, что мы недавно приобрели новый сервер в надежде, что обновленное оборудование и программное обеспечение решат эту проблему. НО наш совершенно новый сервер с установленными только Windows Server 2008, SQL Server 2008 R2 и McAfee был ПО-ПРЕЖНЕМУ показывая утечку памяти NP. Только после того, как я полностью удалил McAfee, утечка прекратилась, и она осталась статичной даже после того, как мы настроили сервер со всем нашим программным обеспечением, готовясь к переходу на него.
С тех пор я прочитал и не знаю, правда ли это, что проблема не в McAfee, а в некоторой подпрограмме Windows, которую использует McAfee, которая вызывает утечку памяти NP. По всей видимости, сетевая активность является причиной утечки, т.е. большая сетевая активность => более крупные утечки. Это, похоже, согласуется с нашим опытом, поскольку утечка усугубляется по мере того, как наш сервер становится более загруженным.