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

[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 ОЗУ его стабильно начинает глючить (уже обсуждалось).
Так что, думаю, что грузить будет все доступные ресурсы.

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

[SHiSHok]

Цитата:

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

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

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

[Lazy_Tiger]

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

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

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

[gl00mie]

Цитата:

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

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

Цитата:

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

в любом случаем, повторю идею с Hyper-V - в этом случае песочницы у каждого АОСа своя. Железо позволяет.

Позволю себе небольшое уточнение этого предложения: Windows Server 2008 все-таки стоит денег и, если его использовать сугубо для запуска виртуалок, думаю, сам будет потреблять больше ресурсов, чем требуется. В то же время, есть отдельный бесплатный Microsoft Hyper-V Server 2008. Грубо говоря, это тот же Windows Server 2008, только устанавливаемый в режиме Core Services (без морды, с управлением из консоли через ком.строку) и с единственной ролью - Hyper-V. Удаленно, впрочем, он поддерживает подключение по RDP. Из ближайших аналогов - VMware ESX Server. Но надо учесть, что Microsoft его позиционирует как отдельный продукт, а не как версию w2k8, соотв., "upgrade" с Hyper-V Server до w2k8 не поддерживается, но виртуалки с одного на другой перенести, если что, можно без проблем.
PS. На счет стоимости - на домашней страничке Hyper-V Server указаны особенности лицензирования guest OS в сравнении с использованием Windows Server 2008.

[Aleck]

Цитата:

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

Позволю себе небольшое уточнение этого предложения: Windows Server 2008 все-таки стоит денег и, если его использовать сугубо для запуска виртуалок, думаю, сам будет потреблять больше ресурсов, чем требуется. В то же время, есть отдельный бесплатный Microsoft Hyper-V Server 2008. Грубо говоря, это тот же Windows Server 2008, только устанавливаемый в режиме Core Services (без морды, с управлением из консоли через ком.строку) и с единственной ролью - Hyper-V. Удаленно, впрочем, он поддерживает подключение по RDP. Из ближайших аналогов - VMware ESX Server. Но надо учесть, что Microsoft его позиционирует как отдельный продукт, а не как версию w2k8, соотв., "upgrade" с Hyper-V Server до w2k8 не поддерживается, но виртуалки с одного на другой перенести, если что, можно без проблем.
PS. На счет стоимости - на домашней страничке Hyper-V Server указаны особенности лицензирования guest OS в сравнении с использованием Windows Server 2008.

А пробовали Hyper-V? Для виртуализации туда MS Virtual Server встроили?
У меня Virtual Server заметно хуже ресурсы делил, чем vmware, так же все осталось?)

[SHiSHok]

Цитата:

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

я бы рассмотрел (на таком железе) вариант с подниманием Win2008 с ролью Hyper-V
Т.е. созданием кластера AOS'ов в виртуальных машинах. Накладные расходы несколько выше, но появляются интересные сценарии использования.
В новом проекте буду проводить тестирование такого варианта, по результатам отпишусь...

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

[gl00mie]

Цитата:

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

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

Ох, неужели все упирается только в это? В то, что разные AOS'ы "как-то не так" синхронизируют закэшированные данные из таблиц? Ну так в чем же проблема? Возьмите и поменяйте параметры кэширования у "проблемных" в вашем случае таблиц на NotInTTS или даже None. При использовании мощного сервера СУБД зачастую оказывается даже с точки зрения производительности намного выгоднее, чтобы не каждый AOS по отдельности запихивал содержимое таблиц себе в кэш, а та же СУБД просто держала большую или меньшую часть таблиц в памяти, а не на диске. По крайней мере, в случае с Ораклом это работает на ура, и проблема синхронизации кэшей AOS'ов перестает быть сдерживающим фактором на пути увеличения их количества.

[SHiSHok]

Цитата:

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

Ох, неужели все упирается только в это? В то, что разные AOS'ы "как-то не так" синхронизируют закэшированные данные из таблиц? Ну так в чем же проблема? Возьмите и поменяйте параметры кэширования у "проблемных" в вашем случае таблиц на NotInTTS или даже None. При использовании мощного сервера СУБД зачастую оказывается даже с точки зрения производительности намного выгоднее, чтобы не каждый AOS по отдельности запихивал содержимое таблиц себе в кэш, а та же СУБД просто держала большую или меньшую часть таблиц в памяти, а не на диске. По крайней мере, в случае с Ораклом это работает на ура, и проблема синхронизации кэшей AOS'ов перестает быть сдерживающим фактором на пути увеличения их количества.

Идея мне нравится. Я к кешированию таблиц относился с большой осторожностью (все таки стандартный функционал и настройки зрели годами). Обязательно проанализирую возможные изменения.