Перемога outofmemoryexception, windraw dot net

Досить довго ми боролися за продуктивність програми WinDraw. а саме за взаємодію між WinDraw і MS SQL Server.

За час цієї боротьби ми зробили кілька серйозних висновків:

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

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

Уже більше місяця ми не отримували помилки 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 практично виключена.