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

[glibs]

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

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

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

[SHiSHok]

Цитата:

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

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

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

[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, то проблемы загрузки сиквела АОС мало волнуют. Ну и конечно же сиквельные тормоза анализируются и оптимизируются.
вот это тоже хотелось бы расшифровать: "Приложение администрируется адекватно?"