Тестирование производительности АОС (32 || 64)

[SHiSHok]

Имеется Ax3sp3 и новая платформа с четырехядерным Xeon. Вопрос: под какой платформой (Win 2008 32 или 64 бит) АОС будет быстрее работать?
И какие способы измерения производительности вы бы предложили?

[glibs]

Я слышал на буржуйском форуме про какие-то проблемы, которые возникают на x64 у АОСа (не 5.0). Возможно, речь шла о 4.0 — точно не помню. Но на всякий случай учтите этот фактор как вводную (не только производительность рассматривайте).

[EfimV]

Насколько я понимаю, АХ3 тем более SP3, существует только в 32 битной версии. Чтобы по максимуму задействовать новый сервер думаю целесообразнее поднять на нём только базу. Вот тут 64 разрядная версия СУБД должна дать прирост производительности. Уверен, что сравнения между производительностью 64 и 32 разрядных версий СУБД будет на сайте производителя. Для сервера приложений в таком случае, лучше использовать отдельный сервер, пусть он будет «старый» и «немощный». Если всё запустить на одном сервере, то либо СУБД либо Ахсапта будет терять производительность.

[Vadik]

Цитата:

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

Имеется Ax3sp3 и новая платформа с четырехядерным Xeon. Вопрос: под какой платформой (Win 2008 32 или 64 бит) АОС будет быстрее работать?

А с чего бы 32-битному приложению быстрее работать под 64-битной ОС, тем более что оно (приложение) даже с 2 Гб памяти нормально управиться не может?

[SHiSHok]

Цитата:

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

Насколько я понимаю, АХ3 тем более SP3, существует только в 32 битной версии. Чтобы по максимуму задействовать новый сервер думаю целесообразнее поднять на нём только базу. Вот тут 64 разрядная версия СУБД должна ...

Про СУБД речь не идет. нужно АОСу дать максимум производительности.

[SHiSHok]

Цитата:

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

А с чего бы 32-битному приложению быстрее работать под 64-битной ОС, тем более что оно (приложение) даже с 2 Гб памяти нормально управиться не может?

ДА. АОС Ax3 только 32бит (для информации). Прирост производительности в 64битной среде, as for me, возможен только за счет исполнения системных запросов в x64.
Не знаю как исполняется 32битный код в x64 среде. Было бы полезно знать.

[EfimV]

Небольшое сравнение Win XP 64 и 32 бита.
http://www.thg.ru/software/20050827/index.html

Я обратил внимание на следующие моменты:
-Поскольку каждый элемент данных имеет длину 64 бита,
32-битные элементы для наследственных 32-битных приложений будут занимать
в два раза больше памяти по сравнению с 32-битной ОС.
-У версии x64 Edition : для 32-битных приложений доступны 4 Гбайт памяти.

[SHiSHok]

Цитата:

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

Я слышал на буржуйском форуме про какие-то проблемы, которые возникают на x64 у АОСа (не 5.0). Возможно, речь шла о 4.0 — точно не помню. Но на всякий случай учтите этот фактор как вводную (не только производительность рассматривайте).

это касается 32битного АОС или уже собранного под 64бит ?

[glibs]

АОС 3.0 и 4.0 под х64 не собирались. Стало быть речь идет о х86-ом АОС на х64-й ОС (не железе).

Поскольку теоретически приростом производительности использование х64-й машины не предвидится, есть смысл использовать х86-ю платформу с несколькими экземплярами АОС.

IMHO.

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

[SHiSHok]

Цитата:

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

АОС 3.0 и 4.0 под х64 не собирались. Стало быть речь идет о х86-ом АОС на х64-й ОС (не железе).

Поскольку теоретически приростом производительности использование х64-й машины не предвидится, есть смысл использовать х86-ю платформу с несколькими экземплярами АОС.

А для каких целей несколько АОС-ов на одной машине? Вижу смысл в нескольких АОС-ах для организации кластера на нескольких машинах целью распределения нагрузки. А на одной машине, мне кажется, и один АОС справится (какая разница какой процесс создаст пользовательскую нить).

[petergunn]

Цитата:

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

Имеется Ax3sp3 и новая платформа с четырехядерным Xeon.

Цитата:

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

А для каких целей несколько АОС-ов на одной машине? Вижу смысл в нескольких АОС-ах для организации кластера на нескольких машинах целью распределения нагрузки. А на одной машине, мне кажется, и один АОС справится (какая разница какой процесс создаст пользовательскую нить).

На данной платформе будет только один AOS запущен? Какое количество пользователей? Размещение других задач на этом сервере не планируется?
Если так, то врят ли он загрузит вычислительные ресурсы всех 4-х ядер Xeon - имеющегося железа ему хватит с запасом ( при этом искать возможный дополнительный выигрыш в использовании x64 ОС - это уже скорее спортивный интерес, imho).

На сколько я помню из курса Axapta 3.0 Installation&Configuration для 3-уровневой архитектуры упоминалось что AOS использует не более 2 CPU, при наличии 2 CPU рекомендации сводились к увеличению рабочей частоты процесоров и добавлению памяти:

Цитата:

Microsoft Business Solutions recommends that your AOS computers have no more than 2 CPUs. This recommendation is based on benchmark tests, which have shown that a 2-way server provides the best ROI (return on investment) and as a result, also provides the best utilization of the actual server hardware. Should a company expand in users, or if the behavior of the current users on the system change, you will need more processing power.

При таком раскладе, скорее всего 2 ядра из 4 будут простаивать без должной загрузки.
Чем не повод поднять на этом же железе еще 1 AOS?

[SHiSHok]

Цитата:

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

На данной платформе будет только один AOS запущен? Какое количество пользователей? Размещение других задач на этом сервере не планируется?
Если так, то врят ли он загрузит вычислительные ресурсы всех 4-х ядер Xeon - имеющегося железа ему хватит с запасом ( при этом искать возможный дополнительный выигрыш в использовании x64 ОС - это уже скорее спортивный интерес, imho).

да, платформа чисто под АОС (никаких других задач).

Цитата:

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

На сколько я помню из курса Axapta 3.0 Installation&Configuration для 3-уровневой архитектуры упоминалось что AOS использует не более 2 CPU, при наличии 2 CPU рекомендации сводились к увеличению рабочей частоты процесоров и добавлению памяти:
При таком раскладе, скорее всего 2 ядра из 4 будут простаивать без должной загрузки.
Чем не повод поднять на этом же железе еще 1 AOS?

Я думаю что эти рекомендации (именно рекомендации основанные на тестах, а не ограничения) были даны в те времена когда 2 процессора были двумя кристаллами, и, как сказано, это лучшее сочетание железо-производительность-инвестиции (опять же для стандартного функционала). Как АОС может грузануть 2xXeon3GHz (c гипертрейдингом) можете глянуть.
По памяти: после захвата АОС под 1Gb ОЗУ его стабильно начинает глючить (уже обсуждалось).
Так что, думаю, что грузить будет все доступные ресурсы.

[glibs]

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

Смотря чем занимаются пользователи. Может и 70 пользователей не загрузить 2 ядра, а может 7 перегрузить все 4. Я чаще наблюдал ситуации, более близкие к первому варианту, тем не менее.

SHiSHok, на ваш вопрос в мой адрес petergunn тем не менее ответил исчерпывающе. Я не стану попугайничать.

[sukhanchik]

Цитата:

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

А для каких целей несколько АОС-ов на одной машине?

Если говорить про 3-шку - то мы ставили несколько АОСов по 2-м причинам:
1. Каждому АОСу по процессору
2. На каждый АОС "вешали" свою логическую бизнес-группу пользователей (из расчета 30-40-50 конкурентных и в зависимости от их нагрузки на БД). Распределение было конечно неравномерное - но это позволяло уменьшить количество отваливающихся пользователей. Не секрет, что бывают ситуации, когда либо АОС надо рестартануть, либо кто-то что-то подвесил и т.д. Конечно - эти ситуации нельзя назвать частыми, но всегда хочется минимизировать поток жалоб "а у меня отвалилась аксапта". Т.о. финансисты работали под одним АОСом, логисты под другим, высшее руководство под третьим. И если логисты заваливали АОС (всякое бывало) - то больше никто не страдал

[SHiSHok]

Цитата:

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

SHiSHok, на ваш вопрос в мой адрес petergunn тем не менее ответил исчерпывающе. Я не стану попугайничать.

Не хочу показаться непонятливым, но в чем собственно состоит исчерпывающесть ответа уважаемого petergunn?
Моя реальность грузит все вычислительные мощности имеющегося АОС в пики нагрузки почти на 100% (имеется в виду 4 виртуальных процессора. картинку показывал). Поэтому и стоит вопрос производительности системы.

[gl00mie]

Цитата:

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

Я думаю что эти рекомендации (именно рекомендации основанные на тестах, а не ограничения) были даны в те времена когда 2 процессора были двумя кристаллами, и, как сказано, это лучшее сочетание железо-производительность-инвестиции

Мне кажется, дело все же в том, что при большем числе доступных процессоров (т.е. большем, чем 2, количестве одновременно выполняющихся потоков того же процесса AOS) возрастают требования к распараллеливаемости выполняемого кода, и в случае с AOS 3-ей версии упирается все в библиотеку управления динамической памятью, а именно в SmartHeap 6.01. Некоторые изыскания на эту тему можно найти тут. Вкратце, SmartHeap бывает "обычная" для многопоточных приложений (но расчитанная на одно процессорное ядро) и для симметричных многопроцессорных систем - SmartHeap/SMP. Второй вариант библиотеки отличается тем, что одновременно выполняющиеся на разных процессорах (ядрах) потоки не блокируют друг друга на операциях с динамически выделяемой памятью. За счет этого производительность использующего SmartHeap/SMP многопоточного приложения, интенсивно работающего с динамически выделяемой памятью, гораздо лучше масштабируется с увеличением числа процессоров/ядер. В случае же "обычной" SmartHeap масштабируемость резко сходит на нет ориентировочно начиня с двух ядер.

Цитата:

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

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

Конечно, могут быть разные варианты: значительную долю процессорного времени может использовать код, занимающийся интенсивными вычислениями и работающий с небольшим набором объектов, память под которые не нужно постоянно выделять/освобождать; в этом случае несколько сессий на AOS'е, выполняющих такой код, смогут успешно грузить многоядерные Xeon'ы. Но мне кажется, применительно к Аксапте это не самый типичный сценарий...

[SHiSHok]

Цитата:

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

2. На каждый АОС "вешали" свою логическую бизнес-группу пользователей (из расчета 30-40-50 конкурентных и в зависимости от их нагрузки на БД). Распределение было конечно неравномерное - но это позволяло уменьшить количество отваливающихся пользователей. Не секрет, что бывают ситуации, когда либо АОС надо рестартануть, либо кто-то что-то подвесил и т.д. Конечно - эти ситуации нельзя назвать частыми, но всегда хочется минимизировать поток жалоб "а у меня отвалилась аксапта". Т.о. финансисты работали под одним АОСом, логисты под другим, высшее руководство под третьим. И если логисты заваливали АОС (всякое бывало) - то больше никто не страдал

Экспериментировал как то с нескольким АОСами. Все бы ничего, но интенсивное обновление данных в одном АОСе с задержками отображалось в другом, что непозволительно для существующих бизнес-процессов.

[gl00mie]

Цитата:

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

Моя реальность грузит все вычислительные мощности имеющегося АОС в пики нагрузки почти на 100% (имеется в виду 4 виртуальных процессора. картинку показывал). Поэтому и стоит вопрос производительности системы.

А сколько при этом сессий работает одновременно? Они равномерно грузят процессор, или же выделяются одна-две-три сессии, которые используют львиную долю процессорного времени (см. Как обнаружить какой пользователь загружает процессор AOS и сопутствующий проект)? Если сессий, дающих основную нагрузку, немного, то, может, поинтересуетесь, что именно делают/запускают пользователи. Может, дело не в железе, а в особенностях реализации доработок.

Цитата:

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

Экспериментировал как то с нескольким АОСами. Все бы ничего, но интенсивное обновление данных в одном АОСе с задержками отображалось в другом, что непозволительно для существующих бизнес-процессов.

Боюсь, применительно к 3-ке увеличение количества AOS'ов - один из немногих способов существенного повышения производительности системы, когда "узким местом" является именно AOS. На одном AOS'е очень легко упереться не в процессор(ы), так в память - пресловутый «1Gb ОЗУ, после захвата которого его стабильно начинает глючить».

[SHiSHok]

Цитата:

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

Вкратце, SmartHeap бывает "обычная" для многопоточных приложений (но расчитанная на одно процессорное ядро) и для симметричных многопроцессорных систем - SmartHeap/SMP.
...................
Но мне кажется, применительно к Аксапте это не самый типичный сценарий...

Загрузку процов уже показывал. Про SmartHeap интересная информация.
Сделал вывод что надо тестировать рабочей нагрузкой нашего репозитария.

[Lazy_Tiger]

я бы рассмотрел (на таком железе) вариант с подниманием Win2008 с ролью Hyper-V

Т.е. созданием кластера AOS'ов в виртуальных машинах. Накладные расходы несколько выше, но появляются интересные сценарии использования.

В новом проекте буду проводить тестирование такого варианта, по результатам отпишусь...