12 июля, воскресенье 08:56
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Производительность Базы, Сервера

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Производительность Базы, Сервера

    Добрый день господа!

    SUSE Linux Enterprise Server 11 SP2 (x86_64)
    OpenEdge Release 10.2B07
    Лицензия WorkGroup

    Хотел поинтересоваться по производительности
    по мере апгрейда сервера выяснилось, что увеличение производительности железа не даёт соответствующего прироста в производительности работы.
    На данный момент сервер:
    IBM System x3550 M4
    2 x XeonDP 6C E5-2620 2.0GHz
    8x8GB PC3L-10600 ECC DDR3 RDIMM
    База 25Gb на IBM System Storage DS3524 подключёном по SAS

    Смена статусов 100 документов занимает в среднем 150 секунд.
    Файлы выписок для ДБО BCC - 4000 шт. формируются в среднем за 200 секунд.

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

    Общались с поддержкой прогресса, путём настройки разных параметров долидись увеличения производительносит процентов на 10. Всё сводилось в конечном итого к словам - "у вас софт не оптимизирован", и понятно, что бисквитовцы ничего менять не будут, отговариваясь словами что у всех так работает.

    Коллеги, поделитесь, у кого какие конфигурации и какие показатели производительности? Нормальна ли такая картина как у нас ?

  • #2
    Конкретно про БИС не скажу, у нас другая система, но тоже на OpenEdge.
    на всякий случай эту статью читали: http://www.openedge.ru/read/202/ ?

    Вот мой опыт и некоторые советы по этой теме:

    1. Прогресс очень любит память, а точнее свой основной буфер (параметр -B) доведите его до размера >= БД (память позволяет) 32 ГБ самое то,
    (значение этого параметра задается в страницах а не в байтах) - это главный источник "ускорения"

    2. Обязательно использовать процессы APW (хотябы 2 шт), BIW

    3. Если используется Auto-Image (если нет - то желательно озаботиться, облегчает резервное копирование и уменьшает время перехода на резерв) то во первых его нужно размещать на отдельных дисках, во вторых нужно использовать AIW (хотя эта фича вроде доступна только в Enterprise)

    4. Если БИС работает в текстовом режиме (не QBIS), то клиентские сессии нужно подключать как SELF (т.е. не использовать -N TCP) через TCP/IP производительность падает многократно... (это второй ускоряющий фактор, правда не всегда осуществимый)

    5. Базу размещать на RAID10 (лучше всего) или RAID1 (но только не RAID0/RAID5 )

    6. (Задание со звездочкой ) Использовать отдельные области БД под разные задачи с размещением их на отдельных дисках. Т.е. например если у вас есть таблица с документами и вы знаете, что она активно растет и меняется каждый день ее можно вынести в отдельную область (лучше типа II, правильно рассчитав ее параметры, зная среднюю длину записи)

    Ну и общесистемные советы: под разделы с БД использовать только ФС ext2/ext3
    планировщик ввода/вывода Progress рекомендует использовать deadline и действительно - многопользовательсая работа с ним намного плавнее (для RHEL4/5)
    перейдя на RHEL6 оставил cfq по умолчанию, т.к. справляется - они его здорово допилили. Не знаю как с этим у SLES

    Как попробовать найти в чем затык в базе (в основном совет для процессов пишущих в базу):
    перед запуском вашего теста ("Смена статусов 100 документов") запускаете
    promon имя_базы
    дальше выбираете пункт 5. (Activity)

    запускаете ваш тест, ждете его окончания
    нажимаете в promon клавишу Ener - он покажет статистику за этот период (т.е. от момента его запуска до нажатия enter)
    смотрите внимательно на параметры
    Record Waits
    Rec Lock waits
    BI Buf waits
    AI buf waits

    все эти значения должны быть около 0
    если они все = 0, а работает медленно значит проблема по чтению,
    и если пункты 1-4 описанные выше выполняются и диски быстрые (скорость линейного чтения с раздела БД > 100MB/s)
    то вероятно. имеют место неоптимальные запросы/алгоритмы и это уже не совсем задача администратора

    Да и замеры времени нужно проводить 2-3 раза подряд - нужно дать Прогресу время заполнить свой буфер, база с холодного старта обязательно будет тупить
    т.к. буфер пустой

    Комментарий


    • #3
      Статью читал, спасибо!
      Буфер попробую увеличит ещё.

      Есть ли люди кто пользуется бисквиом? у кого какая скорость обработки/смены статуса ?

      Комментарий


      • #4
        Сколько у вас открытых дней? Чем больше дней открыто, тем медленнее считаются остатки по счетам, тем медленнее проводятся проводки, особенно по коррсчету.

        Комментарий


        • #5
          Сообщение от mrbes Посмотреть сообщение
          Статью читал, спасибо!
          Буфер попробую увеличит ещё.

          Есть ли люди кто пользуется бисквиом? у кого какая скорость обработки/смены статуса ?
          Из предыдущего поста: "2. Обязательно использовать процессы APW (хотябы 2 шт), BIW"
          По-моему не запускаются на версии workgroup.
          Есть такая известная идея: разместить bi-файл на отдельном диске (несетевом) . Увеличивает скорость, так как распараллеливаются задачи записи и чтения с диска.

          Комментарий

          500 Портал временно недоступен

          Портал временно недоступен

          Возникла ошибка при открытии страницы. Обновите страницу или перейдите на главную
          Обновите страницу спустя некоторое время.

          Агенство Bankir.Ru приносит извинения пользователям
          за доставленные неудобства
          Обработка...
          X