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

[gl00mie]

Цитата:

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

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

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

[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

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

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

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

[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