|
![]() |
#1 |
Участник
|
А вы в курсе, зачем установщик виндов в зависимости от того, сколько процессоров на компе, где он запущен, ставит винды с разными ядрами - однопроцессорным или многопроцессорным? Все дело в том, что в последнем случае используется куда больше объектов синхронизации (критических секций, семафоров, etc) при доступе к различным ресурсам ядра, что не лучшим образом сказывается на производительности - оттого на однопроцессорных машинах и используется "облегченная" сборка ядра. Не стоит забывать, что у AOS'а наверняка тоже есть ресурсы, осуществлять доступ к которым необходимо "по очереди", и при этом на каждое пользовательское подключение он запускает отдельный поток, который при доступе к таким ресурсам должен синхронизироваться со всеми остальными потоками. Так вот, при большом числе пользователей (и, соотв., запущенных потоков) AOS может начать тормозит уже не из-за железа, а из-за взаимоблокировок между отдельными потоками.
Последний раз редактировалось gl00mie; 23.10.2007 в 12:13. Причина: typo... |
|
![]() |
#2 |
Moderator
|
to gl00mie: А ты случайно не разбирался как сам ax32serv работает с объектами синхронизации ? У меня просто есть подозрение, что рекомендация использовать на AOS-серверах не больше двух процессоров, вызвана тем, что в недрах ax32server есть Big Kernel Lock, который приводит к тому, что в реальных условиях система плохо масштабируется на более чем два процессора на компе. Примерно как в ядрах Linux до версии 2.2.x. Там, фактически, все ядро было неповторновходимым, поэтому в теории систему можно было использовать на любом количестве процессоров, но из за того что само ядро было критическим ресурсом, в реальных ситуациях использования Linux (с нормальным вводом-выводом короче говоря), ставить больше двух процессоров было бесполезно.
|
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от fed
![]() А ты случайно не разбирался как сам ax32serv работает с объектами синхронизации ? У меня просто есть подозрение, что рекомендация использовать на AOS-серверах не больше двух процессоров, вызвана тем, что в недрах ax32server есть Big Kernel Lock, который приводит к тому, что в реальных условиях система плохо масштабируется на более чем два процессора на компе.
Цитата:
Сообщение от fed
![]() Примерно как в ядрах Linux до версии 2.2.x. Там, фактически, все ядро было неповторновходимым, поэтому в теории систему можно было использовать на любом количестве процессоров, но из за того что само ядро было критическим ресурсом, в реальных ситуациях использования Linux (с нормальным вводом-выводом короче говоря), ставить больше двух процессоров было бесполезно.
![]() Последний раз редактировалось gl00mie; 24.10.2007 в 00:59. |
|
|
За это сообщение автора поблагодарили: raz (8). |
![]() |
#4 |
Участник
|
"практика - критерий истины"
Цитата:
Сообщение от egorych
...перегрузить его вообще-то достаточно просто...
Цитата:
Сообщение от gl00mie
...Не стоит забывать, что у AOS'а наверняка тоже есть ресурсы... AOS может начать тормозить...
Цитата:
Сообщение от glibs
Все зависит от задач. ... я так думаю.
Думаю, это была бы полезная информация для настройки объектного сервера/кластера. |
|
![]() |
#5 |
Участник
|
Цитата:
![]() У меня прежде была уже библиотека 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.
![]() Цитата:
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.
![]() PS. Первая мысль после расковыривания версии SmartHeap в Axapta 3.0 была: пропатчить ядро AOS'а, чтобы вместо статически скомпонованной 6-й версии он использовал DLL-версию SmartHeap/SMP 8.1 |
|
|
За это сообщение автора поблагодарили: glibs (2), Logger (10). |
Теги |
администрирование, ax3.0 |
|
|