Победа OutOfMemoryException

Автор: | 2 августа 2010

Довольно долго мы боролись за производительность программы WinDraw, а именно за взаимодействие между WinDraw и MS SQL Server.

За время этой борьбы мы сделали несколько серьезных выводов:

1. Использование метода dbo.ZipUnPack в запросах(то есть на стороне SQL Server) построителя отчетов Stimulsoft Reports.Net приводил к тому, что ошибка System.OutOfMemoryException появлялась гораздо чаще!!! Переведя выполнение этого метода на сторону сервера приложений (т.е. используя Atechnology.Components.ZipArchiver.UnZip2 (byte[] classnative) ) мы значительно увеличили время работы SQLServer без перезагрузки!!!

2. Железный апгрейд не решает проблему System.OutOfMemoryException, доказано опытным путем!!! А именно, с момента первого описания проблемы (Проблема производительности WinDraw...) мы приобрели новый сервер — Hewlett Packard Proliant DL380G6 (2xXeonQC, 32Gb оперативной памяти), на котором установили Microsoft Windows Server 2003 Ent, Microsoft SQL Server 2008 Ent. В настройках Microsoft SQL Server включили опцию Address Windowing Extensions (AWE). Уже на следующий день мы получили ошибку System.OutOfMemoryException, причем судя по Task Manager оперативная память была использована всего НАПОЛОВИНУ!!!

Исходя из всего этого, и множества советов в интернете(правда большинство советов относилось к работе программы 1С с SQL Server, но проблема была очень похожа на нашу) — решено было попробовать использовать x64 платформу и ПО.

На Этот же самый сервер (Hewlett Packard Proliant DL380G6 (2xXeonQC, 32Gb оперативной памяти)) была установлена операционная система Microsoft Windows Server 2008 R2 Enterprise x64, Microsoft SQL Server 2008 R2 x64, опция Address Windowing Extensions (AWE) выключена (кстати пришла идея попробовать включить и ее!!!). Итог потрясающий!!!

Уже больше месяца мы не получали ошибки System.OutOfMemoryException, хотя оперативная память используется практически полностью!

System.OutOfMemoryException

Исходя из этого данный набор ПО считаем необходимым при одновременном доступе к SQL Server более 30 пользователей.

З.Ы. В ближайшее время попробуем включить опцию Address Windowing Extensions (AWE) и опишем результат!


Немного технической информации!

Механизм Address Windowing Extensions (AWE), используемый в SQL Server, состоит из двух частей, распределяющих физическую память и отображающую её на Virtual Address Space (VAS) данного процесса. Если физическая память распределена, то операционная система уже не сможет её затребовать, пока использующий её процесс не будет завершён или этот процесс освободит память, вернув её операционной системе. Приложение может управлять и даже полностью предотвращать листание. Преимущество механизма mapping/unmapping в том, что одна и та же физическая страница может быть отображена на разные участки VAS. На 64-х битных платформах в unmapping нет необходимости, поскольку VAS мы имеем достаточно, чтобы вместить всю имеющуюся физическую память.

Из теории операционных систем, для описания отображения страницы VAS на физические страницы, система оперирует записями таблицы страниц — Page Table Entry (PTE). Внутри физическая страница описывается номером блока страниц — Page Frame Number (PFN). Из PFN можно получить всю информацию о физической странице, которую он представляет. Например, PFN показывает, какому Non-Uniform Memory Access (NUMA) — узлу принадлежит эта страница. В операционной системе есть база данных, хранящая совокупность PFN, которыми система управляет. Если страница в VAS является закреплённой, существует PTE, который может указывать или не указывать на задействованные PFN. Концептуально, страница, которую представляет PTE, может быть в памяти или нет, например, если она выгружена на диск. В первом случае она привязана к задействованному PFN, а в последнем — нет. В свою очередь, как только физическая страница привязывается к странице в VAS, её PFN возвращаются PTE.

Когда операционная система закрепляет, освобождает, получает/отдаёт страницы задействованного PTE, или должна получить немного информации об этом (например аллокация NUMA), она должно задействовать блокировку рабочего множества процесса — чтобы обеспечить стабильность привязки PTE к PFN. Эта блокировка обходиться довольно дорого и может испортить масштабируемость процесса.

При распределении физических страниц, использование AWE механизма предоставляет нам набор записей PFN непосредственно из базы данных PFN. Операционная система обязана устанавливать блокировку на базу данных PFN во время распределения записей PFN. Используя механизм отображения AWE, Вы можете отобразить аллоцируемые записи PFN на VAS процесса. Когда происходит такое отображение, PTE аллоцируются, привязываются к PFN и отмечаются как блокированые. В этом случае операционная система должна разово установить блокировку рабочего множество процесса. При отображении обычных страниц, операционная система делает это по требованию и, следовательно, должна будет заполучить рабочее множество и установить блокировку в базе данных PFN для каждой страницы. Так как страницы в памяти блокированы, в момент листания эти PTE системой будет игнорироваться.

На 64-х битных платформах лучше называть такие страницы блокированными страницами (locked pages), и, пожалуйста, не путайте их со страницами, блокированными средствами VirtualLock API. Как было описано выше, у блокированных страниц есть два важных свойства — они не участвуют в листании, проводимом операционной системой, и во время распределения они захватывают рабочее множество и устанавливают разовую блокировку в базе данных для PFN.

Первое свойство имеет не очевидное влияние на высокопроизводительные системы, такие, как системы с архитектурой NUMA. Оно приводит к явной резидентности в памяти. Помните, что система закрепляет страницы по требованию. Для распределения физической памяти будет использоваться узел, на котором выполняется обращающийся к памяти поток. Только после этого страница может быть выгружена операционной системой во время свопинга. Далее, она может снова попасть в память, операционная система снова распределит физическую страницу узлу, на котором поток продолжает работать с этой памятью. В этом случае узел может оказаться уже совсем другим. Такое поведение приведет к дополнительной нагрузке на приложения, которые используют для страниц резидентность NUMA. Блокировка страницы позволяет разрешить эту проблему, полностью защищая их от листания.

Второе свойство — захват рабочего множества и блокировка в базе данных только PFN, дает возможность приложениям работать быстрее и повышает масштабируемость пилообразной нагрузки.

В NUMA архитектуре, SQL Server Buffer Pool фиксирует каждую распределенную страницу с выделенным для неё узлом. Достигается этого за счёт использования QueryWorkingSetEx. Как только страница распределена, вызывается этот API, который позволяет узнать детали резидентности страницы. Делается это только один раз. Поэтому включение locked pages для SQL Server на 64-х битной платформе улучшает работу с пилообразной нагрузкой и повышает производительность и масштабируемость на более длительных отрезках времени. При работе SQL Server в режиме locked pages, Вам не нужно больше волноваться о производительности системы в целом, зависимости от изъятия памяти у SQL Server, когда он участвует в механизме листания операционной системы, прослушивая оповещения отвечающего в системе за память API, и сокращая своё рабочее множество, когда это от него требуют.

Давайте подведём итог этой статьи: на 64-х битных платформах VAS мы имеем достаточно, чтобы вместить всю имеющуюся физическую память, поэтому вероятность получения исключения System.OutOfMemoryException практически исключена.

Использованы материалы:

1. http://blogs.msdn.com/b/slavao/archive/2005/04/29/413425.aspx
2. http://sqlblogcasts.com/blogs/christian/archive/2008/01/07/sql-server-memtoleave-vas-and-64-bit.aspx

Победа OutOfMemoryException: 6 комментариев

  1. Мимо Проходил

    «... такие, какими их написал разработчик. ...»

    Ой! я извиняюсь, я думал вы и есть разработчик. Разработчики не соображают ничего в MS SQL SERVER'е потому у вас как заказчика такие проблемы. Очень жаль.

    1. Внедренец Автор записи

      Нет, мы заказчики. Хотя понемногу становимся разработчиками 😉 Ибо разработчик не спешит решать проблем.

      Кстати, недавно появилось обновление для MS SQL 2008 R2, которое борется с сетевой утечкой памяти. Обновление пока доступно только по требованию, мы его уже установили у себя, и пока тестируем. Но результаты уже впечатляют — память просто так не растет, как раньше. А постепенно набирается, по ночам понемногу возвращается. Как будем уверенны — опишу что это за обновление и как оно действует.

      Пока вот ссылка — support.microsoft.com/kb/2345451

  2. Внедренец Автор записи

    Да мы и не позоримся, а пишем что есть. Схема данных и хранимые процедуры такие, какими их написал разработчик. И такая проблема не у нас одних — почитайте комментарии www.windraw.net/2010/03/p...sti-windraw.html . В некоторых компаниях и того меньше пользователей, а ошибка такая время от времени появляется...

  3. Мимо Проходил

    «...Исходя из этого данный набор ПО считаем необходимым при одновременном доступе к SQL Server более 30 пользователей...»

    Не позорьтесь. То что у вас OutOfMemory было при таком вшивеньком количестве пользователей — 30, говорит лишь о кривой схеме данных и кривых хранимых процедурах.

  4. Внедренец Автор записи

    1. Билды от Атехнолоджи — это отдельная история. У меня хранятся все бекапы, кроме первых трех... Но эти первые три стоили мне очень дорого... Никогда не знаешь, что потеряешь в новом билде. Не было такого обновления, после которого помимо нужных исправлений мы бы не получили новых ошибок (иногда даже уже решенных ранее!!!). Но об этом будет написано отдельно, когда-нибудь. Если у нас будет Ваш новый билд — мы его с радостью потестируем на нашей тестовой базе, и обязательно опишем результат.

    2. Молодцы. Однако никто из Вас до этого сообщения ни разу не писал об этом. Ваши сотрудники лишь советовали обновить платформу Net Framework (вот комментарий — www.windraw.net/2010/03/p...w.html#comment-4)...

    3. Наша фраза написана правильно, ибо есть еще один SQL Server и программы от трех разных разработчиков. Все они прекрасно уживаются и проблем с использованием памяти не возникает. Поэтому проблема реально проявляется в связке WinDraw и MS SQL Server...

  5. Александр

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

    2. sql server 2008 r2 всем настоятельно советуем

    3. фраза «Довольно долго мы боролись за производительность программы WinDraw, а именно за взаимодействие между WinDraw и MS SQL Server.» на самом деле, если быть чуточку корректней к компании-разработчику 🙂 должна звучать так: «мы ... за производительность и стабильность работы ms sql server», но это, я так...

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*