none
Windows Server 2003 R2 SP2 x64 RU - возможно, утечка памяти memory leak RRS feed

  • Вопрос

  • День добрый.
    Конфиг сервера:
    2xE5420, 8 ГБ ОЗУ.
    Все жесткие диски SAS, два раздела - C (RAID1) и D (RAID10). На C разрешен файл подкачки размером от 2046 до 2046 МБ. На D файла подкачки нет.
    Сервер не в домене. Установлено:
    MS SQL Server 2005
    Axapta Object Server
    WSUS
    VMWare Server


    Наблюдается следующее явление:
    1. Явное торможение сервера.
    2. В диспетчере задач (вкладка Быстродействие) наблюдается (узкий график слева) размер файла подкачки 5-6 ГБ, а pagefile.sys на диске С занимает 2 145 386 496 байт. При этом, справа (Физическая память, КБ)указано:
    Всего 8382080
    Доступно - это значение колеблется от 30 МБ до 400 МБ
    При этом, в процессах сумма по всем строкам в столбце Память не достигает даже 4 ГБ, в столбце Вирт п. аналогичная ситуация.

    Попытки анализа:
    1. Останавливаем запущенные движки Аксапты (Axapta Object Server). Ситуация почти не меняется.
    2. Останавливаем SQL-сервер. Резко падает использование файла подкачки и освобождается много (около 4 ГБ) физической памяти.
    3. Запускаем SQL-сервер. Количество доступной физической памяти резко уменьшается на 1-2 ГБ, но в процессах в столбце Память у SQL-сервера занято 350 МБ.

    Попытки решения проблем:
    1. Poolmon.exe. Слабо понятно что искать...ну а даже если нашли, то как потом искать в драйверах??? А что делать если не нашли? В общем - темный лес.
    2. Установили Антивирус Касперского для серверов...запустили полную проверку - не помогло

    Вопросы:
    1. Почему такой каламбур с файлом подкачки? А именно - почему его объем больше заданного?
    2. Куда девается физическая память? Методы поиска?

    Спасибо.
    28 января 2010 г. 19:50

Ответы

  • Думаю, что озвучу очевидное:
    1. Проблем с физической памятью у вас сейчас никаких нет - её достаточно в любое время на данном отрезке.
    2. Диск D: действительно не всегда справляется с нагрузкой, есть пики, но я не могу назвать их критичными - рекомендую поиграть с кэшем контроллера, оптимизировать на запись (возможно доставить батарейку для writeback)
    3. Я не увидел интенсивного обмена страницами - лишь ближе к концу лога IO порядка 8,5Мб, это не должно сильно затормаживать вам систему с учётом неповторяемости (в данном отрезке). Причём попадает этот пик на активность "Проводника" и RAR - подозреваю, что делали что-то с файлами сами.
    4. с диском C:, на который, как вы указали, настроен файл подкачки - нет проблем вообще... не то, чтобы нет - я бы сказал, на него вообще нагрузка минимальна
    Всё-таки я вам настоятельно рекомендую отпустить PageFile - хотя бы гигов до 8-12: у вас достаточно тяжёлые приложения, чтобы так зажимать. В остальном - я объективно не вижу проблем с данным сервером.
    • Предложено в качестве ответа AndricoRusEditor 2 февраля 2010 г. 10:06
    • Помечено в качестве ответа AndricoRusEditor 9 декабря 2010 г. 13:58
    1 февраля 2010 г. 16:09
    Отвечающий
  • Видимо, ситуация стала лучше (мы не замечаем тормозов в работе приложений) в связи с тем, что объем используемой памяти, примерно, 8 ГБ...то есть ровно столько, сколько у нас ее было до апгрейда...теперь есть запас и, я думаю, поэтому нет проблем.
    • Помечено в качестве ответа AndricoRusEditor 9 декабря 2010 г. 13:58
    22 февраля 2010 г. 8:44

Все ответы

  • Попробуйте ограничить объем потребляемой памяти SQL сервером.
    29 января 2010 г. 6:38
    Отвечающий
  • Григорий, если у вас наряду с SQL установлено ещё что-либо - режьте использование памяти для него (в свойствах SQL-сервера). SQL возьмёт всю доступную память под себя - такова его схема работы, закэширует всё что можно. В случае если стоит только SQL - это не приносит проблем, если ещё и сторонние бизнес-приложения есть - ограничьте 5-6 гигами и всё будет хорошо. Никаких поисков тут не нужно - обычное поведение SQL Server.

    • Предложено в качестве ответа Hroft 2 февраля 2010 г. 7:20
    29 января 2010 г. 7:32
    Отвечающий
  • Григорий, если у вас наряду с SQL установлено ещё что-либо - режьте использование памяти для него (в свойствах SQL-сервера). SQL возьмёт всю доступную память под себя - такова его схема работы, закэширует всё что можно. В случае если стоит только SQL - это не приносит проблем, если ещё и сторонние бизнес-приложения есть - ограничьте 5-6 гигами и всё будет хорошо. Никаких поисков тут не нужно - обычное поведение SQL Server.


    тогда возникают вопросы: как мониторить, сколько отъедает скуль реально? Ведь в процессах он показывает до гигабайта памяти. Как узнать, хватает ли ему этого объема? И, наконец, почему происходит такое гонево с файлом подкачки? На винте он весит 2 ГБ, а в диспетчере задач показывает 4.5 ГБ.

    upd:
    После зажимания MSSQL в рамки 3 ГБ всё проработало нормально в течении 3х часов. Сейчас доступно физической памяти 800 МБ, Аксапта тормозит так же, как до зажимания. Файл подкачки в диспетчере задач показывает 5.6 ГБ. То есть, насколько я понял, не помогло
    29 января 2010 г. 8:55
  • счётчик Process\Virtual Bytes, Instance - sqlservr
    вот вам вся выделенная процессу память, Process\Working Set - реально занимаемый объём физической памяти (без pagefile)
    29 января 2010 г. 10:57
    Отвечающий
  • счётчик Process\Virtual Bytes, Instance - sqlservr
    вот вам вся выделенная процессу память, Process\Working Set - реально занимаемый объём физической памяти (без pagefile)

    Я правильно понял, что на русском это звучит так:
    Process\Virtual Bytes = Процесс\Байт виртуальной памяти
    Process\Working Set = Процесс\Рабочее множество
    ?

    Если да, то Рабочее множество держится около 280 МБ, так же как и отображается в процессах у sqlservr.exe
    А Байт виртуальной памяти около 9 ГБ. Что довольно неожиданно, учитывая что размер файла подкачки ограничен 2я ГБ
    29 января 2010 г. 11:48
  • Тогда смотрите Working Set - общий и каждого процесса в отдельности... хотя мне ситуация кажется абсурдной - какой-то из процессов держит себя в памяти, при этом засвопив сиквел...?

    п.с. в остальном, подумав... а зачем вы при такой массе "тяжёлых" приложений зарезали PF на 2 гига? оставьте автомат - тут только сиквела для такого решения достаточно, не считая остальных... IMHO!

    29 января 2010 г. 13:15
    Отвечающий
  • Посмотрите на счетчик sqlserver:memory manager\Total server memory (SQL server использует память для индексов, сортировки, и прочей sql лабуды, а не только для исполняемых файлов)
    Регулируется это, например в sql server management studio в свойствах сервера на вкладке memory - параметр "maximum server memory"
    29 января 2010 г. 13:52
    Отвечающий
  • Я прошу прощения за то, что ухожу с уже начатой дистанции. Этому есть объяснимая причина. Как мне кажется, я задал не правильное начало. Я все беды свалил на SQL-Server, а это, как мне кажется, не совсем корректно.
    Я предлагаю перейти к методу исключения.
    Я начинаю с того, что отключил запуск виртуальных машин в VMWare и перезагрузил сервер. Посмотрю что это даст и сообщу.

    Счетчики производительности смотрел...жутко неудобная штуковина - значения (числа) даже не разбиты на разряды...но могу сказать одно - я не увидел явного виновника всех бед - именно поэтому я начал с того приложения, которое, как мне кажется, может быть виновником.

    Спасибо.

    29 января 2010 г. 17:50
  • ну с разрядами как раз решить - проще простого:
    HKEY_CURRENT_USER\Software\Microsoft\SystemMonitor\
    новый параметр DWORD с именем "DisplayThousandsSeparator" и значение в 1
    штуковина может и не совсем удобная, но невероятно функциональная для отлова проблем на windows-системах...

    29 января 2010 г. 18:25
    Отвечающий
  • Итак, на сервере остались работать только Axapta Object Server и MS SQL Server 2005.
    1. Размер файла подкачки ограничен настройками от 2046 МБ до 2046 МБ. На диске файл занимает именно столько, а в диспетчере задач размер файла подкачки: 4,62 ГБ. Странно - как так получается?
    2. График использовние файла подкачки в диспетчере задач, примерно, на 50 %.
    3. Объем доступной физической памяти в данный момент 3 ГБ, но постепенно уменьшается.
    4. Симптом: жуткие торможения клиентов аксапты...можно 5 минут ждать того, что, обычно, происходило за 1 секунду.
    Какие счетчики смотреть?
    Можно как-то записать показания счетчиков чтоб выложить сюда?
    Спасибо.
    1 февраля 2010 г. 9:39
  • Среднее значение счетчика pages/sec и avg.disk queue leght у вас какие?

    1 февраля 2010 г. 9:54
    Отвечающий
  • Можно, вам нужен Counter Logs в той же консоли... соберите счётчики по объектам:
    Cache
    Logical Disks
    Memory
    Network Interface
    Physical Disks
    Process
    Processor
    System

    с интервалом 5 минут, собирайте хотя бы в течение суток (проблема за сутки успевает возникнуть?)
    затем выложите blg-файл куда-либо в архиве (можно в RAR под паролем) и дайте ссылку

    1 февраля 2010 г. 10:14
    Отвечающий
  • ОК, сделаем, а какую шкалу лучше поставить?
    1 февраля 2010 г. 10:36
  • Похоже, что дело в дисковых очередях, которые возникают (как я думаю) по причине неоправданно высокой степени использования файла подкачки.
    Позже сделаю журнал.
    1 февраля 2010 г. 11:23
  • шкала любая - для сбора это совершенно не важно
    касательно очередей - счётчик достаточно условный, смотрите время доступа...

    1 февраля 2010 г. 13:20
    Отвечающий
  • http://ifolder.ru/16205170
    Вот счетчики за 3 часа



    1 февраля 2010 г. 14:41
  • Думаю, что озвучу очевидное:
    1. Проблем с физической памятью у вас сейчас никаких нет - её достаточно в любое время на данном отрезке.
    2. Диск D: действительно не всегда справляется с нагрузкой, есть пики, но я не могу назвать их критичными - рекомендую поиграть с кэшем контроллера, оптимизировать на запись (возможно доставить батарейку для writeback)
    3. Я не увидел интенсивного обмена страницами - лишь ближе к концу лога IO порядка 8,5Мб, это не должно сильно затормаживать вам систему с учётом неповторяемости (в данном отрезке). Причём попадает этот пик на активность "Проводника" и RAR - подозреваю, что делали что-то с файлами сами.
    4. с диском C:, на который, как вы указали, настроен файл подкачки - нет проблем вообще... не то, чтобы нет - я бы сказал, на него вообще нагрузка минимальна
    Всё-таки я вам настоятельно рекомендую отпустить PageFile - хотя бы гигов до 8-12: у вас достаточно тяжёлые приложения, чтобы так зажимать. В остальном - я объективно не вижу проблем с данным сервером.
    • Предложено в качестве ответа AndricoRusEditor 2 февраля 2010 г. 10:06
    • Помечено в качестве ответа AndricoRusEditor 9 декабря 2010 г. 13:58
    1 февраля 2010 г. 16:09
    Отвечающий
  • Еще вопрос:
    Свойства системы - Дополнительно - Параметры (Быстродействие)
    Сейчас там включено: Оптимизировать работу "Служб, работающих в фоновом режиме" и "Системного кэша". Оставлять так или он считает SQL и AOS программами, а не службами?
    1 февраля 2010 г. 18:38
  • оставить именно так, как есть

    2 февраля 2010 г. 7:11
    Отвечающий
  • Еще, для увеличения скорости работы с файлом подкачки, Майкрософт рекомендует его выставить в рекомендуемый размер, не меньще, а лучше и верхний и нижний предел использования файла подкачки поставить на рекомендуемый максимум.
    При 8Г оперативной памяти это будет не ниже 12Г (от 12 до 12).
    Не понимаю этой рекомендации при больших объемах памяти, но она есть.
    2 февраля 2010 г. 7:26
  • Еще, для увеличения скорости работы с файлом подкачки, Майкрософт рекомендует его выставить в рекомендуемый размер, не меньще, а лучше и верхний и нижний предел использования файла подкачки поставить на рекомендуемый максимум.
    При 8Г оперативной памяти это будет не ниже 12Г (от 12 до 12).
    Не понимаю этой рекомендации при больших объемах памяти, но она есть.

    вчера как раз 12 ГБ и поставил. Посмотрим, как сегодня будет работать и отпишемся.
    2 февраля 2010 г. 7:44
  • А по-моему, надо отключить вообще файл подкачки...Бред какой-то - имеем достаточный объем ОЗУ, а используем файл подкачки.
    2 февраля 2010 г. 13:42
  • Полностью нельзя в принципе, в случае трапа не сохранит дампа памяти.
    Дурь, понимаю, но не мы это писали и это не юникс, а винда.


    А рекомендации разработчиков, сколь бы они ни были неожиданными, выполнять стоит.
    2 февраля 2010 г. 13:48
  • Григорий, файл подкачки отнюдь не решает вопросы недостатка памяти... это часть механизмов, обеспечивающих корректную работу системы - развитое кэширование необходимых данных в физ. памяти и т.д... отключите его - в принципе некоторое время система будет работать быстро, пока не наберёт данных в память... а вот потом всё резко встанет и вы получите "черепаху" и сообщения о недостатке виртуальной памяти... моё мнение - оставьте идею отключения файла подкачки "пионерам" на домашних системах...
    2 февраля 2010 г. 19:08
    Отвечающий
  • Среднее значение счетчика pages/sec и avg.disk queue leght у вас какие?


    кстати, при наличии SQL Server, да и вообще приложений активно использующих технологию memory mapped-файлов - pages/sec вообще способен повергнуть вас в ступор... и к pagefile это вообще может не относиться...
    6 февраля 2010 г. 8:54
    Отвечающий
  • Здравствуйте.
    Попробуйте этим средством проверить Sql
    SQL Server 2005 Best Practices Analyzer
    скачать
    мне он помог когда Sql тормозил на мощном сервере.
    потом сообщите что он покажет анализатор

    8 февраля 2010 г. 3:23
  • http://ifolder.ru/16309280

    Тут отчет о скане
    8 февраля 2010 г. 12:26
  • сужу по отчету:
    что дело немного в винтах - не успевают иногда.а так то все хорошо должно быть )
    9 февраля 2010 г. 5:04
  • В винтах? То есть ему SAS винтов в рэйдах ему не хватает?(:
    9 февраля 2010 г. 8:15
  • Купили еще 8 ГБ оперативки. Ситуация заметно улучшилась. Счетчики после установки оперативки тут: http://ifolder.ru/16527505
    Как считаете, стОит ли урезать файл подкачки? Сейчас стоит 12 ГБ
    22 февраля 2010 г. 8:08
  • Купили еще 8 ГБ оперативки. Ситуация заметно улучшилась. Счетчики после установки оперативки тут: http://ifolder.ru/16527505
    Как считаете, стОит ли урезать файл подкачки? Сейчас стоит 12 ГБ
    по новым счётчикам могу сказать всё абсолютно то же самое, что и говорил ранее - один в один...
    1. Проблем с физической памятью у вас сейчас никаких нет - её достаточно в любое время на данном отрезке.
    2. Диск D: действительно не всегда справляется с нагрузкой, есть пики, но я не могу назвать их критичными - рекомендую поиграть с кэшем контроллера, оптимизировать на запись (возможно доставить батарейку для writeback)
    3. Я не увидел интенсивного обмена страницами - лишь ближе к концу лога IO порядка 8,5Мб, это не должно сильно затормаживать вам систему с учётом неповторяемости (в данном отрезке). Причём попадает этот пик на активность "Проводника" и RAR - подозреваю, что делали что-то с файлами сами.
    4. с диском C:, на который, как вы указали, настроен файл подкачки - нет проблем вообще... не то, чтобы нет - я бы сказал, на него вообще нагрузка минимальна Всё-таки я вам настоятельно рекомендую отпустить PageFile - хотя бы гигов до 8-12: у вас достаточно тяжёлые приложения, чтобы так зажимать. В остальном - я объективно не вижу проблем с данным сервером.
    конечная рекомендация - точно НЕ урезать... более того - оставить в рамках 12-20Гб, впрочем - это исключительно моё мнение... если места свободного хватает - не трогайте pagefile: никакого заметного влияния на производительность дисковой подсистемы у вас он не оказывает, а стабильность системы будет значительно выше...
    22 февраля 2010 г. 8:38
    Отвечающий
  • Видимо, ситуация стала лучше (мы не замечаем тормозов в работе приложений) в связи с тем, что объем используемой памяти, примерно, 8 ГБ...то есть ровно столько, сколько у нас ее было до апгрейда...теперь есть запас и, я думаю, поэтому нет проблем.
    • Помечено в качестве ответа AndricoRusEditor 9 декабря 2010 г. 13:58
    22 февраля 2010 г. 8:44