Тестирование производительности АОС (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), настроили макс. кол-во памяти и юзеров для каждого. Все работает нормально, относительно стабильно. Проблем с исчерпанием ресурсов АОСа по памяти и юзерам нет, а раньше было. Производительности процов точно хватает, памяти тоже хватает. Работает такая конфигурация уже давно (больше года точно). Мы еще и пакетные сервера (т.е. клиентов Аксапты) умудряемся на нем запускать... В общем, производительность СУБД гораздо важнее - там нужен куда круче сервер. АОСам много не надо. Конечно, в кластере есть свои "перелести" обновления приложения и проблемы с кэшем данных, но это, так сказать, "плата" за масштабируемость

[SHiSHok]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[SHiSHok]

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

[SHiSHok]

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

[fed]

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

[SHiSHok]

Цитата:

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

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

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

[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битных приложений (как бы возможность есть и даже почти все работает).

[gl00mie]

Цитата:

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

Тестирование работы Ax3sp3 под управление Win2008 редакций 32 и 64 бит (2xXeonE5420).
1. платформа 32bit (x86)
a) 7 тестовых задач выполнялось 37-39 минут (среднее время 1 итерации 4-5 сек)
б) 14 тестовых задач выполнялось 53-57 минут (среднее время 1 итерации 6-7 сек)
в) 25 тестовых задач выполнялось 1:37-1:44 (среднее время 1 итерации 11-12 сек)
2. платформа 64bit
а) 7 тестовых задач выполнилось за время почти в 2 раза большее чем на x86 платформе 1:17-1:20 (среднее время 1 итерации 8-9 сек)
б) 14 тестовых задач выполнилось 9:52-10:00 (среднее время 1 итерации 71-72 сек). Если честно, то совсем не понимаю почему так медленно. Уровень загрузки CPU как и для 7 тестовых задач, только на всех CPU одинаковый уровень.
в) 25 тестовых задач даже и не запускал

Вообще, было бы интереснее посмотреть графики загрузки ЦП с включенным крыжом Show kernel times, чтобы хоть примерно представлять себе, сколько процессорного времени тратит сам AOS, а сколько - система, API которой в т.ч. AOS вызывает. Весьма вероятно, что в случае платформы x64 время, затрачиваемое ядром, было существенно выше, и AOS просто "ждал ответа" от системы - поэтому и не мог загрузить процессоры полностью. Если это так, то более детальное тестирование стоило бы проводить с привлечением Performance Monitor, чтоб точнее понять, на что именно уходило время, было ли больше переключений контекста в случае платформы x64, были ли длиннее дисковые очереди, etc. А так, выходит, что на x64 AOS просто упирался во что-то, не являющееся процессором Причиной ли тому сама 64-разрядная ОСь - большой вопрос, может, какие-нить используемые драйверы под x64 оказались более кривыми, чем под x86...