Снова о WLM и не только

[zVlad]

слушая недавний webcast по поводу анонсирования z13 я, заскучав на докладе далеком от собственно МФ, подсоединился к офису и обнаружил что там беда с производительностью....
Немного предыстории. С конца прошлого года у нас идет перевод двух с лишним тысяч пользователей из ERP приложения на SAP в Юникс/Оракл в другое ERP приложение на МФ. При этом внедрился новый интерфейс которых на Java в WebSphere и было принято ошибочное решение поставить WS на два сервера AIX вместо того чтобы поставить в ту же zOS на ятовь же МФ. С этим тоже были связаны проблемы решеные наконец лишь вчера, но об этом ниже.
Этот новый интерфэйс, в отличии от старого, не только держит метаданные в ДБ2 на МФ (вторая ошибка - раз уж решили ставить WS не на МФ так заведите локальную БД для метаданных там же - не на МФ, а где нибудь поближе), но и достает прикладные данные не через CICS (как в старом интерфейсе) а напрямую, через JDBC. И вот с этими запросами в ДВ2 случилась заминка.
Не сказать чтобы такие, удаленные, запросы в ДБ2 для нас были в новинку. Несколько лет назад был возвращен прикладной модуль на МФ (складская задача) который до того использовал тоже удаленные запросы. Для того модуля и его запросов в WLM была сделана правильная конфигурация. А про этот новый интерфэйс забыли. Пользователи визжат, манагеры забросали письмами мой Тим лид пытается что-то как всегда не имеющее отношение к делу и проблеме рассказывать. Я посмотрел данные в мониторе и увидел что сумма времени процессора и времени ожидания ввода-вывода много меньше чем общее время нахождения запроса в ДБ2, и это так только для удаленных запросов. Тут же включилась мысль о WLM, тут же WLM был подправлен (конкретно в отношении удаленных запросов к ДБ2) и новая полиси была активирована. На другой день,весь день я мониторил и убедился что теперь время нахождения в ДБ2 примерно равно стремени процессора и ожидания нормальных процессов -IO и других).

Может возникнуть вопрос почему сразу это было не замечено, ведь мы начали новую жизнь со 2-го января, а завизжали лишь 14-го. Дело в том что после нового года люди подтягивались постепенно и ресурсов (хотя как обычно CPU было 100% busy большую часть времени) так или иначе хватало, а 14 января workload стал таким что удаленные запросы с низким уровнем сервиса (service classes in WLM) стали дольше стоять в очередях. Вот и все. Подтянув сервис класс удаленных запросов к запросам из CICS, я лишь обеспечил, с помощью WLM, более справедливое распределение ресурсов и этого оказалось достаточно.

[Palych]

ресурсов (хотя как обычно CPU было 100% busy большую часть времени) так или иначе хватало, а 14 января workload стал таким что удаленные запросы с низким уровнем сервиса (service classes in WLM) стали дольше стоять в очередях. Вот и все. Подтянув сервис класс удаленных запросов к запросам из CICS, я лишь обеспечил, с помощью WLM, более справедливое распределение ресурсов и этого оказалось достаточно.

А какие запросы теперь замедлились?

[zVlad]

ресурсов (хотя как обычно CPU было 100% busy большую часть времени) так или иначе хватало, а 14 января workload стал таким что удаленные запросы с низким уровнем сервиса (service classes in WLM) стали дольше стоять в очередях. Вот и все. Подтянув сервис класс удаленных запросов к запросам из CICS, я лишь обеспечил, с помощью WLM, более справедливое распределение ресурсов и этого оказалось достаточно.

А какие запросы теперь замедлились?

Хороший вопрос, спасибо. Естественно чудес быть не может и если система была загружена на сто процентов то помочь кому-либо можно лишь отобрав у другого.
Замедлились запросы из CICS и сам CICS, который есть напомню аппликэйшн сервер. Но, поскольку числа у запросов CICS были хорошими то их ухудшения, тем более разбросанные на гораздо бОльшее количество чем количество удаленных запросов, пока не критичны. А перераспределенные ресурсы заметно улучшили положение с удаленными запросами (их в целом гораздо меньше количественно).

Кроме того был использован механизм "периодов" это когда жизненный цикл транзакции можно разделить на стадии каждая из которых может иметь свой target и свои численные параметры. И в этом смысле удаленные запросы предоставляют хорошую возможность основанную на том что каждый такой запрос известен системе в то время как запросы CICS полностью управляются и известны только CICS (здесь тоже не всё так просто, но у нас это так потому что наши CICS специалисты ленивы и тупы, а я не CICS специалист и не хочу им быть - слишком много будет для одного). Так что для удаленных запросов я создал два периода - первый с более высоким приоритетом и критерием по response time, а второй период такой же как в целом для CICS транзакций. Подумав вы спросите а как же происходит переход с первого периода на второй. Очень просто, всем периодам кроме последнего дается определенное количество "service units" в этом случае я дал 500 su. Что такое su? Это определенным образов подсчитанное количество времени CPU, ввода-вывода и памяти. С помощью коэффициентов, которые можно тоже менять делая акценты на те или иные ресурсы. Таким образом как только транзакция потребит некоторое количество ресурсов периода она будет переведена на другой уровень обслуживания - ниже или выше и так до последнего на котором будет оставаться до завершения.

Кроме периодов есть еще одна фишка у WLM. Performance Index (PI) это отношение достигнутого сервиса к заданному. WLM подсчитывает это отношение и делает во-первых вывод о качестве управления, а во-вторых решает у какого сервис класса можно отобрать ресурсы а какому их добавить. Доноры-реципиенты.

[Palych]

Замедлились запросы из CICS и сам CICS, который есть напомню аппликэйшн сервер. Но, поскольку числа у запросов CICS были хорошими то их ухудшения, тем более разбросанные на гораздо бОльшее количество чем количество удаленных запросов, пока не критичны. А перераспределенные ресурсы заметно улучшили положение с удаленными запросами (их в целом гораздо меньше количественно).

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

...А ну как добавить процессор(ов) и не заморачиваться с приоритетами? Чтобы никто не ушел обиженным?

[zVlad]

Замедлились запросы из CICS и сам CICS, который есть напомню аппликэйшн сервер. Но, поскольку числа у запросов CICS были хорошими то их ухудшения, тем более разбросанные на гораздо бОльшее количество чем количество удаленных запросов, пока не критичны. А перераспределенные ресурсы заметно улучшили положение с удаленными запросами (их в целом гораздо меньше количественно).

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

...А ну как добавить процессор(ов) и не заморачиваться с приоритетами? Чтобы никто не ушел обиженным?

Обиженным никто уйти не может, некуда - система перенесена на МФ и работает.

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

Ухудшение не могло быть заметным, как я уже объяснил выше. Улучшения тоже обычно не такое яркое событие чтобы его замечали пользователи.

Про добавить процессоров. Собственно их добавлять не надо. Надо лишь активировать более высокий уровень капасити. У нас он Q05, до буквы Z еще достаточно места для роста мощности нашего МФ. Тут проблема в прохождении purchase order через нашу бюрократию. Это говорят может длится месяцами. После оплаты это будет дело нескольких минут. Без физического присутствия ИБМ.

[Palych]

Про добавить процессоров. Собственно их добавлять не надо. Надо лишь активировать более высокий уровень капасити. У нас он Q05, до буквы Z еще достаточно места для роста мощности нашего МФ. Тут проблема в прохождении purchase order через нашу бюрократию. Это говорят может длится месяцами. После оплаты это будет дело нескольких минут. Без физического присутствия ИБМ.

А разве не были процессоры заняты на 100% до начала миграции?
Может тогда и надо было инициировать процесс добавления?
А теперь некоторые запросы замедляются под нагрузкой, а вы надеетесь что этого никто не заметит...

[zVlad]

Про добавить процессоров. Собственно их добавлять не надо. Надо лишь активировать более высокий уровень капасити. У нас он Q05, до буквы Z еще достаточно места для роста мощности нашего МФ. Тут проблема в прохождении purchase order через нашу бюрократию. Это говорят может длится месяцами. После оплаты это будет дело нескольких минут. Без физического присутствия ИБМ.

А разве не были процессоры заняты на 100% до начала миграции?
Может тогда и надо было инициировать процесс добавления?
А теперь некоторые запросы замедляются под нагрузкой, а вы надеетесь что этого никто не заметит...

Процессоры были заняты на 100% и до миграции и до того как была сделана миграция одного модуля. Но, как уже говорил, до всех миграций 100% было кратковременным явлением, а теперь кратковременным явлением бывает когда процессор не 100%. Я прицепил картинку здесь. Верхний график показывает CPU busy для Production LPAR, нижний для Test LPAR. Напомню, это один и тот же MF с 5 CPU (поэтому я даю оба графика). Веса LPAR: 80% Production, 20% Test. Production-у доступны все 5 CPU, Test только 3, последнее обстоятельство не имеет никакого сакрального значения поскольку у нас использыется HyperDispatch. Dmitry67 знает что это за зверь. В крaтце с HyperDispatch даже если бы мы сделaли все 5 CPU доступными Test LPAR он все равны бы использовал только три (потому что веса: 80% и 20%)), а два находились бы в "Parked" status.

Разговор о добавлении CPU капасити шел, но чисто теоритически. У нас на этом МФ есче есть 4 GB не распределенной памяти. И пока загрузил туда инсталяшку Linux, но руки завершить инсталяцию не доходят пока и вряд ли дойдут скоро.

У нас есть роботы (PC со скриптами) на каждом user locations (их примерно десять). Эти роботы по графику делают тестовый прогон по определенному сценарию и меряют response time. Эти response time (среднее значение) являются предметов SLA и должны быть не больше 1 секунды. Пока я не слышал чтобы роботы намеряли больше 1 секунды. Если роботы начнут показывать плохие числа то разговор о добавлении ЦПУ может перейти в практическую плоскость. Пожуем - увидим.