Данным постом, я выполняю давно обещанное, но не выполненное. За что приношу свои извинения.
Этот пост написал и просил меня разместить у себя в блоге Дмитрий Бондарев.
Контакты Дмитрия: электронная почта: bdmalex@mail.ru, skype: bdmalex.
Стиль и пунктуация - автора.
Существовал в нашей организации SAP ECC 6.0 на HP-UX платформе. И написали по какому-то ТЗ ABAP программисты отчёт дивный, который при запуске колбасил сервер и только после порядка 14 часов работы выдавал результат.
Ушёл ABAP-программист с чувством выполненного долга в отпуск, и естественно начальство начало задавать вопросы базису: "Почему это работает так долго?".
Начальственный заход для решения проблемы был простой: добавили в сервер ещё пяток ядер и немного ОЗУ. Запустили отчёт заново – и прослезились, никаких изменений.
Запускаем отчёт с трассировкой и получаем следующие унылые результаты:
Первый резерв вспомнился навскидку – это класс задания:
Выбираем класс "A" – и задание отрабатывает за 12 часов.
Всего на 7% меньше – но уже приятно!
Дальше, переходим на сервер приложений и запускаем любимую команду top.
Выясняется, что существенный % времени занимает переключение задания между ядрами процессора. А что будет, если жёстко привязать задание к одному процессорному ядру и заставить его работать только там. Зачем тратить драгоценное время на скачки с одного ядра на другое?
Заходим сразу после запуска задания в SM66 (или SM50, ну в общем это дело вкуса) и выясняем необходимый нам PID (идентификатор процесса). Далее на HP-UX под нашим любимым пользователем <sid>adm запускаем команду:
Для других *nix-платформ команды привязки следующие:
Ну, а почему бы не повысить приоритет нашему процессу. Запускаем:
Вот таким, совсем нехитрым способом, можно ускорить выполнение любого отчёта на многопроцессорной машинке с HP-UX (и не сомневаюсь, что аналогично можно сделать на любой *nix платформе, разве что запускаемые команды будут отличаться названием). В моём случае выигрыш составил порядка 42%, что на мой взгляд – вполне осязаемая и ощутимая величина.
Автор: Дмитрий Бондарев (e-mail: bdmalex@mail.ru, skype: bdmalex)
Этот пост написал и просил меня разместить у себя в блоге Дмитрий Бондарев.
Контакты Дмитрия: электронная почта: bdmalex@mail.ru, skype: bdmalex.
Стиль и пунктуация - автора.
История одного долгоиграющего отчёта
... или как сократить срок его выполнения не исправляя ни одной строки ABAP кода
... или как сократить срок его выполнения не исправляя ни одной строки ABAP кода
Существовал в нашей организации SAP ECC 6.0 на HP-UX платформе. И написали по какому-то ТЗ ABAP программисты отчёт дивный, который при запуске колбасил сервер и только после порядка 14 часов работы выдавал результат.
Ушёл ABAP-программист с чувством выполненного долга в отпуск, и естественно начальство начало задавать вопросы базису: "Почему это работает так долго?".
Начальственный заход для решения проблемы был простой: добавили в сервер ещё пяток ядер и немного ОЗУ. Запустили отчёт заново – и прослезились, никаких изменений.
Запускаем отчёт с трассировкой и получаем следующие унылые результаты:
- 98% времени уходит на работу на Сentral Instance (CI),
- 2% времени уходит на работу и взаимодействие с базой данных (DB).
Первый резерв вспомнился навскидку – это класс задания:
Выбираем класс "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)