Bankir.Ru
7 декабря, среда 17:35

Объявление

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

Оптимизация ПРОИЗВОДИТЕЛЬНОСТИ

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

  • Оптимизация ПРОИЗВОДИТЕЛЬНОСТИ

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

  • #2
    Раз начал тему, надо что-то сказать:
    Меня сейчас интерисует мониторинг текущего состояния базы. Хочется знать, кто и чем следит за работоспособностью Афины. Интересует как средства для наблюдения за системными характеристиками (диски, процессора, память, блокировки), так и характеристики самой Афины (скорость обработки документов, скорость выполнения типовых операций.
    Есть что сказать?

    Комментарий


    • #3
      2 Медведев : Для мониторинга Oracle советую обратить внимание на Spotlight от Quest Software (http://www.quest.com/spotlight-portal). А для повседневного наблюдения за активностью юзеров мы написали замену тормозному Афинскому admin.exe - утилита показывает блокировки документов и таблиц, примерно так :
      WBR, Александр Турчин

      Комментарий


      • #4
        2All : Вымерли все пользователи Афины, что ли ?
        WBR, Александр Турчин

        Комментарий


        • #5
          Александр. Spotlight от Quest Software у нас покрутился некое время, штука красивая и полезная, но беда его в том, что он показывает системные характиристики базы. Оно конечно хорошо - наблюдать за блокировками и нагрузкой на диски, но не понятно откуда берется пик чтений, блокировок и т.д. с точки зрения Афинских процессов.
          Я написал небольшую процедурку для сбора внутриафинских показателей типа время потраченное на отчеты, время потраченной на обработку документов, количество обработанных документов и т.д.. Результаты собираются раз в час и хранятся уже два года. Для просмотра использую MathLab. По крайней мере, график скорости обработки документов реально отображает ситуацию, но с дискретностью - час и получается график по требованию.

          Комментарий


          • #6
            но не понятно откуда берется пик чтений, блокировок и т.д. с точки зрения Афинских процессов

            Эт точно. Было бы интересно как-то набрать статистику, от каких процедур наиболее часто происходят блокировки, массовые чтения и т.п. с целью "доточить" эти самые проблемные процедуры. Но вот как это сделать ?
            WBR, Александр Турчин

            Комментарий


            • #7
              В своем варианте, я фиксирую время работы стандартной, частовыполняемой процедуры и объем выполненой работы. Например: загружается поток файлов с документами. В файле может быть от 1 до 4000-5000 документов. Фиксируется суммарное время работы процедуры разбора и обработки файлов и кол-во документов в них. Параллельно запоминаем системные характеристики. Дальше ищем зависимость между скоростью обработки файлов, количеством обработанных документов и изменениями в системных параметрах.
              Потом можно разбивать процесс обработки файла на этапы и запоминать время работы на каждом из этапов.

              Комментарий


              • #8
                А вообще на каком железе у кого это работает? И какова удовлетворенность производительностью на таком железе? чего хотелось бы?
                Интересуют общие показатели кол-во юзров\кол-во документов в месяц....

                Нашел только http://www.athena.ru/athena/Tech.htm, на сколько это кореллируется с реальностью?

                Комментарий


                • #9
                  День добрый. Решил пару строк и я написать.

                  1) А нужно ли вам заниматься производительностью. Если все устраивает или приемлимо, то лучше не тратить время. Просто я не увидел у вас проблему как то ( рейс долго грузится, проценты долго начисляются)

                  2) Если вы все-таки решите ей заняться, то советую обратиться на www.sql.ru в подфорум по Oracle.

                  Комментарий


                  • #10
                    1) А нужно ли вам заниматься производительностью. Если все устраивает или приемлимо, то лучше не тратить время. Просто я не увидел у вас проблему как то ( рейс долго грузится, проценты долго начисляются)

                    Вроде и не нужно, но вот пример: с лета обещают отправлять НДС отдельной платежкой. Что скажет админ?
                    А админ скажет - раз платежей в два раза больше, то докупаем железа.
                    А если подумать, то окажется, что дешевле переписать несколько процедур, чтобы система снова стала удовлетворять требованиям производительности.

                    Еще пример. Я нахожу в базе 4 неиспользуемых индекса по гигу каждый и удаляю их. Вроди ничего не выигрываем. Но с другой стороны на слудующий год дисковых массивов закупать можно меньше. Главное, как можно красочнее описать это начальнику.

                    Комментарий


                    • #11
                      Недавно видел предварительный вариант системы внутриафинского мониторинга от ЗАО "Новая Афина". Сырая пока (на январь 2004), но прикольная штука.
                      Если есть возможность выбить под это деньги, то рекомендую.

                      Комментарий


                      • #12
                        По моим наблюдениям, самая часто блокируемая таблица - Balance. Любое изменение планового или реального остатка блокирует в этой таблице строки.
                        Понятно, если две сессии пытаются изменить остаток по одному счету. Блокировка полезна.
                        Но если все свежие строки с остатками за текущий день лежат в одном или нескольких блоках, то при сильно параллельной работе получаем очень "горячие блоки". За эти блоки идет драка между юзерами.
                        Варианты решения:
                        1 как можно меньше строк в блоке для этой таблицы (PCTFREE 90). Периодически делать ребилд с параметром PCTFREE 0, а затем возвращать в PCTFREE 90.
                        2 Range partitioning по счету. Все счета разбиваются на группы с одинаковым поличеством строк в группе. (новые счета валятся в Default part.)
                        3 В одной из последних версий процедуры создания планового остатка, можно указывать счета, по которым нет необходимости блокировать остаток при пересчете планового остатка (блокировка нужна только для счетов, по которым есть лимит овердрафта и нужно запретить выходить за лимит).
                        4 Index Organaized Table (8 i и выше). Хотя, я пробовал, на нашей системе выигрыша не получил. Но может из за того, что у нас очень мало работающих счетов (меньше 1000).


                        Есть у кого другие предложения???

                        Комментарий


                        • #13
                          Кто нибудь пробовал делать Local Managed Tablespace в Афине?
                          Где это имеет смысл?

                          Комментарий


                          • #14
                            schkoda
                            Сбербанк РФ
                            Две афинские базы на одном сервере.
                            HP Superdome 64Х850Мгц (+ зеркало - точная копия)
                            База 1 размер 360Гб 30тыс плат. документов в день 100 коннектов.
                            База 2 размер 1028Гб 280-350тыс плат. документов в день 100 коннектов. Максимальная производительность 320 документов в час (от загрузки до выгрузки).

                            Комментарий


                            • #15
                              У меня есть такой вопрос. Что есть в НА кол-во документов.. Это все созданные документы в doctree за день или что? Или какие-то определенные категории? Опять же.. кол-во документов в час. У документов несколько состояний и соотетвенно один и тот-же документ м.б. обработан (переведен в состояние) несколько раз в разное время. И как в свете этого оценивать производительность по показателю док/час?

                              Комментарий


                              • #16
                                Сообщение от Медведев К.В.
                                Кто нибудь пробовал делать Local Managed Tablespace в Афине?
                                Где это имеет смысл?
                                Привет Константин.
                                тебе я как-то писал, кажется, по этому поводу. Просто на широкую аудиторию хочу сказать следующее:
                                перевод на локал менеджет оправдан на тех таблицах на которых заведомо известно существование конкуренции при insert/update операциях. как следствие при этом наблюдается наличие событий buffer busy wait& latch free. ( не буду тут размещать скрипты, чтобы определить таблицы вызывающие системные блокировки, их много и их можно найти продукте "Кnowledge Xpert for Oracle Administrator" продукт от quest). поскольку на табличных пространствах с дикшнари менеджмент, используются фри листы и каждый раз идёт обращение к словарю - против битовой матрицы при локал менеджед тейблспейс, при большой конкуренции - производительность должна быть лучше. хотя на деле очень трудно это замерить, поскольку реальную нагрузку на базу, практический нельзя смоделировать. также рекомендую не использовать опцию аутолокейт при создании табличного пространства.
                                Вернее при создании продуктового табличного пространства. А для этого в первый раз, при созданий тестового табличного пространства нужно указать аутолакейт. Затем перенести туда таблицу командой alter table table_name move tablespace New_TS.
                                Затем в dba_extents посмотреть как разрослись размеры экстента у данной таблицы. Они увеличиваются постепенно, нужно смотреть размер последнего экстента. И при создании продуктового табличного пространства в UNIFORM SIZE нужно указать этот максимальный размер.
                                Таким образом я в качестве эксперимента, пока, перевел несколько таблиц и их индексы на Local Managed Tablespace.

                                Комментарий


                                • #17
                                  Tolich
                                  У меня есть такой вопрос. Что есть в НА кол-во документов.. Это все созданные документы в doctree за день или что? Или какие-то определенные категории? Опять же.. кол-во документов в час. У документов несколько состояний и соотетвенно один и тот-же документ м.б. обработан (переведен в состояние) несколько раз в разное время. И как в свете этого оценивать производительность по показателю док/час?

                                  Обычно в каждом тесте понимается по своему. Для приведенных в сообщении Медведева цифр под количеством документов понималось число платежных поручений (переводов из другого банка + переводов в другой банк). То есть реальное число записей в таблице DocTree было раза в три (а то и в четыре) больше (добавляются еще проводки - по одной/две на платежку, занесения/списания из реестра, транспортные сообщения и т.п.).
                                  В большинстве тестов, которые проводились фирмой мерялось число платежных документов (переводы, кассовые оредера и т.п. - грубо говоря число записей в BankOper). Хотя были тесты и на скорость открытия счетов, заведения договоров и т.п. В этом случае мерялось число документов соответствующих категорий.

                                  Комментарий


                                  • #18
                                    Сообщение от Медведев К.В.
                                    По моим наблюдениям, самая часто блокируемая таблица - Balance. Любое изменение планового или реального остатка блокирует в этой таблице строки.
                                    Есть у кого другие предложения???
                                    А про отложенный пересчет остатков что скажете?

                                    Комментарий


                                    • #19
                                      Господа, хотелось бы узнать Ваше мнение по вопросу степени влияния показателей производительности (количество проводок/операций в единицу времени) при выборе АБС для росийских ретейловых Банков (например массовое начисление процентов на ДБП, погашение задолженности и т.д.). Актуален ли вопрос, насколько актуален сейчас и будет ли актуален в будущем. Испытываете ли Вы сейчас данную проблему. Какая производительность устроила бы лично Ваш Банк сейчас и в ближайший год-два.

                                      Комментарий


                                      • #20
                                        Chikov А почему этот вопрос задан в подфоруме "Новая Афина"? Да еще и работником Кворума?

                                        Комментарий


                                        • #21
                                          Афинянин
                                          А почему этот вопрос задан в подфоруме "Новая Афина"? Да еще и работником Кворума?
                                          Доброго времени суток!
                                          Потому что ввиду проблем с заведением новой темы решил продолжить наиболее близко соответствующую... Тем более "Афина" славится своей производительностью (судя по информации на сайте), хотя, как я понимаю, проблемы есть и у ваших клиентов. Можете и опытом поделиться, если не жалко, конечно...

                                          Комментарий


                                          • #22
                                            Chikov
                                            Темы мне не жалко, только вот думаю, что немногие сюда заглянут.
                                            Можете и опытом поделиться, если не жалко, конечно... А что тут делиться? Известно же, что любую работу можно выполнить а) быстро б) дешево в) качественно - выбирайте любые два пункта.
                                            В данном случае не представляет особой проблемы написать систему, которая будет жестко оговоренный функционал исполнять с очень высокой производительностью. При этом удобство работы не пострадает, но такая заказная разработка будет достаточно дорога. Гораздо сложнее (и почти невозможно) сделать высокопроизводительный универсальный механизм, который можно будет относительно недорого продавать и быстро настраивать под меняющиеся требования.
                                            Афина - достаточно универсальная система, поэтому и в ней не все места достаточно быстры. Особенно это касается тех случаев, когда в процессе внедрения идет адаптация по специфические требования банка. В этих случаях и автоматизаторы банка и наши внедренцы не всегда выбирают наиболее производительные способы решения задач.
                                            Некоторое преимущество Афины в том, что уже накоплен некоторый опыт оптимизации (которая выполнялась по специальным заказам), ну и естественно, что этот опыт использован для оптимизации ключевых операций в общем ядре системы.

                                            Комментарий


                                            • #23
                                              2Chikov : при выборе АБС для росийских ретейловых Банков

                                              В лучших домах ЛондОна ретейловую подсистему выносят за рамки традиционной АБС. По крайней мере, в случае большого объёма ритейловых операций. Может, это утверждение и спорно, однако такая практика в exUSSR широко распространена.
                                              WBR, Александр Турчин

                                              Комментарий


                                              • #24
                                                Я думаю, что Вам не удастся оптимизировать работу Афины. По следующим причинам:
                                                1. Вы не сможете оптимально настроить сервер БД (если интересно станет, то объясню почему)
                                                2. Вы не сможете оптимально переписать все, что отрабатывает на сервере БД
                                                3. Вы не сможете переписать то, что навояли в своих приблудах разработчики
                                                4. Вы не в силах поменять примененые технологи

                                                и т.д. и т.п. А ведь оптимизация - это именно ЭТО!

                                                Комментарий


                                                • #25
                                                  Да, Энциклопедия, сначала господин Chikov на Первое апреля решил озадачить конкурентов вопросом. Теперь еще Вы, но сегодня хоть пятница...
                                                  Вы кому отвечали-то ? Кто не сможет оптимизировать работу Афины ?
                                                  Chikov, Афинянин, Александр_Турчин ???

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

                                                  Комментарий


                                                  • #26
                                                    2Энциклопедия : Вы не сможете...

                                                    М.б. Вы, уважаемый Энциклопедия, и не сможете всё это сделать. Однако не надо говорить на форуме от лица всех - некоррЭктно как-то получается с Вашей стороны.
                                                    WBR, Александр Турчин

                                                    Комментарий


                                                    • #27
                                                      Ребята, советую Вам почитать Тома Кайта, документацию Oracle, выснить, как программситы Афины там напрограммировали - открытые коды у них взять, как для клиентской части, так и серверной. Да, схему данных не забудьте у них попросить. Вот только после этого можете начать оптимизацию работы. Я так понял производительность у Вас не та, о которой Вы мечтаете. Кстати, условия Вашего бизнеса тоже влияют на многое... Так что всё в Ваших руках!

                                                      Комментарий


                                                      • #28
                                                        Что к4асается вот этого "Вы не в силах поменять примененые технологи", то все тут нормально - читайте литературу и Вы в этом убедитесь. Примеры приводить не буду.

                                                        Комментарий


                                                        • #29
                                                          Энциклопедия
                                                          Откуда такое настойчивое желание написать всюду даже не читая сообщений других участников? Неужели так интересно быть "в каждой бочке затычкой"?
                                                          Я так понял производительность у Вас не та, о которой Вы мечтаете. Кто из участников обсуждения здесь жаловался на производительность?

                                                          Комментарий


                                                          • #30
                                                            Афинянин, тема называется НАСТРОЙКА ПРОИЗВОДИТЕЛЬНОСТИ.

                                                            1. "Меня сейчас интерисует мониторинг текущего состояния базы. Хочется знать, кто и чем следит за работоспособностью Афины." Это цитата. Не зная Oracle следи хоть заследись... все равно толку не будет никакого.

                                                            Мой ответ:
                                                            1. Вы не сможете оптимально настроить сервер БД (если интересно станет, то объясню почему)
                                                            2. Вы не сможете оптимально переписать все, что отрабатывает на сервере БД
                                                            3. Вы не сможете переписать то, что навояли в своих приблудах разработчики
                                                            4. Вы не в силах поменять примененые технологи

                                                            2. "так и характеристики самой Афины (скорость обработки документов, скорость выполнения типовых операций."

                                                            Мой ответ:
                                                            1. Вы не сможете оптимально настроить сервер БД (если интересно станет, то объясню почему)
                                                            2. Вы не сможете оптимально переписать все, что отрабатывает на сервере БД
                                                            3. Вы не сможете переписать то, что навояли в своих приблудах разработчики
                                                            4. Вы не в силах поменять примененые технологи



                                                            Что не так? Или продолжить? Знатоки блин...

                                                            Я согласен, что ускорить что-то можно будет, но только ощуите это, если владеть информацией будете, а вы ей не владеете. Oracle не знаете, систему не программировали, базу не проектировали.... Как собираетесь оптимизацию ничего не делая проводить...??? Лично я не понимаю! Можно конечно поиграться параметрами, наверное, но, а смысл Глобальный думаете будет в этом.... Я думаю, что не особо!

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X