Тестирование производительности АОС (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-ю платформу с несколькими экземплярами АОС.

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

[sukhanchik]

Цитата:

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

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

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

[SHiSHok]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

[SHiSHok]

Цитата:

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

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

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