Реальная производительность системы


Главная Форумы IBM i (OS/400) Реальная производительность системы

В этой теме 24 ответа, 8 участников, последнее обновление  Jevgeni Astanovski 7 года/лет назад.

  • Автор
    Сообщения
  • #10221

    Jevgeni Astanovski
    Участник

    Коллеги,
    если кто не знает, то наша маленькая, но гордая держава 1 января 2011 переходит на новую валюту.
    Ну и в связи с этим, естественно, маразм крепчает.
    Ясный пень, деньги надо сконвертировать из старой валюты в новую. Конечно не только, но это — всяко.
    По этому поводу непричастные к технической стороне вопроса от нечего делать затеяли меряться п..сками.
    Значить, у кого длиньше? То есть кто быстрее сконвертирует.
    Захлестывает.
    И один «наш» (шведский) банк сказал из телевизора, что у них весь процесс занимает 18 минут. А участвуют в нем 300 (триста) человек.
    Комментировать желания нет, но возник профессиональный вопрос.
    Мы уже провели 3 теста конвертации остатков.
    Средняя скорость конвертации — 50 счетов в секунду. Внутри этого времени выборка очередного счета в «старой» валюте, нахождение принадлежащего этому же клиенту счета в новой валюте, вычисление эквивалента суммы в новой валюте, вызов ITA API для формирования соответствующих проводок.

    Речь идет об Equation, если кто не понял.B)

    Мне не слишком интерены комментарии по поводу оптимальности/неоптимальности.
    Я точно не знаю, какая у нас машина (это agent знает), но думаю что на уровне P10.
    А интересует меня вот что: до каких высот может подняться это число (50 конвертов/секунду) на «взрослых машинах»?
    Есть ли у кого-то РЕАЛЬНЫЕ СРАВНИМЫЕ оценки? Будет ли это больше моего числа в 10 раз или вовсе в 100?
    Очень интересно…

  • #10222

    Oldnick
    Участник

    как я понимаю, есть некий job, который у вас работает с такой-то скоростью (в среде EQ).
    требуется выяснить как быстро будет работать этот job, например, у нас.
    уверен, что вопрос надо адресовать тем, кто работает с похожими job’ами. лично я не работаю с ними и не могу сказать как быстро это будет. скорость его работы зависит от многих факторов. машина, процессоры, память, ввод/вывод, параллельная обработка…
    думаю, специалисты в этой области у нас могут на вскидку ответить на этот вопрос. но к сожалению они этот форум не читают…

  • #10223

    Jevgeni Astanovski
    Участник

    думаю, специалисты в этой области у нас могут на вскидку ответить на этот вопрос. но к сожалению они этот форум не читают…

    К сожалению!
    А нельзя у них спросить? 🙂

  • #10224

    Demetrio
    Участник

    Не эксперт в области банковских технологий, но логика подсказывает, что даже увеличив процессорные мощности, скорость обработки счетов останется таже. Все упирается в скорость поступления данных и сохранения данных, а арифметически процессор перелапатить может и тысячи счетов за секунду, вы же не гидродинамические процессы обсчитываете.
    Копайте в сторону увеличение скорости получения запросов sql базы всеми возможными методами.

  • #10225

    Sever
    Участник

    Мне не слишком интерены комментарии по поводу оптимальности/неоптимальности.
    Я точно не знаю, какая у нас машина (это agent знает), но думаю что на уровне P10.
    А интересует меня вот что: до каких высот может подняться это число (50 конвертов/секунду) на «взрослых машинах»?
    Есть ли у кого-то РЕАЛЬНЫЕ СРАВНИМЫЕ оценки? Будет ли это больше моего числа в 10 раз или вовсе в 100?
    Очень интересно…

    Реальных оценок нет.
    IMHO производительность EQ для таких глобальных изменений можно существенно увеличить только с увеличением в разы числа процессоров, объема ОП, дисковой подсистемы и использованием многопоточности из расчета 2 потока обработки на ядро.
    Мы работаем на системе с 32мя ядрами 5Ггц, ОП около терабайта, дисковая — около 40Тб, которая состоит из 20Тб на зеркале на скази + 20 Тб на двух DS8K с десятым рейдом. Все это одна партиция с одним ASP. И нам этого мало 😆

  • #10227

    Jevgeni Astanovski
    Участник

    Товарищи,
    если Вы прочитаете мой пост, то я там не задавал вопрос о том, как оптимизировать работу задачи.
    Нас вполне устраивает скорость (50 в среднем, 90 — пиковая).

    Мне было интересно, возрастет ли она с ростом CPW машины.

    Если я правильно понял, то Север считает, что не возрастет если не перейти на многопоточность. В тривиальном варианте — просто запустить больше одного «конвертера».
    Пожалуй я готов согласиться, так как это звучит вполне логично. А сейчас конвертация у меня идет в один поток.

    И это значит, что на 4-х ядерной машине можно было бы запустить 8 потоков и это, возможно, дало бы 5-6 кратное ускорение.
    На самом деле я обдумывал параллельные джобы но отказался от этой идеи…

  • #10228

    Jevgeni Astanovski
    Участник

    Все это одна партиция с одним ASP. И нам этого мало 😆

    Дайте мне лекарство от жадности!
    Мно-о-о-го!!!
    :laugh:

  • #10230

    Sever
    Участник

    Захлестывает.
    И один «наш» (шведский) банк сказал из телевизора, что у них весь процесс занимает 18 минут. А участвуют в нем 300 (триста) человек.

    Пример правильного и грамотного пиара.
    Хорошее обоснование для занятости 300 сотрудников.

  • #10231

    Григорий
    Участник

    Мы работаем на системе с 32мя ядрами 5Ггц, ОП около терабайта, дисковая — около 40Тб, которая состоит из 20Тб на зеркале на скази + 20 Тб на двух DS8K с десятым рейдом. Все это одна партиция с одним ASP. И нам этого мало 😆

    *пускает слюни*

  • #10239

    Сергей
    Участник

    Хорошо живут у вас шведы 😉

    300 шведов = 1 нормальный программист и 1 технолог для постановки?

    Про ITA не помню, а вот PMC, в аналогичной по структуре задаче, на нашей 890-ой с 16 процами (EQ 3.40, V5R2M0) минут за 20 полностью исчерпывает лимит SAPSQ (т.е. 99999). это около 80 операций в секунду.
    На 570-ой прогресс конечно есть, но не настолько существенный, как можно было бы ожидать.

    Попугаи, ОЗУ и прочие предметы зависти здесь конечно важны, но не первичны.

    Когда у нас встала проблема с ежемесячными комиссиями, которые работали более 2-ух часов, то модификацией кода и распаралеливанием процесса удалось уменьшить время почти в двое, можно было уменьшить еще, но уже сложнее с программированием.

    Еще пример — патч от MiSys на закрытие дня удлинил его время в 1,5 раза, но устранил ошибку.

  • #10242

    Jevgeni Astanovski
    Участник

    Хорошо живут у вас шведы 😉

    300 шведов = 1 нормальный программист и 1 технолог для постановки?

    Шведы, наверное, живут хорошо. Только не всегда в шведском банке шведы работают B)
    В данном конкретном случае речь идет об эстонцах.

    Что касается остального.
    По всей видимости, программистам там места нет. Занимаются такими вещами все-таки администраторы, у нас по крайней мере. И программистов будут держать примерно на расстоянии пушечного выстрела 😛

    80 PMC в секунду это примерно наша скорость с одного процессора (пиковая у нас 90), а значит остальные 15 спокойно курят в отдалении. Хотя 890 — это довольно старая машина?
    Я согласен с Севером по поводу параллельности, как единственного способа повысить скорость. Но уж очень в лом заниматься распараллеливанием для задачи, которая в живье отработает только 1 раз…

  • #10243

    pre
    Участник

    Мы уже провели 3 теста конвертации остатков.

    Интересно было бы приложить журналы полученые во время такого теста и посмотреть какой overhead самого конвертора. Очень стимулирует программерскую мысль, поверьте.
    Увеличится ли скорость на машине побыстрее зависит от того, где в конкретном случае узкое место. Может процессор ждёт IO, может открытие-закрытие файлов избыточное, да много чего может быть. В первом случае многопоточность может помочь.

  • #10244

    Сергей
    Участник

    Хотя 890 — это довольно старая машина?

    угу, старая, а 570 новая и процы 6+ и ресурсов всяческих больше … а результат, фактически, тот же.

    можно еще ОЗУ дорастить, можно SSD поставить вместо HDD, и это даст результат — может процентов на 10-15 эта операция и пройдет быстрее.

    если говорить про EQ, то основной ресурс — оптимизация кода.

    Пример не в тему, но показателен, — тот объем операций по сделкам, что на «мостике» в EQ 3.40, обрабатывается часами, на EQ 3.82, без «мостика», пролетает в секунды.

  • #10245

    Jevgeni Astanovski
    Участник

    Интересно было бы приложить журналы полученые во время такого теста и посмотреть какой overhead самого конвертора. Очень стимулирует программерскую мысль, поверьте.
    Увеличится ли скорость на машине побыстрее зависит от того, где в конкретном случае узкое место. Может процессор ждёт IO, может открытие-закрытие файлов избыточное, да много чего может быть. В первом случае многопоточность может помочь.

    Приложение журнала не показатель. Там еще куча логики в программе. Надо взять старый счет, определить его остаток, если больше минимума — сконвертировать сумму, найти счет в новой валюте — и только после этого — выполнить ITA.
    По поводу теории — это я все знаю, не первый год, и не десятый даже:)
    Вопрос был практический…

  • #10247

    Jevgeni Astanovski
    Участник

    Пример не в тему, но показателен, — тот объем операций по сделкам, что на «мостике» в EQ 3.40, обрабатывается часами, на EQ 3.82, без «мостика», пролетает в секунды.

    Ну и память! Это ##_FX_MM?
    Больная хреновина была, но как давно! Мне уже даже не вспомнить, когда он исчез.
    По-моему на 3.41 его уже не было…
    Или я ошибаюсь…
    :blink:

  • #10248

    Oldnick
    Участник

    fx_mm был еще на 342

  • #10249

    Сергей
    Участник

    Ну и память! Это ##_FX_MM?

    угу, он.
    да, память ничего, только вот мы до сих пор на 3.40 сидим 😉
    и если ничего не путаю, то мостик исчез только в 3.60, а до того, транзакционность на уровне БД они и не пытались использовать.

    Приложение журнала не показатель.

    Почему? как раз таки и показатель, как кривая прога может потребовать увеличения ресурсов в РАЗЫ, чтобы получить прирост в 15%

  • #10250

    pre
    Участник

    Боже! Дай мне разум и душевный покой принять то, что я не в силах изменить, мужество изменить то, что могу, и мудрость отличить одно от другого.

    Обычно тесты с приложением журналов помогают отличить то, что мы в силах изменить, от того, что следует принять, как данность.B)

  • #10283

    Jevgeni Astanovski
    Участник

    Поскольку до 1 января время осталось, а все в целом сделано, то решил попробовать оптимизнуть.
    Заодно проверить версию Севера по поводу ядер.
    Там у меня было открывание счетов в Евро — в общей сложности 6-ти значное число по 4 разным типам.
    Ну и запускались последовательно. Производительность — примерно 30 счетов в секунду (пиковая до 36). Загрузка процессора менее 30%.
    Решил попробовать параллельно — с помощью Misys’овых EQN0SPN и EQN0SPW.
    Запустил 4 штуки параллельно. Загрузка процессора 96% и скорость примерно 60 счетов в секунду.
    Значит действительно от кучи ядер нет никакого толку если конкретная задача не умеет их утилизовать.
    Что, вообще говоря, абсолютно логично.
    🙂

  • #10284

    Oldnick
    Участник

    так и есть.
    поэтому кто-то пишет сам примочки, которые помогают распараллеливать задачи, кто-то покупает готовые. 🙂 особенно актуально для новых машин P6/P7 с кучей ядер на борту.

  • #10285

    andrewk
    Участник

    а в OS/400 нельзя привязать задачу к конкретному процессору? В случае с AIX это выглядило бы примерно:
    а) форкнули процесс
    б) получили PID процесса
    в) забайндили PID на определенный процессор

  • #10286

    Сергей
    Участник

    а в OS/400 нельзя привязать задачу к конкретному процессору?

    А вопрос интересный! Как-то он меня раньше не посещал 😉
    Наверное потому, что задача, как правило, в обратной нотации — ограничить число процессоров для джоба у которого CURRENT DEGREE = ‘ANY’

    В PASE может быть и можно.

  • #10291

    Sever
    Участник

    а в OS/400 нельзя привязать задачу к конкретному процессору? В случае с AIX это выглядило бы примерно:
    а) форкнули процесс
    б) получили PID процесса
    в) забайндили PID на определенный процессор

    В IBM i отсутствует возможность «ручной» привязки задач к конкретному физическому процессору. Система видит только виртуальные процессоры, которые в любой момент могут быть смаппированы на физические. В системе свой встроенный механизм диспетчеризации задач и процессов, который построен на теории массового обслуживания и терии очередей. В любом случае в системе присутствует параметр, с помощью которого можно влиять на привязку уже работающей задачи к конкретному виртуальному процессору. По умолчанию он выключен для возможности переключения задачи на свободный процессор в случае занятости того, на котором она работала ранее в предшествующий интервал активности.

    В P6 системах на активность и доступность процессоров болше влияет гипервизор, который заточен на экономию элекроэнергии по умолчанию. В многоядерных партициях можно отследить факт того, что при низкой куммулятивной загрузке ядер вся утилизация процессорных ресурсов для дедикейтед режима группируется на последних процессорах ноды, а первые процессоры принудительно переводятся в sleep моду. В случае использования процессоров из shared пула в слип моду может быть переведена вся нода целиком.
    Жесткая привязка задачи к конкретному ядру в этом случае встапала бы в конфликт с этим механизмом…
    IMHO в P7 все должно работать аналогично.

  • #10395

    Sever
    Участник

    Поскольку до 1 января время осталось, а все в целом сделано, то решил попробовать оптимизнуть.
    Заодно проверить версию Севера по поводу ядер.
    Там у меня было открывание счетов в Евро — в общей сложности 6-ти значное число по 4 разным типам.
    Ну и запускались последовательно. Производительность — примерно 30 счетов в секунду (пиковая до 36). Загрузка процессора менее 30%.
    Решил попробовать параллельно — с помощью Misys’овых EQN0SPN и EQN0SPW.
    Запустил 4 штуки параллельно. Загрузка процессора 96% и скорость примерно 60 счетов в секунду.
    Значит действительно от кучи ядер нет никакого толку если конкретная задача не умеет их утилизовать.
    Что, вообще говоря, абсолютно логично.
    🙂

    Число потоков нужно подбирать банальным тестированием.
    Без увеличения мощности IO и объема ОП бездумное увеличение потоков может принести больше вреда.

    Для версии OS 6.1 есть пара фиксов, которые могут увеличить производительность до 30%% для любых задач, интенсивно использующих чтение по ключу и собраных в OPM. Фиксы на два порядка снижают паразитную активность двух системных модулей. Если есть интерес — стукнись по почте…

  • #10411

    Jevgeni Astanovski
    Участник

    Ты ж понимаешь! Тестированием…
    Для одноразовой проги. Ну на самом деле там было не тестирование а поиск компромисса между скоростью (выигрышем во времени) и необходимыми изменениями в программах. Они же не так просто, они в GYPF пишут. А он — обижается, если что. Там еще пришлось пободаться с DAJOBCTLE. В общем не разгуляешься. В итоге максимально было 4 параллельных процесса. Ну и ТЕХНИЧЕСКОЕ время сократилось почти в 2 раза. Был соблазн еще повозиться (время есть). Но понял что это бессмысленно, так как в промежутках есть «ручные» операции и проверка результатов по рапортам. На проверку у нас запросили примерно 2 часа. Ну и кого волнует, отработают программы за 74 минуты или за 62, к примеру 😛
    К тому же выяснилось, что наша живая машина примерно на 30% слабее тестовой и операционка там вообще — 5.4 :dry:
    Так что пусть будет. Лучшее — враг хорошего!

Для ответа в этой теме необходимо авторизоваться.