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

[glibs]

Цитата:

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

...
в чем собственно состоит исчерпывающесть ответа уважаемого petergunn?
...

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

Если нормативно АОСу нужно два процессора (ядра точнее), то проще и дешевле поставить два экземпляра АОСа на один ящик с четырехядерным процессором.

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

Цитата:

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

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

Ну, это ваша частная реальность.

У вас система без модификаций? Ошибок в конфигурации нет? База ухожена? Приложение администрируется адекватно?

Другими словами, вы уверены, что конечная вина в высокой загрузке АОСов лежит в коде стандартной Аксапты? Вы диагностировали проблему (одно из направлений предложил gl00mie в своем предыдущем посте)? Чем обусловлена такая высокая загрузка?

[Lazy_Tiger]

Цитата:

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

Другими словами, вы уверены, что конечная вина в высокой загрузке АОСов лежит в коде стандартной Аксапты? Вы диагностировали проблему (одно из направлений предложил gl00mie в своем предыдущем посте)? Чем обусловлена такая высокая загрузка?

не является это нормой, однозначно.

[egorych]

Цитата:

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

Если нормативно АОСу нужно два процессора (ядра точнее), то проще и дешевле поставить два экземпляра АОСа на один ящик с четырехядерным процессором.

Вот в этом случае у нас имели место проблемы! Т.е. если на 1 машине работает 2 АОСа, то почему-то часто зависали, и вообще сильно хуже работали. При разнесении на 2 РАЗНЫХ машины все нормализовывалось и сейчас работает нормально. Почему - хз, не понятно, возможно это тоже моя частная заморочка, но такое имеет место быть!

[Lazy_Tiger]

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

[Demel]

Цитата:

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

Вот в этом случае у нас имели место проблемы! Т.е. если на 1 машине работает 2 АОСа, то почему-то часто зависали, и вообще сильно хуже работали. При разнесении на 2 РАЗНЫХ машины все нормализовывалось и сейчас работает нормально. Почему - хз, не понятно, возможно это тоже моя частная заморочка, но такое имеет место быть!

Ну не знаю, мы запустили на одном сервере Xeon 3.2 ГГц (4 проца) 4 Гб RAM 3 инстанса АОС, все в аксаптовском кластере (Ax 3.0 SP4 KR3), настроили макс. кол-во памяти и юзеров для каждого. Все работает нормально, относительно стабильно. Проблем с исчерпанием ресурсов АОСа по памяти и юзерам нет, а раньше было. Производительности процов точно хватает, памяти тоже хватает. Работает такая конфигурация уже давно (больше года точно). Мы еще и пакетные сервера (т.е. клиентов Аксапты) умудряемся на нем запускать... В общем, производительность СУБД гораздо важнее - там нужен куда круче сервер. АОСам много не надо. Конечно, в кластере есть свои "перелести" обновления приложения и проблемы с кэшем данных, но это, так сказать, "плата" за масштабируемость

[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.

[SHiSHok]

Цитата:

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

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

Работает порядка 50 юзеров. Анализ загрузки АОСа использую. Функционал у нас можно сказать что стандартный, но серъезно доработанный. Касательно картины загрузки CPU: иногда грузит определенный функционал (тяжелый код, который я выловил и планово переписываю), но и активная работа юзеров (особенно отдела продаж в совокупности со складом) хорошо подгружает. Т.е. нельзя однозначно сказать что вот она гадкая доработка которая грузит.

[SHiSHok]

Цитата:

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

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

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

[SHiSHok]

Цитата:

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

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

Если нормативно АОСу нужно два процессора (ядра точнее), то проще и дешевле поставить два экземпляра АОСа на один ящик с четырехядерным процессором.

Я за 2 АОС-а, но подобная конфигурация имеет неприятную особенность синхронизации кэшей.

Цитата:

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

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

Выделение памяти в рамках приличия я настроил - АОС не превышает 700Mb

Цитата:

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

У вас система без модификаций? Ошибок в конфигурации нет? База ухожена? Приложение администрируется адекватно?
Другими словами, вы уверены, что конечная вина в высокой загрузке АОСов лежит в коде стандартной Аксапты? Чем обусловлена такая высокая загрузка?

Что значит "Ошибок в конфигурации" ?
Модификаций много и пишутся дальше.
Какая База имеется в виду? если SQL, то проблемы загрузки сиквела АОС мало волнуют. Ну и конечно же сиквельные тормоза анализируются и оптимизируются.
вот это тоже хотелось бы расшифровать: "Приложение администрируется адекватно?"

[SHiSHok]

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

[SHiSHok]

Собственно грузануть АОС-ом получилось (class AOSLoadGen).

[fed]

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

[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]

Цитата:

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

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

У некоторых участников как раз были сомнения насчет возможностей АОС. Код класса вычислительной нагрузки конечно примитивный - перебор записей с вычислениями. Сейчас думаю как рабочую нагрузку симулировать, чтоб получить правильный тест. Несколько волнует меня информация о smartHeap от gl00mie.
ЗЫ: может есть рекомендации по настройкам АОСа для достижения максимально эффективной его работы?

[gl00mie]

Цитата:

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

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

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

[SHiSHok]

Цитата:

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

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

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

[SHiSHok]

Тестирование работы Ax3sp3 под управление Win2008 редакций 32 и 64 бит (2xXeonE5420).
Цель тестирования: выбрать наиболее производительную инсталляцию АОС.
Методика тестирования: исполнение N итераций тестовой задачи в разных средах с замером времени выполнения (+ контроль загрузки CPU). Цель тестовой задачи: максимальное использование вычислительных ресурсов АОС с минимальным задействованием SQL.
Реализация: класс выполняющий серию проверок для созданного заказа

ТЕСТ: 500 итераций для заказа из 500 строк.

1. платформа 32bit (x86)
В общем то все закономерно: каждый поток АОС грузит выделенный процессор на полную мощь, т.е. 90%-98%
a) 7 тестовых задач выполнялось 37-39 минут (среднее время 1 итерации 4-5 сек)
б) 14 тестовых задач выполнялось 53-57 минут (среднее время 1 итерации 6-7 сек)
в) 25 тестовых задач выполнялось 1:37-1:44 (среднее время 1 итерации 11-12 сек)
график загрузки будет.

2. платформа 64bit
Первая неприятность - проблемы на этапе установки АОС (internal error и CLSID). Все обновленные файлы перенес ручками в директорию установки. АОС стартанул.
Результаты:
а) 7 тестовых задач выполнилось за время почти в 2 раза большее чем на x86 платформе (среднее время 1 итерации 7-8 сек)
б)
в)

картинка 1 - график загрузки 7 задач (Load7CPUx64.jpg)
не успеваю, посему to be continued...

PS: Может я чего то не знаю про настройку или особенности 64битной ОС, но очень интересно почему процессоры загружены меньше чем наполовину (в 32битном варианте CPU грузятся тестовой задачей по полной)?

[mazzy]

Цитата:

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

PS: Может я чего то не знаю про настройку или особенности 64битной ОС, но очень интересно почему процессоры загружены меньше чем наполовину (в 32битном варианте CPU грузятся тестовой задачей по полной)?

А там нигде hyper Threading не включен?
У вас физически 8 ядер или 4 с включенным HT?

При включенном HT загрузки больше 50% практически никогда не бывает.

[SHiSHok]

Цитата:

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

А там нигде hyper Threading не включен?
У вас физически 8 ядер или 4 с включенным HT?
При включенном HT загрузки больше 50% практически никогда не бывает.

у меня 2 с 4 ядрами : Quad-Core IntelR XeonR Processor 5400 Series
http://www.intel.com/products/proces...5000+tab_specs

[SHiSHok]

Тестирование работы Ax3sp3 под управление Win2008 редакций 32 и 64 бит (2xXeonE5420).
Цель тестирования: выбрать наиболее производительную инсталляцию АОС.
Методика тестирования: исполнение N итераций тестовой задачи в разных средах с замером времени выполнения (+ контроль загрузки CPU).
Цель тестовой задачи: максимальное использование вычислительных ресурсов АОС с минимальным задействованием SQL.
Реализация тестовой задачи: класс выполняющий серию проверок для созданного заказа

ТЕСТ: 500 итераций для заказа из 500 строк.

1. платформа 32bit (x86)
В общем то все закономерно: ОС равномерно распределяет потоки АОС по процессорам и доводит заргузку CPU до максимальной.
a) 7 тестовых задач выполнялось 37-39 минут (среднее время 1 итерации 4-5 сек)


б) 14 тестовых задач выполнялось 53-57 минут (среднее время 1 итерации 6-7 сек)


в) 25 тестовых задач выполнялось 1:37-1:44 (среднее время 1 итерации 11-12 сек)



2. платформа 64bit
Первая неприятность - проблемы на этапе установки АОС (internal error и CLSID). Все обновленные файлы перенес ручками в директорию установки. АОС стартанул.
Результаты:
а) 7 тестовых задач выполнилось за время почти в 2 раза большее чем на x86 платформе 1:17-1:20 (среднее время 1 итерации 8-9 сек)


б) 14 тестовых задач выполнилось 9:52-10:00 (среднее время 1 итерации 71-72 сек). Если честно, то совсем не понимаю почему так медленно. Уровень загрузки CPU как и для 7 тестовых задач, только на всех CPU одинаковый уровень.

в) 25 тестовых задач даже и не запускал

Вывод: для Ax3sp3 наиболее подходящей платформой все таки является родная, 32битная ОС.
В 64 битной платформе так и не удалось достичь максимальной утилизации CPU посредством АОС, плюс проблемы с самим процессом инсталляции компонент, плюс отдельная среда обитания 32битных приложений оставили впечатление неполноценной поддержки 32битных приложений (как бы возможность есть и даже почти все работает).