Сколько сессий выдержит ваш сервер с Oracle Database?

Ведь очень важно знать: какое максимальное число пользователей смогут одновременно подключится к вашей БД ?

Конечно: все зависит от нагрузки создаваемой прикладным приложением, но вопрос хороший!

На днях мне пришлось участвовать в проекте, и заказчик потребовал чтобы СУБД могла одновременно обслуживать 2500 пользователей.
И перед запуском прикладных тестов нужно было убедиться, что СУБД в принципе способна выдержать такое количество сессий.

Это не такая простая задача, как может показаться на первый взгляд: потребовалось изменение нескольких параметров и тонкая настройка листенера для его защиты от "шторма" сессий. В этой работе очень помогла утилита LoadBalance.

Первоначально эту утилиту я разрабатывал для тестирования балансировки в RAC, но оказалось что у нее есть применения и для Single Instance.
Тестирование проводилось на 8-ми процессорном сервере HP DL785 с 4-х ядерными процессорами AMD на борту и с 64 Гб памяти. Какая была операционная система? - Это был ... MS Windows 2008 x64.

Ну а теперь можно назвать и приложение - это было "1С:Предприятие" !
:-)

20 комментариев:

  1. Анонимный31/12/09 11:19 AM

    Пора писать книгу или хотя бы брошюру по миграции с OEBS на 1С на платформе Oracle Database. А для буржуев назвать OEBS 2010 Russian Edition!!!

    ОтветитьУдалить
  2. Безумству храбрых поем мы песню...

    ОтветитьУдалить
  3. Анонимный31/12/09 6:25 PM

    Господи боже!!! Все думают что 1с будет работать если его под Oracle продавать?! Вот уж действительно нескончаема людская вера в маркетинг:) Вместо то того чтобы после выпуска пресс релиза о 1С+Oracle наконец то понять что 1с ни ERP ни разу, и не работает(из пресс релиза следует) люди таки решили в очередной раз набить себе шишку. Да здравствует маркетинг!!!

    ОтветитьУдалить
  4. Анонимный31/12/09 8:12 PM

    >> Господи боже

    Расскажите, пожалуйста, поподробнее почему 1С не работает. Похоже, что у Вас есть опыт работы с 1С и Вам действительно есть что сказать. И почему "1С не ERP"?

    Я в свое время много внедрял OEBS, но у меня нет никакого опыта с 1С. Я только слышал о том, что 1С практически захватили весь low end сегмент рынка, в основном за счет того, что у них все работает "из коробки" и ничего не надо настраивать/внедрять.

    Мне кажется, что поддержка ими СУБД Oracle является частью их стратегии по выходу на более крупные рынки,где традиционно тусуются Axapta, SAP, OEBS и др. Я так понимаю, что под "верой в маркетинг" Вы имели в виду тот факт, что поддержка новой СУБД не добавит им функциональности, которая уже есть у ERP систем более высокого ценового уровня. Или я не так понял?

    P.S. Еще раз всех с Новым 2010 годом!

    ОтветитьУдалить
  5. Евгений1/1/10 11:35 AM

    Игорь,
    Большое спасибо за интересный пост.Не могли ли бы вы уточнить какую версию базы вы использовали и какую конфигурацию листнера(скорее всего это был Shared)?
    Так же во время тестя проводили ли пользователи какие либо транзакции?

    Спасибо

    ОтветитьУдалить
  6. Использовалась версия 10.2.0.4 + Bundle 30

    СУБД работала в dedicated режиме. Сам бизнес-тесты (и соответственно транзакции) проводились через "1С Тест-Центр"

    ОтветитьУдалить
  7. Анонимный1/1/10 6:19 PM

    Для такого количества dedicated сессий в Windows, как раз было неплохо продемонстрировать возможности RAC по наращиванию PGA на более скромном( хотя, желательно,тоже 64-разрядном железе). А против 1С те, кто зарабатывает на OEBS, который вприходится с треском (и за большие деньги) втискивать в российский бухучет. В отличие 1С, который под него заточен.
    С Новым Годом!

    ОтветитьУдалить
  8. Анонимный2/1/10 1:33 AM

    С Новым 2010 Годом!
    Сергей я попробую аргументировать свою позицию про маркетинг и про то что именно не работает. Опыт работы/внедрения 1с имеется в не очень маленьких проектах(ритейл).
    Любая система для бизнеса автоматизирует некие бизнес процессы. Для этого в системах имеется базовая бизнес логика, которая с программной точки зрения представлена в виде неких примитивов: таблиц, объектов, процедур, функций, пакетов. А уже на базе этих примитивов, производится высокоуровневое программирование бизнес-логики под потребности проекта.
    При этом чем более система универсальна, в частности не зависима от СУБД, тем меньше возможностей СУБД она использует, возможностей оптимизации в частности. В результате СУБД рассматривается в большей степени как "свалка" данных, а при попытке работать с корпоративными объемами такое отношение к возможностям СУБД выливается долгие часы ожидания на определенных операциях. Причем это относиться как к 1с так и к SAP и прочему. Но здесь есть одно но, которое заключается в том, какой путь прошли компании вместе СУБД Oracle. Скажем SAP и 1с. У SAP например при всех тех же недостатках есть большое преимущество - опыт разработки внедрения и поддержки решений на Oracle. Что есть у 1с, не очень долгий путь перевода платформы на Oracle. Несколько лет назад не последние люди в 1с заявляли - зачем Oracle, у нас есть все что нужно MSSQL, Postgres, пишите под 1С! На данном этапе можно на вполне законных основаниях утверждать, что ни опыта серьезной оптимизации под СУБД Oracle, ни опыта поддержки своих решений под Oracle у компании 1С нет. Хороших Oracle'оидов на рынке не много.
    Логика действий очень проста "ни одно наше решение не тянет работу на объемах данных которые возникают в корпоративных системах значит надо дать понять бизнесу что у нас серьезное решение". А дальше все еще проще - пишем слово Oracle, все знают что это серьезно и по взрослому, значит будут брать.
    В пресс релизе 1с говорилось "Поддержка СУБД Oracle Database", читаем - теперь вы можете держать свою "свалку" под Oracle, потому что это серьезно, по-взрослому - это Enterprise. Хотя в том же пресс релизе есть слова оптимизация работы с базой и оптимизация получения агрегатов, но в реальности заточкой системы под Oracle и не пахнет. Вот почему "Да здравствует маркетинг!".

    ОтветитьУдалить
  9. Анонимный2/1/10 2:47 PM

    Спасибо. Очень интересный анализ.

    ОтветитьУдалить
  10. Да какой тут анализ, тут и анализировать нечего, очевидные же вещи. Стандартный trade of универсальности на производительность.

    ОтветитьУдалить
  11. Анонимный2/1/10 5:30 PM

    смотрим на картинку

    http://v8.1c.ru/overview/Term_000000135.htm
    и понимаем - что писать "оптимизированный" софт под Оракл - незачем - вся нагрузка на серверах приложений.

    уж лучше 1С чем OёBS

    ОтветитьУдалить
  12. Анонимный2/1/10 7:12 PM

    После адаптации OEBS для российских потребителей, он как раз и превращается в свалку данных в текстовых дополнительных атрибутах, что трудно назвать оптимизацией под Oracle.

    ОтветитьУдалить
  13. >вся нагрузка на серверах приложений
    Осталось только надеяться, что инженеры 1С создали продукт, который масштабируется не хуже, чем Оракл:))

    ОтветитьУдалить
  14. Анонимный3/1/10 1:06 AM

    Ну и каковы результаты тестирования? Я и без этих результатов скажу, что на 2500 пользователей - ни памяти, ни процов не достаточно, даже при самом скупом и нищебродском расчете.

    Для ораторов выше, про 1С и OEBS. Зачем крайности? Миделваре - наше все. Пускай работает 1С и OEBS на одном предприятии друг друга дополняя.

    ОтветитьУдалить
  15. >> "Ну и каковы результаты тестирования?"

    К сожалению, формат блога не позволяет мне приводить здесь результаты тестирования. Чтобы их получить вам нужно официально обратиться в Oracle или в 1C.
    Одно могу сказать точно: вышеописанного сервера для СУБД было вполне достаточно для получения положительных итогов тестирования !

    >> "Я и без этих результатов скажу, что на 2500 пользователей - ни памяти, ни процов не достаточно ..."

    С чего Вы это взяли? Видимо у Вас есть магический кристальный шар ... :-)

    1C работает в трех-звенной архитектуре и вся бизнес-логика выполняется на сервере приложений, СУБД лишь играет роль механизма хранения данных. В тестировании использовалось несколько серверов приложений (4-х процессорных) объединенных в кластер (у 1С есть свой кластер), плюс серверы -балансировщики нагрузки.

    Дополнительно к этому: сессии к СУБД идут через пул соединений, который совместно используют все клиентские приложения 1С.

    Я не разделяю таких ваших однозначных выводов ...
    :-)

    ОтветитьУдалить
  16. Анонимный5/1/10 11:00 PM

    2 Blogger Igor Melnikov:

    Так что тогда тестировалось? Пользовательская нагрузка на "кластер 1С" или какую нагрузку дает этот кластер на сервер БД?

    Я конечно не особо знаком с трехзвенной архитектурой 1С, но есть предположение, что если 2500 пользователей одновременно захотят сделать выборку из какого-нибудь одного справочника, к базе данных будут применены одновременно 2500 селектов... и бобик сдохнет.

    ОтветитьУдалить
  17. Тестировалось время выполнения всей системой (СУБД + приложение) нескольких бизнес-операций, критерии времени выполнения которых были заданы заказчиком.

    1C - это OLTP-приложение, то есть в нем в основном преобладают короткие и быстрые операции чтения-записи. Основное время в таких системах тратиться на ожидание ввода информации от пользователей. Конечно, существует вероятность того, что по сигналу стартового пистолета все 2500 пользователей одновременно нажмут кнопку "Провести счет-фактуру". :-)

    Как сами понимаете, вероятность такого события ничтожно мала !

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

    ОтветитьУдалить
  18. Анонимный15/2/10 10:29 PM

    А если не секрет, то при тестировании имитировался ввод пользователями каких именно документов 1С? С какой скоростью вводились документы отдельным пользователем? Пересекались ли данные, в документах одного вида, вводимых разными пользователями? Спасибо заранее за ответ.

    ОтветитьУдалить
  19. Анонимный13/2/12 5:08 PM

    "к базе данных будут применены одновременно 2500 селектов... и бобик сдохнет"
    Бобик с именем НЕ сдохнет. А вот "кластеры серверов приложений 1C" - однозначно. Знаю реализацию системы с активными в течение часа 1500 юзеров на Oracle с операциями и рассчетами посложнее проводочек 1C - всё отлично жужжит через WEB на обычном двухпроцессорном сервере Intel x86-64 (16 потоков) с жалкими 16 ГБ памяти и 2 ТБ базой (правда, на дисковом массиве через FiberChanel). Т.е. ВСЁ на этом сервере крутится(и инстанс базы, и Apache).

    ОтветитьУдалить
  20. Анонимный19/10/12 5:39 PM

    Опять 1С "золотым молотком ржавые гвозди забивает" (истольует RDBMS как помойку данных, без бизнес-логики).

    ОтветитьУдалить