После установки KR2 на AX3 SP3 не пускает на AOS больше 100 пользователей

[Alexandr A. Osipkin]

Здравствуйте.

После установки KR2 на AX3 SP3 не пускает на AOS больше 100 пользователей. В логе появляются ошибки, пришлось поднять второй AOS.
Подскажите пожалуйста, как решить эту проблему.

С уважением, Александр

[glibs]

Вы уж меня простите если грубовато получилось, но это самый что ни на есть RTFM

"...
AOS Enhanced Stability and Logging
Registry Keys have been added for the purpose of tightening configuration when the AOS is in a low resource scenario. If these limits are reached, the AOS will reject new connections. If these keys do not exist, or if they exist without a value, Axapta uses the default value listed for each key. If enabling this functionality, configure each key for each instance of the AOS running.
\HKLM\SYSTEM\CurrentControlSet\Services\Axapta Object Server\Applications\<AOS Instance Name>\3.0\<AOS Config Name>
These keys may be replicated to the CurrentControlSet001 and CurrentControlSet002. See Microsoft Knowledge Base article 100010, “What are Control Sets? What is CurrentControlSet? (http://go.microsoft.com/fwlink/?LinkId=59068)” for more information on Control Sets.
Note: The registry settings may have to be set for each control set for each AOS instance configured. This may not be a one place registry change.
The following table lists the default values, which are also the recommended values. Note that they are string values.
Reg key Type Default
MaxConcurrentSessions REG_SZ1 100
MaxMemPercentage REG_SZ1 50
MaxConcurrentSessions
Set the value of this key to the number of concurrent sessions that you want the upper limit to be.
MaxMemPercentage
Set this value to the percentage of memory that you want the AOS process (ax32serv.exe) to use. This total memory percentage includes pagefile.
..."

На форуме тоже где-то обсуждалось. Наверняка можно найти в поиске.

Кстати, более 100 пользователей на один АОС — многовато, IMHO.

[Alexandr A. Osipkin]

Цитата:

Сообщение от glibs

Вы уж меня простите если грубовато получилось, но это самый что ни на есть RTFM
На форуме тоже где-то обсуждалось. Наверняка можно найти в поиске.

Кстати, более 100 пользователей на один АОС — многовато, IMHO.

Прошу прощения Просто поторопился, сразу написал на форум. На счёт количества пользователей - реально работают 20-30

[somebody]

Цитата:

Сообщение от glibs

Кстати, более 100 пользователей на один АОС — многовато, IMHO.

Если SQL-сервер/сеть нормальные в плане железа, то АОС(ы) 2.5/3 перегрузить маловероятно. Даже и сотнями пользователей. Притом АОС может быть далеко не таким мощным, как SQL. Конечно, "ПМСМ".

[egorych]

Цитата:

Сообщение от somebody

Если SQL-сервер/сеть нормальные в плане железа, то АОС(ы) 2.5/3 перегрузить маловероятно.

Весьма смелое заявление! Помимо процессора и сети есть еще такой ресурс как RAM. А т.к. АОС сам по себе 32-битный и по статистике больше 1Г "съесть" и не подавиться вообще не в состоянии, то перегрузить его вообще-то достаточно просто.

[gl00mie]

Цитата:

Сообщение от somebody

Если SQL-сервер/сеть нормальные в плане железа, то АОС(ы) 2.5/3 перегрузить маловероятно. Даже и сотнями пользователей.

А вы в курсе, зачем установщик виндов в зависимости от того, сколько процессоров на компе, где он запущен, ставит винды с разными ядрами - однопроцессорным или многопроцессорным? Все дело в том, что в последнем случае используется куда больше объектов синхронизации (критических секций, семафоров, etc) при доступе к различным ресурсам ядра, что не лучшим образом сказывается на производительности - оттого на однопроцессорных машинах и используется "облегченная" сборка ядра. Не стоит забывать, что у AOS'а наверняка тоже есть ресурсы, осуществлять доступ к которым необходимо "по очереди", и при этом на каждое пользовательское подключение он запускает отдельный поток, который при доступе к таким ресурсам должен синхронизироваться со всеми остальными потоками. Так вот, при большом числе пользователей (и, соотв., запущенных потоков) AOS может начать тормозит уже не из-за железа, а из-за взаимоблокировок между отдельными потоками.

[glibs]

Цитата:

Сообщение от somebody

...
Если SQL-сервер/сеть нормальные в плане железа, то АОС(ы) 2.5/3 перегрузить маловероятно.
...

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

Все зависит от задач. Если пользователи неспеша открывают формы и счелкают по закладкам, то АОС может и 300 пользователей выдержать, я так думаю.

[fed]

to gl00mie: А ты случайно не разбирался как сам ax32serv работает с объектами синхронизации ? У меня просто есть подозрение, что рекомендация использовать на AOS-серверах не больше двух процессоров, вызвана тем, что в недрах ax32server есть Big Kernel Lock, который приводит к тому, что в реальных условиях система плохо масштабируется на более чем два процессора на компе. Примерно как в ядрах Linux до версии 2.2.x. Там, фактически, все ядро было неповторновходимым, поэтому в теории систему можно было использовать на любом количестве процессоров, но из за того что само ядро было критическим ресурсом, в реальных ситуациях использования Linux (с нормальным вводом-выводом короче говоря), ставить больше двух процессоров было бесполезно.

[gl00mie]

Цитата:

Сообщение от fed

А ты случайно не разбирался как сам ax32serv работает с объектами синхронизации ? У меня просто есть подозрение, что рекомендация использовать на AOS-серверах не больше двух процессоров, вызвана тем, что в недрах ax32server есть Big Kernel Lock, который приводит к тому, что в реальных условиях система плохо масштабируется на более чем два процессора на компе.

По правде сказать, особо не разбирался... Если же взглянуть поверхностно, то выходит вот что.

• ax32serv.exe версии KR2 импортирует следующие функции синхронизации:
  • CreateEvent, SetEvent;
  • InitializeCriticalSection, InitializeCriticalSectionAndSpinCount, EnterCriticalSection, TryEnterCriticalSection, LeaveCriticalSection, DeleteCriticalSection;
  • CreateMutex, OpenMutex, ReleaseMutex;
  • WaitForMultipleObjects, WaitForSingleObject;
  • InterlockedExchange, InterlockedIncrement, InterlockedDecrement;
  при этом InitializeCriticalSectionAndSpinCount используется вместо InitializeCriticalSection в 1-м месте С-шной RTL и в 1-м месте собственно AOS'ом - и почему-то через GetProcAddress; неужели разработчики расчитывали на запуск AOS'а под Win95 или WinNT4 до SP3? ну да ладно...
• функции Interlocked* нас не интересуют, поскольку серьезных блокировок они создать не могут;
• WaitForMultipleObjects используется в одном месте для одного объекта (дескриптора hThread) с таймаутом 5 сек., при этом код, вызывающий эту функцию, занимается закрытием сокетов;
• взаимоисключения (Mutex) используются, видимо, только библиотекой SmartHeap: в одном случае создается (и потом запрашивается) глобальный Mutex с именем "SmartHeap601MutexMovShrName", в другом создаются взаимоисключения с именами формата "SHI%lX", где %l получается генератором случайных чисел, а полученный дескриптор взаимоисключения сохраняется в свойстве динамически создаваемого объекта, т.е. не является неким глобальным объектом;
• критические секции используются очень широко и зачастую являются свойством того или иного динамически создаваемого объекта; возможно, есть глобальные критические секции. Мне с полпинка встретилась одна, используемая 3-мя разными функциями для выполнения очень небольших кусков кода, как правило, прописывания в свойстве динамически созданного объекта адреса другой (созданной для него?) критической секции;
• события (Event) - тут начинается самое "веселое". Мне встретились как минимум 5 глобальных Event'ов, правда, один из них "дергается" в обработчике RestoreUnhandledExceptionFilter() и, видимо, относится к RTL. Но самое поганое (или просто недоступное моему пониманию на том уровне, на котором я "знаю" использующий их код) - это то, как происходит работа с этими глобальными объектами. Обычно события используются при ожидании того, когда они перейдут в мнэ.. сигнальное (signaled) состояние, либо пока не истечет какой-то таймаут. Так вот, как минимум два из найденных пяти глобальных собыий, по ходу, никогда не переходят в сигнальное состояние (я не нашел вызовов SetEvent, где они передавались бы в качестве параметров). Одно из этих двух глобальных событий монопольно используется одной функцией, которая просто вызывает на нем WaitForSingleObject с переданным в параметре таймаутом и фактически эквивалентна Sleep(). Эта функция вызывается из 14 различных мест с таймаутами в среднем 250-500мс, при этом одно из мест, откуда она вызывается, - это функция-заглушка, которая просто передает ей параметры и, в свою очередь, вызывается еще из 9 различных мест. Выглядит это, скажем так, непонятно.

В общем, код, использующий объекты синхронизации, работает местами очень загадочно... Два из пяти найденных глобальных событий, которые все же переходят при определенных условиях в сигнальное состояние, могут претендовать на роль «Big Kernel Lock», но для подтверждения этого нужно копать более тщательно. Плюс еще неизвестно, какая версия библиотеки SmartHeap используется Аксаптой. Насколько я знаю, есть отдельная версия SmartHeap SMP для многопроцессорных машин, так вот не факт, что использована именно она.

Цитата:

Сообщение от fed

Примерно как в ядрах Linux до версии 2.2.x. Там, фактически, все ядро было неповторновходимым, поэтому в теории систему можно было использовать на любом количестве процессоров, но из за того что само ядро было критическим ресурсом, в реальных ситуациях использования Linux (с нормальным вводом-выводом короче говоря), ставить больше двух процессоров было бесполезно.

На счет линукса не скажу, но что-то схожее было в Win9x, в частности, Matt Pietrek в "Секретах программирования под Windows 95" писал про некий глобальный Mutex, из-за которого в Win9x были проблемы с эмуляцией вытесняющей многозадачности Кажется, это было отчасти связано с кодом GDI, унаследованным от Win 3.1, с кучей ручных оптимизаций, использующих глобальные переменные, по причине которых этот код стал по большей части "нереентерабельным".

[somebody]

Цитата:

Сообщение от egorych

...перегрузить его вообще-то достаточно просто...

Цитата:

Сообщение от gl00mie

...Не стоит забывать, что у AOS'а наверняка тоже есть ресурсы... AOS может начать тормозить...

Цитата:

Сообщение от glibs

Все зависит от задач. ... я так думаю.

Так. Я не теоретически отвечал. Я просто практически не сталкивался с перегрузкой АОСа (не имею в виду сбои/глюки, этого хватало!). И не будем показывать пальцами: "Ха-ха-ха, он не сталкивался с перегрузкой АОСа!". Вот на практике у Вас были случаи, когда производительность проседала именно из-за АОСа, и это было доказано? Можно конкретнее описать ситуацию?

Думаю, это была бы полезная информация для настройки объектного сервера/кластера.

[Garic]

Всё зависит от задач.
Проблема возникает не в производительности а скорее в возможности работать.

На одном проекте АОС постоянно валился на 70-ти пользователях из-за нехватки памяти. Из-за изобилия трудоёмких операций. Как только поставили второй АОС - стало хорошою

На другом проекте один АОС прекрасно себя чуствовал при более чем 200 пользователей. Здесь все трудоёмкие операции выведены на пакетный сервер и выполняются в двузвенке.
Сразу после перехода на 4.0 и исчезновения двузвенки - АОС стал падать раз по десять за день. Поставили второй АОС - отпустило.

[gl00mie]

Цитата:

Сообщение от fed

У меня просто есть подозрение, что рекомендация использовать на AOS-серверах не больше двух процессоров, вызвана тем, что в недрах ax32server есть Big Kernel Lock, который приводит к тому, что в реальных условиях система плохо масштабируется на более чем два процессора на компе.

Не дает мне покоя этот вопрос...
У меня прежде была уже библиотека SmartHeap 8.0, а недавно я выклянчил на "посмотреть" версию SmartHeap/SMP 8.1 - захотелось сравнить с ними код ядра Аксапты, чтобы точно узнать, какая из разновидностей там используется. В выборе версий, как выяснилось, разработчики очень консервативны: они использовали SmartHeap 6.0.1 со всеми сборками ядра Axapta 3.0, выходившими с октября 2002 по октябрь 2006-го года, т.е. на протяжении 4-х лет (я проверял ядра с 3.0.1951.17 по 3.0.1951.7609). Собственно, чтобы определить номер версии SmartHeap, достаточно посмотреть, что возвращает метод класса HeapCheck.version(), а возвращает он отформатированное в виде строки число, которое получает от функции MemVersion() из библиотеки SmartHeap, статически скомпонованной с ядром Аксапты. Со всеми сборками ядра DAX 4.0 используется уже версия SmartHeap 8.0.0, что, опять же, нетрудно проверить, но самое интересное в другом. Несмотря на то, что мне удалось найти упоминание о существовании версии SmartHeap/SMP 6.0.1 (фраза после "Buzzword bonanza of the year"), датированное примерно маем 2002-го, в ядре Axapta 3.0, как это ни печально, используется "обычная" версия SmartHeap для многопоточных приложений, а не SmartHeap/SMP. По крайней мере, к такому выводу я пришел после некоторого анализа кода этой библиотеки в ядре Аксапты и сравнения с теми версиями библиотеки SmartHeap, которые у меня имеются. Печально же это в свете того, что говорится в документации, описывающей изменения в версиях SmartHeap (пусть и про 8-ю версию, но сдается мне, это - коренное различие SmartHeap и SmartHeap/SMP):

Цитата:

Note that the general performance improvements in SmartHeap version 8 [...] are available only when running on single-processor (including hyperthread-enabled Intel processor) systems. The performance enhancements are enabled on SMP systems only in the SmartHeap/SMP product.

Отсюда, как мне представляется, и растут ноги слабой масштабируемости сервера приложений Axapta 3.0 на многопроцессорных серверах. Но есть и хорошая новость: судя по анализу кода, в ядре DAX 4.0 используется именно SmartHeap/SMP! Причем выигрыш в производительности тут может быть не только за счет масштабируемости, но и просто за счет использования новой версии этой библиотеки, поскольку в документации, опять-таки в описании изменений написано буквально следующее

Цитата:

The SmartHeap 8.0 multi-threaded libraries contain performance optimizations making them up to 2x faster than version 7. The performance improvement is greatest on the Windows operating system.

Так что скорее обновляемся на 4-ку
PS. Первая мысль после расковыривания версии SmartHeap в Axapta 3.0 была: пропатчить ядро AOS'а, чтобы вместо статически скомпонованной 6-й версии он использовал DLL-версию SmartHeap/SMP 8.1

[fed]

Ну и для завершения этой темы, надо заметить что в DAX 2009 от использования SmartHeap отказались (поскольку даже SMP - версия была неидеальна с точки зрения работы с объектами синхронизации). В версии 2009 smartheap бlibrary был заменена на Low Fragmentation Heap, появившийся в Windows 2003.

[Logger]

Цитата:

Сообщение от fed

Ну и для завершения этой темы, надо заметить что в DAX 2009 от использования SmartHeap отказались (поскольку даже SMP - версия была неидеальна с точки зрения работы с объектами синхронизации). В версии 2009 smartheap бlibrary был заменена на Low Fragmentation Heap, появившийся в Windows 2003.

А доступ из X++ к ней сохранили ? Т.е. сохранился ли класс HeapCheck ?

Недавно ковырял Ax 3.0 - очень порадовали его возможности. Оказывается с его помощью легко самим ловить утечки памяти.

Для этого даже в поставку входит класс HeapLog - позволяет в произвольный момент сделать "снимок" кучи и сбросить на диск, а в другой момент времени - сравнить слепок с диска с текущим состянием и сбросить в лог различия.

[fed]

Цитата:

Сообщение от Logger

А доступ из X++ к ней сохранили ? Т.е. сохранился ли класс HeapCheck ?

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