История одного долгоиграющего отчёта

Данным постом, я выполняю давно обещанное, но не выполненное. За что приношу свои извинения.

Этот пост написал и просил меня разместить у себя в блоге Дмитрий Бондарев.
Контакты Дмитрия: электронная почта: bdmalex@mail.ru, skype: bdmalex.
Стиль и пунктуация - автора.

История одного долгоиграющего отчёта
... или как сократить срок его выполнения не исправляя ни одной строки ABAP кода

   Существовал в нашей организации SAP ECC 6.0 на HP-UX платформе. И написали по какому-то ТЗ ABAP программисты отчёт дивный, который при запуске колбасил сервер и только после порядка 14 часов работы выдавал результат.

   Ушёл ABAP-программист с чувством выполненного долга в отпуск, и естественно начальство начало задавать вопросы базису: "Почему это работает так долго?".

   Начальственный заход для решения проблемы был простой: добавили в сервер ещё пяток ядер и немного ОЗУ. Запустили отчёт заново – и прослезились, никаких изменений.

   Запускаем отчёт с трассировкой и получаем следующие унылые результаты:

• 98% времени уходит на работу на Сentral Instance (CI),
• 2% времени уходит на работу и взаимодействие с базой данных (DB).

   Так как у нас CI и DB – это 2 разных сервера, я даже слегка расстроился. Мне сначала думалось, что проблема связана с большим временем работы на БД. А стало ясно, что игры с оптимизацией запросов никаких существенных профитов не принесут и оптимизировать надо именно то,что крутится на СI.

   Первый резерв вспомнился навскидку – это класс задания:

Выбираем класс "A" – и задание отрабатывает за 12 часов.
Всего на 7% меньше – но уже приятно!

   Дальше, переходим на сервер приложений и запускаем любимую команду top.
Выясняется, что существенный % времени занимает переключение задания между ядрами процессора. А что будет, если жёстко привязать задание к одному процессорному ядру и заставить его работать только там. Зачем тратить драгоценное время на скачки с одного ядра на другое?
Заходим сразу после запуска задания в SM66 (или SM50, ну в общем это дело вкуса) и выясняем необходимый нам PID (идентификатор процесса). Далее на HP-UX под нашим любимым пользователем <sid>adm  запускаем команду:

 > mpsched –c номер_процессорного ядра  –p PID 

   Смотрим результат: отчёт отработал за 10 часов.

Для других *nix-платформ команды привязки следующие:

• bindprocessor для AIX
• psrset для Solaris
• taskset (+ chrt) для Linux

   В принципе, на этом можно было бы успокоиться, но ведь аппетит всегда приходит во время еды? Что ещё можно сделать, чтобы ускориться?

   Ну, а почему бы не повысить приоритет нашему процессу. Запускаем:

 > renice –n +20 –p PID 

   Смотрим результат: отчёт отрабатывает за 8 часов.

   Вот таким, совсем нехитрым способом, можно ускорить выполнение любого отчёта на многопроцессорной машинке с HP-UX (и не сомневаюсь, что аналогично можно сделать на любой *nix платформе, разве что запускаемые команды будут отличаться названием). В моём случае выигрыш составил порядка 42%, что на мой взгляд – вполне осязаемая и ощутимая величина.

Автор: Дмитрий Бондарев (e-mail: bdmalex@mail.ru, skype: bdmalex)