Методика пошуку вузьких місць з виробництва. Визначення вузьких місць. Планування оптимальної програми виробництва чи асортименту. Розширення bottleneck дасть відчутний приріст продуктивності та ефективності

Передісторія
У жовтні 2010р., в рамках організації проектів щодо підвищення ефективності
авіазаводу на 2011р., компанія «Райтстеп» виконала діагностику основного
виробництва заводу. Основною метою обстеження було визначення «вузьких місць», тобто. тих об'єктів, процедур управління та підрозділів, які обмежували весь випуск заводу.
За результатами аналізу, основними «вузькими місцями» заводу було визначено (потенційним «вузьким місцем» також були процедури (вірніше їх відсутність) ведення електронного складу виробу):
1) агрегатно-складальний цех АСЦ1;
2) методи планування та управління виробництвом;
3) цех ШЦ (штампувальний), цех МЦ (механічний)
У цій статті описується розшивка вузького місця в цеху АСЦ1.

Цех АСЦ1 - перший у послідовному ланцюжку збирання машин (там із агрегатів починає збиратися виріб, далі - передається в інші складальні цехи, АСЦ2 і ЦОС), що є «вершиною трикутника» внутрішньозаводського ланцюжка поставки і є споживачем інших «деталі-робильних» цехів (Д ). Або - початком «трубопроводу» переміщення виробу по ланцюжку збирання.

Отже, будь-яка проблема, що виникає в цеху АСЦ1 і обмежує початок збирання виробів, автоматично призводила до обмеження випуску машин усім заводом.
І на осінь 2010 року цех АСЦ1 був таким вузьким місцем, із середнім випуском у 6 виробів на місяць, при заводському плані у 7-8. Основними проблемами АСЦ1 були:
1) несинхронність поставок деталей та складальних одиниць від інших цехів на адресу цеху АСЦ (читай – постійні «несподівані» дефіцити на складання)
обумовлена ​​фактичною відсутністю розрахункового позамовного (помашинного) плану постачання;
2) вкрай неефективна внутрішня організація роботи у цеху, з основними симптомами (не причинами!): «немає людей», «браковані деталі», «немає місця, нікуди ставити вироби».

Фактично проблеми АСЦ1 були відображенням проблем в управлінні та організації виробництва всього заводу. І, перш за все:
1) фактичною відсутністю синхронізованого між «детальними і «агрегатносборочними» (ДДЦ і АСЦ) цехами помашинного номенклатурного плану, що призводило до випуску не того, що треба і не в тому кількості, як наслідок - до роботи «за дефіцитами» і, в зрештою, до зриву графіка складання;
2) відрядної оплати праці, що дозволяє і змушує цехи гнатися, передусім за «валівкою», навіть – у цехах-«вузьких місцях», у своїй – який завжди з урахуванням дефіцитів.

Вибір концепції

За результатами аналізу даних та обговорення можливих шляхів «розшивки» вузького місця» було визначено такі напрями перетворень.

Перше:зміна системи управління виробництвом так, щоб вона змушувала випускати тільки те, що потрібно при порівняно невисоких витратах. Для цього було потрібно:
1) організувати систему витягуючого позамовного номенклатурного цехового планування, систему моніторингу поставок та «закриття» машин;
2) через зміну системи мотивації (модифікації «угоди») мотивувати цехи виконання передусім зазначеного плану;
3) забезпечити можливість управління процесом виробництва та поставок через візуалізацію та моніторинг того, що відбувається.

Друге: зміна системи організації виробництва цеху через:
1) оптимізацію внутрішньоцехових потоків руху деталей та агрегатів,
2) усунення всіх зайвих як виробничих так і не виробничих операцій на шляху створення машини,
3) забезпечення візуалізації того, що відбувається, статусу справжньої ситуації, майбутніх та справжніх проблем,
4) скорочення партій запуску та переміщень по всьому ланцюжку виробництва.

Для реалізації зазначених перетворень було обрано інструменти SCM («управління виробничими ланцюжками»), Lean («ощадливе виробництво») та ТГЗ («Теорія Обмежень») методів управління виробництвом.

Роботи по першому напрямку, постановка «Система Планування та Моніторингу заводу» почали реалізовуватися через впровадження для всього заводу нових процесів (процедур) синхронізованого (під графік складання та відвантаження машин) планування та управління виробництвом, плюс, впровадження Lean IT Системи Планування та Моніторингу, що їх підтримує. виробництва SCMo.

Роботи по другому напрямку були прийняті до реалізації з використанням більш традиційних, але, «підігнаних» до застосування на заводі інструментів Lean і TOC.

Перетворення. Нова організація всередині цеху АСЦ1

Проект перетворень в АСЦ1 було розпочато у січні 2011 року, але потім у зв'язку з певними змінами в цеху зупинено.

Наведені нижче результати проекту було досягнуто лише за кілька місяців, у т.ч. завдяки рішучій та принциповій позиції керівництва цеху. І, забігаючи вперед, відзначимо, що основна мета проекту - збільшена пропускна спроможність цеху з 6 до 8 машин на місяць, за умови:
незбільшенні операційних витрат (ФОП, чисельність робітників тощо) та запасів деталей та НЗП - було досягнуто.

Оптимізація ділянки позастапельного збирання виробів

Фізичне розташування виробів. Робота з нестачею місця

За результатами аналізу було визначено, що одним із «вузьких місць» АСЦ1 була фізична організація ділянки позастапельної збірки. Ділянка була захаращена старим оснащенням/антресолями, непотрібними шаблонами, деталями та іншою нісенітницею, яка фактично не використовувалася при виробництві машин існуючих модифікацій.

силу цього, на ділянці позастапельної збірки вдавалося розмістити максимум 3-4 машин, що одночасно збираються. Причому, у вкрай стиснутих та неоптимальних умовах.



Цього було б достатньо при ідеальній організації робіт зі збирання та ідеальному дотриманні графіка поставок деталей з інших цехів. Але, «в реальному світі», при виникненні проблем із будь-яким виробом, він гальмував складання, в т.ч. стапельную всіх інших машин. І бригади збирачів просто не мали фізичної можливості переходити на іншу машину.
В результаті було прийнято рішення про знесення непотрібного обладнання, розчищення місця та організації на ділянці двох «ліній» збирання машин. У ході проведення даних роботи було використано методи ергономічної організації робочого простору по 5С. схему і фото.



Як результат, на ділянці позастапельної збірки тепер можна помістити 6 машин, включаючи здавальні, і це – при незрівнянно кращій та зручнішій організації робочих місць.

Перенесення операцій із остаточного складання виробу на інші ділянки.

За результатами аналізу ділянки позастапельної збірки, що було «вузьким місцем» цеху, було виявлено численні «зайві» операції, тобто. операції, які більш ефективно могли бути виконані на інших ділянках та менш кваліфікованим персоналом. Деякі приклади – див. фото.

Після проведення ретельного аналізу та обговорень з технологами цеху дані операції були перенесені на інші, менш завантажені ділянки, звільнивши час збирачів від «непрофільних» операцій.

Зміна системи нарахування заробітної плати робітників

В рамках перетворень було змінено систему нарахування заробітної плати робітникам.
Фонд заробітної плати явно розраховувався виходячи з плану випуску, факт залежав від кількості зроблених і переданих у наступний по ланцюжку цех машин.
Далі, ця сума розподілялася за членами складальних бригад (бригадирами), залежно від кваліфікації працівників та коефіцієнта трудової участі.

Система сигналізації

Додатково було прийнято рішення побудувати гнучку структуру робочого процесу в цеху, орієнтовану на створення максимальних умов
виробничого робітника та сигналізації/вирішення всіх його потреб/проблем в оперативному режимі, як показано нижче:

Для швидкого реагування вищезгаданого ланцюжка на потреби виконавців вирішили використовувати засоби візуалізації, такі як сигнальні лампочки. Кожен сектор ділянки планується оснастити двома типами лампочок зеленого та червоного кольору та кнопками їх включення.

Зелена лампасигналізує про те, що сектор повністю забезпечений деталями, є оснащення для виготовлення та цілком зрозумілі поточні потреби у зборках (тобто ситуація нормальна).

Червона лампочка- це сигнал до того, що сектор потребує вирішення проблем одного з трьох напрямків, і майстер ділянки повинен максимально швидко зреагувати на цей запит і вжити заходів до якнайшвидшого вирішення, або повідомити інших виконавців, якщо питання зачіпає їх компетенцію.

Жовта- Проблема існує, але в процесі вирішення.

Оптимізація ділянки детального збирання цеху

Система забезпечення поставок від ділянки детального збирання цеху

Після проведення зазначених вище перетворень пропускну здатність ділянки позастапельної збірки вдалося збільшити до 8 машин на місяць. Але, практично відразу "вузьке місце" цеху АСЦ1 перемістилося на ділянки детального збирання цеху.

У зв'язку з цим, нова організаціябула впроваджена на ділянці детального складання цеху, ділянці, що виготовляє та безпосередньо постачає складання на позастапельне складання. Роботи були виконані приблизно за місяць, за запропонованою «Райтстепом» методології:
1) оптимізація організації робочих місць ділянки за принципами "5С";
2) встановлення системи візуалізації;
3) організація системи витягуючого планування та постачання деталей на складання, методами «супермаркет» та «канбан».



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

Перетворення. Забезпечення своєчасності поставок до АСЦ1


Система Планування та Моніторингу SCMo

З погляду «зовнішніх» умов, величезною проблемою цеху було неритмічне (несинхронне з ритмом складання конкретних машин) постачання деталей із ДДЦ цехів заводу.
Вирішення цієї проблеми здійснювалося у рамках загальнозаводського проекту постановки системи синхронного позамовного номенклатурного міжцехового планування. Як методологія була взята методологія «витягуючого» (точно вчасно і точно в кількості на замовлення) планування та методологія роботи з «буферами» та «пріоритетами» «вузьких місць» Теорії Обмежень.

Як інструмент реалізації використовувалася Lean ERP система SCMo, що забезпечує on-line планування, управління та моніторинг процесів виробництва та постачання.
Настроєний для заводу алгоритм планування дозволяв формувати позамовні (під кожну машину чи «розсипне» замовлення) номенклатурний план
виробництва та поставок для кожного цеху, охопленого системою. З постійно оновлюваної за фактом виробництва колірною сигналізацією/підсвічуванням кожної з партій деталей, що поставляються цехом-постачальником. схему нижче.

У рамках проекту перетворень у цеху АСЦ1, з використанням SCMo вдалося «правильно» поставити такі процеси:
1) формування послідовності складання машин по цехах АСЦ1 - АСЦ2 - ЦОС, і, для АСЦ1 - формування графіка здачі, за конкретними машинами та на конкретні числа місяця (див. екранну форму нижче):

2) виходячи з графіка здачі машин цехом АСЦ1 - формувати план поставок деталей і агрегатів від цехів - постачальників. Повністю автоматизувати даний момент не вдалося через неточності в електронному складі виробу (машина). Внаслідок цього було прийнято рішення щодо часткового відання в SCMo електронних дефіцитів на адресу цехів постачальників, з обов'язковою установкою постачальниками «обіцяної дати». Фактично це – публіковані on-line і доступні для всіх «журнали дефіцитів», які раніше вели диспетчера ПДБ цеху, і інформація з яких ставала доступна цехам постачальникам часто у спотвореному вигляді, і лише на планерках.

Зроблено це було в рамках нової методології управління, перекладеної на ІТ систему, а саме забезпечення максимальної візуалізації того, що відбувається для всіх учасників виробничого ланцюжка(див. нижче):

Побічний позитивний ефект - ведення «електронних дефіцитів» в SCMo - можливість переходу на «електронні» планерки, ефективність яких набагато вища за традиційні, а час, що витрачається на них, - менша.

Система моніторингу того, що відбувається (система відеоспостереження)

У рамках цього напряму, для забезпечення максимальної візуалізації того, що відбувається у виробництві, в цеху також було впроваджено систему візуалізації (відеоспостереження), що працює в on-line режимі і дозволяє при необхідності побачити, що реально відбувається на ділянках цеху в даний момент часу.


Результати проекту

1. Збільшено пропускну здатність цеху з 6 до 8 машин на місяць.

При: незбільшенні операційних витрат (ФОП, чисельність робітників тощо) та запасів деталей та НЗП.
2. Введено в роботу Система Планування та Моніторингу поставок, що синхронізує не тільки випуск, а й запуск усіх цехів заводу з графіком
агрегатного та остаточного складання машин.
3. Забезпечено повну прозорість того, що відбувається у виробництві.
4. Забезпечено базис для виходу у 2012 р. на ритм виробництва 9 машин на місяць.
5. Запущено «маховик» перетворень, у т.ч. та інших ділянках цеху.

Райтстеп, Iris Partenaires

Інший часто зустрічається постановкою завдань дослідження складних об'єктів з метою вдосконалення організаційного управління вивчення можливостей підвищення продуктивності технологічної схемиоб'єкта за рахунок максимально можливого скорочення простоїв обладнання апаратів обслуговування, окремих каналів та/або фаз. Кількісну оцінку простоїв обладнання можна отримати імітаційним моделюванням функціонування об'єкта протягом представницького проміжку часу, отриманням та аналізом відповідних тимчасових характеристик.

Цільова функція організаційного управління у зазначених випадках має вигляд, аналогічний (9.36):

v=min (9.39),

де - час простою апарату обслуговування (або каналу, або окремої фази - при відповідному виборі індексів) перед надходженням на обслуговування i-го вимоги із спільної партії Nвимог.

Так, для одноканальних однофазних об'єктів сумарна величина простоїв апарату обслуговування для всієї партії Nвимог визначається виразом (9.8), тому цільова функція організаційного управління, зокрема автоматизованого, у разі має вигляд:

v=[ 1sign(+)]min (9.40).

Аналогічні вирази можна отримати для багатофазних та багатоканальних об'єктів як систем масового обслуговування на основі (9.16), (9.26) або (9.34).

Звернемо увагу на те, що в даному випадку цільова функція vорганізаційного управління є комплексним критерієм, який враховує, крім розглянутих простоїв обладнання, та інші фактори, оскільки до нього входять інтервали надходження вимог, періоди зайнятості апаратів, каналів та фаз, а також інші часові характеристики. Тому, якщо реалізувати в даному об'єкті вказані в попередньому підпараграфі заходи, що призводять до скорочення часів очікування вимогами, це також призведе і до збільшення завантаження обладнання технологічних об'єктів, що робить у багатьох практичних випадках особливо зручним вибір критерію ефективності організаційного управління складними, що саме розглядається в цьому підпараграфі. об'єктами.

3. Виявлення та ліквідація "вузьких місць"

У виробничих системах "вузьким місцем" у технологічній схемі називають апарат, що має продуктивність нижче, ніж технологічна схема в цілому, тому саме він і є ланкою загального обслуговування, що лімітує, в об'єкті. Виявлення "вузьких місць" дозволяє поставити і вирішити завдання підвищення продуктивності об'єкта особливо раціонально, реалізуючи комплекс організаційно-технічних заходів стосовно одного, даного апарату, що є "вузьким місцем", а не до всієї технологічної схеми в цілому, оскільки останнє, безсумнівно, складніше, довше і зазвичай набагато дорожче.

Часто " вузьке місце " є змінним " у часі та просторі " , тобто. залежно від технологічного режиму та умов функціонування об'єкта чи його окремих ланок чи технологічної природи окремих груп чи класів вимог (іншими словами, залежно від конкретної ситуації в об'єкті в даний проміжок часу) "вузьким місцем" може виявитися то один, то інший апарат ( або канал) обслуговування чи навіть окрема фаза. У таких випадках виявлення "вузьких місць" імітаційним моделюванням є важливим напрямом дослідження об'єкта з метою обґрунтування, розробки та подальшої перевірки ефективності управлінських рішень. Відомо, що під ліквідацією “вузького місця” мають на увазі комплекс організаційно - технологічних заходів, після реалізації яких апарат, колишній “вузьким місцем” більше не є таким і не стримує функціонування виробництва в цілому.

Ознакою наявності "вузьких місць" у технологічній схемі об'єкта, що інтерпретується як СМО, є утворення черги або затримки на попередніх агрегатах або фазах перед апаратом (або фазою), що є "вузьким місцем", і, навпаки, простий апаратів (або фаз) безпосередньо після нього.

Уявімо ситуацію з наявністю "вузького місця" в об'єкті у формалізованому вигляді, використовуючи методику, що розглядалася вище в цьому розділі.

Нехай, наприклад, об'єкт як одноканальна СМО складається з декількох одноканальних послідовно розташованих однофазних апаратів обслуговування, технологічна схема якого відповідає рис.9.5.

9.5. Схема багатоапаратної одноканальної СМО.

Апарати обслуговування технологічної схеми цієї СМО позначені індексом kі саме k-ий з них є "вузьким місцем". Нехай i-а вимога знаходиться на обслуговуванні у зазначеному k-ом апараті протягом часу, причому воно надійшло в цей апарат з інтервалом по відношенню до вимоги, що раніше прийшла.

На попередньому ( k1)-ом апараті вимога, що перебуває там, вже закінчила обслуговування і чекає звільнення k-го апарату; можливо, на вході до ( k1)-ий апарат вже знаходиться ще одна вимога в очікуванні обслуговування. Таким чином, ситуація на ( k1)-ом апараті відображається тимчасовою характеристикою (9.4):

= +при+>для (9.41);

Наступний, ( k+1)-ый апарат перебуває у стані простою, тому для нього в загальному випадку на підставі (9.8) матимемо:

= при>+для [ k+1, ...,n] (9.42).

Що ж стосується безпосередньо k-го апарату технологічної схеми, що є "вузьким місцем", то для нього може бути справедливе як співвідношення (9.41), так і (9.42), залежно від того, що конкретно лімітує його функціонування або початок обслуговування вимоги (тобто · вхід апарату, можливо, початкові фази обслуговування, якщо воно багатофазне, і т.д.), або його стан (внутрішні елементи, зв'язки між ними, заключні фази тощо).

Цільова функція організаційного управління v, спрямованого на ліквідацію "вузького місця" та збільшення за рахунок цього продуктивності всієї технологічної схеми, має наступний загальний вигляд:

v=(9.43).

Аналогічно можна отримати висловлювання за інших структур об'єкта та інших дисциплін обслуговування. Реалізувавши імітаційну модель досліджуваного об'єкта на ЕОМ стосовно різних умов його функціонування і отримавши в кількісному вигляді значення критеріїв (9.41) і (9.42) для кожного компонента та/або технологічної схеми, що завжди можна зробити, за цими отриманими результатами легко встановити, чи має місце у цій технологічної схемою " вузьке місце " і який саме компонент об'єкта й у яких умовах їм є. Після чого можна пропонувати комплекс організаційно - технічних заходів з ліквідації “вузького місця” (розпаралелювання обслуговування вимог у цьому місці технологічної схеми виробництва, прискорені технології, тобто із значно швидшим обслуговуванням і відповідно меншим середніми тощо), а також потім перевірити їх ефективність на тій самій імітаційній моделі об'єкта.

Вузьке місце

Вузьке місце- явище, у якому продуктивність чи пропускну здатність системи обмежена одним чи кількома компонентами чи ресурсами. У відповідному англомовному терміні (англ. bottleneck) Простежується аналогія з горловиною пляшки, вузькість якої не дозволяє вилити або висипати весь її вміст відразу, навіть якщо її перевернути. У разі збільшення її ширини збільшується і швидкість, з якою пляшка спустошується. Щодо бізнесу, то вузьким місцем організації є те, що знижує її продуктивність.

Управління проектами

Вузькі місця у програмному забезпеченні

Див. також


Wikimedia Foundation. 2010 .

Синоніми:

Дивитись що таке "Вузьке місце" в інших словниках:

    Ситуація прийняття рішення за недостатніх виробничих потужностях, у якій калькуляція покриття показує, який асортимент продукції підприємству слід вибрати у тому, щоб якнайвище покриття. Див. також:… … Фінансовий словник

    Заковирка, труднощі, утруднення, заколупка, проблема, перешкода, закавычка, зачіпка, закорючка, загвоздка, закавыка, пікове положення, кома, ускладнення Словник російських синонімів. вузьке місце сущ., у синонімів: 19 загвоздка (26) … Словник синонімів

    - (bottleneck) Реальне обмеження (constraint) максимальних темпів розвитку чи рівня будь-якої діяльності. У економіці цей термін використовується за аналогією з фізикою. Наприклад, максимальна швидкість витікання рідини з пляшки. Економічний словник

    вузьке місце)- Вузька частина - Тематики нафтогазова промисловістьСиноніми вузька частина EN criticalnarrow …

    вузьке місце- вузький прохід - Тематики нафтогазова промисловість Синоніми вузький прохід EN bottleneckbottle neck … Довідник технічного перекладача

    "вузьке місце"- 3.46 «вузьке місце»: Об'єкт газотранспортної системи (магістральний газопровід, газопровід відведення, газопровід перемичка, розподільчий газопровід або їх ділянка, компресорна станція, ДПА, станція підземного зберігання газу, ГІС, вузол… Словник-довідник термінів нормативно-технічної документації

    "ВУЗЬКЕ МІСЦЕ"- - ситуація, що складається внаслідок недоліків в організації виробництва, коли робоче місцене забезпечується матеріальними, трудовими чи паливно-енергетичними ресурсами; перевищення продуктивності праці за попередньої… … Короткий словник економіста

    вузьке місце- у чому. Найбільш слабка, вразлива сторона в якомусь л. справі, що створює труднощі, ускладнення тощо. У е місце у виробництві … Словник багатьох виразів

    - (сленг.) 1) нестача виробничих потужностей в ланцюзі технологічного процесу, який визначається будь-яким компонентом: обладнанням, персоналом, матеріалами або доставкою, транспортуванням; ліквідується в ході організаційно-технічних… Енциклопедичний словник економіки та права

    Публ. Недолік у слабких ланках виробничого процесу, господарювання. НРЛ 96; БТС, 1378; Мокієнка 2003, 57 … Великий словник російських приказок

Книги

  • Синергетика та самоорганізація. Соціально-економічні системи, Мілованов В.П.. У цій книзі докладно розглядається синергетика та самоорганізація у соціально-економічних системах, і, зокрема, у ціноутворенні. Пропонуються формули для розрахунку цін, емісії...
1

У статті розглядається метод аналізу та усунення вузьких місць технологічних, логістичних та організаційних бізнес-процесів. Для дослідження технологічних, логістичних та організаційних бізнес-процесів застосовується підхід мультиагентних процесів перетворення ресурсів. Для моделювання процесів перетворення ресурсів потрібно дедалі більше обчислювальних ресурсів. У зв'язку з цим є актуальним виявлення та використання нових принципів побудови та аналізу мультиагентних моделей процесів перетворення ресурсів. Метод аналізу та усунення вузьких місць мультиагентного процесу перетворення ресурсів ґрунтується на інтеграції моделі процесу перетворення ресурсів, операційного аналізу ймовірнісних мереж, мультиагентного підходу та експертних систем. Метод аналізу та усунення вузьких місць мультиагентного процесу перетворення ресурсів програмно реалізовано в автоматизованій системі випуску металургійної продукції.

автоматизована інформаційна система

технологічні операції

процес перетворення ресурсів

вузьке місце

мультиагентне моделювання

1. Аксьонов К.А., Аксьонова О.П., Ван Кай. Планування портфеля проектів у будівництві на основі мультиагентного імітаційного моделювання // Науково-технічні відомості СПбДПУ № 6 (162) 2012. Інформатика. Телекомунікації. Управління. м. С.-Петербург С. 171-174.

2. Аксьонов К.А., Антонова А.С., Спіцина І.А., Сисолетін Є.Г., Аксьонова О.П. Розробка автоматизованої системи аналізу, моделювання та прийняття рішень для металургійного підприємствана основі мультиагентного підходу // Автоматизація у промисловості. - М., 2014. - № 7. - С. 49-53.

3. Аксьонов К.А., Ван Кай, Аксьонова О.П. Вирішення завдання планування портфеля проектів та аналізу вузьких місць бізнес-процесу на основі мультиагентного моделювання та методу критичного шляху // Сучасні проблеминауки та освіти. - 2014. - № 2; URL: www.04.2014).

4. Аксьонов К.А. Модель мультиагентного процесу перетворення ресурсів та системний аналіз організаційно-технічних систем. // Вісник комп'ютерних та інформаційні технології. – 2009. – № 6. – С. 38–45.

5. Бородін А.М., Мирвода С.Г., Поршнєв С.В. Аналіз сучасних засобів прототипування мов програмування// Програмна інженерія. – 2014. – № 12. – С. 3–10.

6. Бородін А.М., Мирвода С.Г., Поршнєв С.В. Особливості тестування стійкості до збоїв корпоративних інформаційних системметодом генерування відмов // Сучасні проблеми науки та освіти. - 2014. - № 5. - URL: www..02.2015).

7. Литвин В.Г., Аладишев В.П., Винниченко О.І. Аналіз продуктивності мультипрограмних ЕОМ. M.: Фінанси та статистика. – 1984. – 159 c.

8. Томашевський В., Жданова E. Імітаційне моделювання в середовищі GPSS. М: Бестселер. – 2003. – 416 c.

9. Aksyonov K.A., Bykov E.A., Aksyonova O.P. Application of Multi-agent Simulation for Decision Support in Construction Corporation and its Comparison with Critical Path Method // Applied Mechanics and Materials Vols. 278-280 (2013) Trans Tech Publications, Switzerland. doi:10.4028/www.scientific.net/AMM.278-280.2244. pp. 2244-2247.

Існуючі методи аналізу та імітаційного моделювання технологічних, логістичних та організаційних бізнес-процесів часто стикаються з об'єктами, в яких кількість елементів перевищує сотні. У зв'язку з цим щодо імітаційного експерименту таких моделей потрібно дедалі більше обчислювальних ресурсів і машинного часу. Технологічні, логістичні та організаційні бізнес-процеси відносяться до процесів перетворення ресурсів. Специфікою даних типів процесів є існування у складі підпроцесів (операцій) прийняття та узгодження рішень, підпроцесів чи елементів управління, осіб, які приймають рішення (ЛПР). Для формалізації моделей ЛПР та сценаріїв прийняття (управління та узгодження) рішень у даній роботі пропонується використовувати апарат мультиагентних та експертних систем. У зв'язку з цим актуальне завдання розробки нового методу аналізу та усунення вузьких місць мультиагентних процесів перетворення ресурсів (МППР).

Метод аналізу та усунення вузьких місць мультиагентного процесу перетворення ресурсів

Розглянемо два основних елементи процесу МППР (операцію та агента), що використовуються для аналізу та усунення вузьких місць процесів підприємства (технологічних, логістичних, організаційних бізнес-процесів). Як теоретичну основу методу використано операційний аналіз ймовірнісних мереж.

Для оцінки виконання операції Op процесу МППР розглянемо наступні її параметри: середню чергу заявок до операції QOp_ср, середню завантаженість операції UOp_ср, просту операцію через відсутність коштів PMechOp, просту операцію через відсутність вхідних ресурсів PResOp:

,

,

де T END- час спостереження (тривалість інтервалу спостереження за процесом),

N- кількість виконань операції Opза час спостереження T END,

T OP- Тривалість виконання операції Op,

Tact- одиниця виміру часу,

Count_Mech_UnLock- кількість одиниць засобу, що не заблокована при виконанні поточних операцій,

Count_Mech_Use- кількість одиниць кошти, необхідне запуску операції Op,

Count_Res- поточна кількість одиниць ресурсу,

Count_Res_In- кількість одиниць ресурсу, необхідне запуску операції Op.

Аналогічно оцінки черги проводиться оцінка середнього стану ресурсів (як вхідних, так і вихідних щодо певної операціїчи правилу агента). Для оцінки використання засобу в операціях процесу розглянемо середню завантаженість засобу UMech_СР:

,

де Count_Mech_Lock - кількість одиниць засобу, заблоковане під час виконання поточних операцій,

Count_Mech – загальна кількість одиниць засобу.

Статистику функціонування агента будемо аналізувати виходячи із середньої черги заявок до агента QAg_ср та середньої завантаженості агента з обробки заявок UAg_ср:

,,

де - оператор обробки заявки (створення, видалення або блокування (включаючи зміну параметрів) заявки),

AgSolutIf - умови агента «Якщо»,

AgSolutThen - умови агента "То".

Представимо правила аналізу параметрів процесу МППР та усунення вузьких місць (правила зміни (згортки/розгортки)) у вигляді діаграм пошуку рішень (рисунок 1). Вершини графа мають такі позначення: 0 - нульове значення, М - мале значення, С - середнє значення, - високе значення відповідного об'єкта графа (черги, завантаженості або простою). Пунктирні лінії переходів графа відповідають рішенням для нульової та малої черг заявок до операції, суцільні лінії - рішенням у випадках.

В результаті проведення експерименту формується статистика виконання операцій, функціонування агентів, витрачання та формування ресурсів та заявок та використання коштів в операціях процесу МППР. За результатами аналізу експериментів діагностуються вузькі місця, приймається рішення про згортання/розгортання процесу МППР (усунення вузьких місць). Критерієм зупинення методу аналізу та усунення вузьких місць процесу перетворення ресурсів є зниження часу очікування до допустимих значень по всіх блоках.

Зміна процесу МППР здійснюється такими діями: або видаленням операції, або додаванням паралельної операції; додаванням/видаленням (збільшенням/зменшенням кількості) коштів, що використовуються операцією (операціями); збільшенням/зменшенням кількості ресурсів; додаванням чи видаленням правила агента, видаленням агента.

Рис.1. Діаграми пошуку рішень застосування правил аналізу та усунення вузьких місць процесу МППР

Метод програмно реалізований в автоматизованій системі випуску металургійної продукції (АС ВМП). Попереднім етапом роботи методу є створення та доопрацювання (модифікація) моделі процесу підприємства у модулі створення моделей процесів (СМП). На малюнку 2 представлена ​​блок-схема методу аналізу та усунення вузьких місць процесу МППР. Скорочення, що використовуються на малюнку:

ІМ – модуль інтеграції моделей;

КЗ – модуль конструктор запитів;

ОПП – модуль оптимізації процесів підприємства;

СМП – модуль створення моделей процесів;

ТБПІ – типовий постійно діючий бізнес-процес металургійного підприємства щодо зміни виробничих процесів.

Рис. 2. Загальна схема методу аналізу та усунення вузьких місць мультиагентного процесу перетворення ресурсів

Розглянемо основні етапи методу. Пропонований метод складається з наступних етапів (нумерація етапів відповідно до нумерації блоків малюнка 2).

1. Якщо модель процесу підприємства була раніше побудована в модулі ШМД, то переходимо на наступний етап. При побудові імітаційної моделі процесу підприємства (в модулі ШМД) будуються такі підмоделі:

1) генерації об'єктів (одиниць продукції (ЕП)/проектів/замовлень), такий об'єкт у моделі МППР представимо у вигляді екземпляра заявки (транзакту) з набором атрибутів;

2) процесів проходження об'єктів (технологічних, логістичних та організаційних бізнес-процесів, пов'язаних з обробкою одиниць продукції на агрегатах та устаткуванні, транспортуванні ЄП та виконанням замовлень / етапів проекту / виробничих операцій), у моделі МППР маршрут обробки заявки формується ланцюжком блоків, що складаються з перетворювачів (операцій та агентів);

3) постачання споживаних ресурсів (сировини, матеріалів і напівфабрикатів), у моделі МППР маршрут постачання ресурсів формується ланцюжком блоків, що складаються з операцій та агентів;

4) роботи коштів (верстати, устаткування, агрегати, транспорт, персонал).

2. З метою актуалізації моделі поточних процесів підприємства у модуль ОПП попередньо необхідно оновити значення змінних моделі шляхом взаємодії з модулями КЗ та ІМ.

4. Планування експерименту відповідно до висунутих гіпотез. Складання плану експериментів полягає у виборі таких вхідних (керованих) параметрів моделі, значення яких мають найбільший вплив на значення вихідних параметрів моделі, що оцінюються.

5. Імітаційні експерименти проводять у модулі ОПП. Експерименти проводяться згідно з планом експериментів до знаходження оптимального чи ефективного рішення.

6. При діагностиці вузьких місць аналізуються такі параметри процесу МППР:

1) коефіцієнт використання операції, кошти, агента;

2) середній час заявки у черзі до операції, агенту;

3) простий операції через відсутність коштів та/або вхідних ресурсів. Для оцінки динаміки роботи операції та агента аналізуються середня черга заявок до операції, агенту, а також середній стан ресурсів.

7. В результаті проведення експерименту формується статистика виконання операцій, функціонування агентів, витрачання та формування ресурсів та заявок та використання коштів в операціях процесу МППР. За результатами аналізу статистики експериментів діагностуються вузькі місця та приймається рішення про зміну (згортки/розгорнення) процесу МППР. На цьому етапі здійснюється вибір оптимального рішення.

Критерієм зупинки методу також може бути зниження часу очікування до допустимих значень по всіх блоках моделі. Даний етап спрямований на розв'язання задачі розпаралелювання паралельних процесів у часі з виробництва одиниць продукції, що входять у замовлення (замовлення) (у блоках імітаційної моделі можуть виникати ситуації з паралельною обробкою заявок).

8. Якщо на попередньому етапі було знайдено оптимальне рішення, то переходимо на 12 етап, інакше на 11 (див. малюнок 2).

9. У разі, якщо на етапі 9 не було знайдено оптимальне рішення, здійснюються коригування плану експериментів і перехід на етап 5.

10. Якщо на етапі 9 було знайдено оптимальне рішення, то здійснюється видача рекомендацій щодо зміни процесу. Цей етап ініціює запуск ТБПІ щодо вдосконалення процесу підприємства (технологічного, логістичного, організаційного бізнес-процесу) з метою усунення вузьких місць.

Метод пройшов апробацію завдання балансування ресурсів бізнес-процесу .

Висновок

Завдання розробки методу аналізу та усунення вузьких місць мультиагентного процесу перетворення ресурсів вирішене в результаті інтеграції операційного аналізу ймовірнісних мереж, мультиагентного підходу, моделі процесу перетворення ресурсів та апарату експертних систем. Розроблено правила аналізу та усунення вузьких місць (правила зміни) мультиагентного процесу перетворення ресурсів, побудовані на основі діаграм пошуку рішень. p align="justify"> Метод програмно реалізований в автоматизованій системі випуску металургійної продукції.

Робота виконана в рамках договору № 02.G25.31.0055 (проект 2012-218-03-167) за фінансової підтримки робіт Міністерством освіти і науки Російської Федерації.

Рецензенти:

Поршнєв С.В., д.т.н., професор, завідувач кафедри радіоелектроніки інформаційних систем, ФДАОУ ВПО «Уральський федеральний університет ім. першого Президента Росії Б.М. Єльцина», м. Єкатеринбург;

Доросинський Л.Г., д.т.н., професор, завідувач кафедри Теоретичних засадрадіотехніки, ФДАВУ ВПО «Уральський федеральний університет ім. першого Президента Росії Б.М. Єльцина», м. Єкатеринбург.

Бібліографічне посилання

Аксьонов К.А. МЕТОД АНАЛІЗУ І УСУНЕННЯ ВУЗЬКИХ МІСЦЬ МУЛЬТІАГЕНТНОГО ПРОЦЕСУ ПЕРЕТВОРЕННЯ РЕСУРСІВ // Сучасні проблеми науки та освіти. - 2015. - № 1-1.;
URL: http://science-education.ru/ru/article/view?id=18538 (дата звернення: 09.02.2020). Пропонуємо до вашої уваги журнали, що видаються у видавництві «Академія Природознавства»

Існує така статистика: 20% коду виконується 80% часу. Точність її
навряд чи повністю відповідає реальному стану речей, а ось загальний зміст
досить цікавий: виходить, що оптимізація всього додатку – заняття
невдячне і безглузде, а реальні результати може дати лише оптимізація тих
20% програми, які виконуються найдовше. Причому знайти ці 20% не так вже й
та складно.

У цій статті ми говоритимемо про профілюванні. Якщо вірити Вікіпедії,
профільування не що інше, як "збір характеристик роботи програми, таких
як час виконання окремих фрагментів, число правильно передбачених умовних
переходів, число кеш-промахів тощо". У перекладі російською мовою це
означає "виявлення вузьких місць програми" (або, як кажуть англофіли,
"пляшкових шийок"), а саме – всіх тих ділянок коду, на яких програма
починає "пробуксовувати", змушуючи користувача чекати.

Найпростіше профільування можна зробити голими руками (і нижче я покажу,
як це зробити), проте краще покластися на спільноту, представники якої
вже створили усі необхідні інструменти. Перший та найбільш популярний інструмент
носить ім'я GNU Profiler (або gprof). Він споконвіку використовується для
профілювання коду, що генерується компілятором GCC. Другий - GNU Coverage
testing tool (gcov), утиліта для детальнішого аналізу продуктивності.
Третій - набір інструментів налагодження та профілювання під загальним ім'ям Google
Performance Tools (скорочено GPT). Ну а четвертий – це Valgrind, який хоч
і призначений для пошуку помилок роботи з пам'яттю, але містить у своєму арсеналі
ряд утиліт для аналізу продуктивності програм.

Почнемо, як і годиться, із класики.

GNU Profiler

GNU Profiler(gprof) - один із найстаріших профайлерів, доступних для
операційних систем типу UNIX Він входить до складу пакету gcc і тому може
бути використаний для профілювання програм, написаних на будь-якому підтримуваному
їм мовою (а це не тільки C/C++, а й Objective-C, Ada, Java).

Сам по собі gprof не є інструментом профілювання, а лише дозволяє
відобразити профільну статистику, яка накопичується програмою під час
роботи (зрозуміло, за замовчуванням ніякий додаток цього не робить,
але може розпочати, якщо зібрати програму з аргументом "-pg").

Розглянемо, як це працює у реальних умовах. Щоб відчути все
переваги gprof, ми застосуємо її не до якогось абстрактного, штучно
створеному додатку, а до справжнісінькому повсякденно використовуваному. Нехай
це буде gzip.

Отримуємо та розпаковуємо вихідники архіватора:

$wget www.gzip.org/gzip-1.3.3.tar.gz
$ tar -xzf gzip-1.3.3.tar.gz
$ cd gzip-1.3.3

Встановлюємо інструменти, необхідні для збирання (в Ubuntu це робиться
через інсталяцію мета-пакету build-essential):

$ sudo apt-get install build-essential

Запускаємо конфігуратор складання, передавши у змінній оточенні CFLAGS аргумент
"-pg":

$ CFLAGS="-pg" ./configure

Компілюємо програму:

Тепер у нас є бінарник gzip, здатний вести статистику свого
виконання. Кожен його запуск супроводжуватиметься генерацією файлу gmon.out:


$ls -l gmon.out
-rw-r--r-- 1 j1m j1m 24406 2010-11-19 14:47 gmon.out

Цей файл не призначений для читання людиною, але може бути використаний для
створення докладного звіту про виконання:

$ gprof ./gzip gmon.out > gzip-profile.txt

Найважливіша частина отриманого файлу показана на скріншоті.

Кожен рядок – це статистика виконання однієї функції, стовпці – різні
Показники. Нас цікавлять перший, третій, четвертий та сьомий стовпці. Вони
відображають інформацію про загальну кількість часу, витраченого на виконання
функції (перший стовпець – у відсотках, третій – у секундах), кількості її
викликів та імені.

Спробуймо проаналізувати звіт. Першою у списку йде функція deflate,
яка була викликана лише один раз, але "зжерла" 29% всього часу виконання
програми. Це реалізація алгоритму компресії, і якби перед нами стояла
Завдання оптимізувати gzip, ми мали б почати саме з неї. 22% часу
пішло на виконання функції longest_match, але, на відміну від deflate, вона була
викликано аж 450 613 081 раз, тому кожен окремий виклик функції займав
мізерна кількість часу. Це другий кандидат на оптимізацію. Функція
fill_window забрала 13% всього часу і була викликана "всього" 22180 разів.
Можливо, й у цьому випадку оптимізація могла б дати результати.

Промотавши файл звіту до середини (до речі, відразу за таблицею йде докладна
довідка про всі її стовпці, що дуже зручно), ми дістанемося так званого
"граф викликів" (Call graph). Він є таблицею, розбиту на записи,
відокремлені один від одного пунктиром (знаками мінуса, що повторюються). Кожна
запис складається з декількох рядків, при цьому другий рядок всупереч здоровому
змісту називається "первинною" і описує функцію, якій присвячено запис.
Рядком вище розташовується опис її функції, а нижче - викликаних
їй.

Стовпці містять таку інформацію (зліва направо): індекс (index, він є
тільки у первинному рядку і, по суті, нічого не означає); відсоток часу,
який йде виконання функції (% time); кількість часу, що витрачається
її виконання в секундах (self); кількість часу, що витрачається на
виконання функції та всіх викликаних нею функцій (children); кількість викликів
функції (called) та її ім'я (name).

Граф викликів виявляється дуже корисним, коли йдеться про оптимізацію
чужого коду. Стають видно не лише вузькі місця програми, а й уся логіка
її роботи, яка може бути неочевидною щодо вихідців.

GNU Coverage testing tool

Окрім gprof, компілятор GCC має у своєму складі ще один інструмент.
профілювання, який дозволяє отримати детальніший звіт про виконання
програми. Утиліта називається gcov і призначена для генерації так
званого анотованого вихідного коду, який навпроти кожного рядка
містить кількість її виконань. Це може знадобитися для більш глибокого
вивчення проблем програми, коли функції, винні в "гальмах", знайдені, а
суть проблеми так і залишається неясна (наприклад, незрозуміло, який рядок у
багаторазово вкладеному циклі всередині довжелезної функції відповідає за
аномальне падіння продуктивності).

Gcov не може покладатися на статистику, що генерується додатком при збиранні з
прапором "-pg", і вимагає перескладання з прапорами "-fprofile-arcs" та "-ftest-coverage":

$ CFLAGS="-fprofile-arcs -ftest-coverage"
./configure && make

$ ./gzip ~/ubuntu-10.10-desktop-i386.iso

Для кожного файлу вихідного коду буде згенеровано граф викликів на основі
якого можна створити підготовлений для читання людиною анотований
вихідник:

$gcov deflate.c
File "deflate.c"
Lines executed:76.98% of 139
deflate.c:creating "deflate.c.gcov"

Отриманий файл складається з трьох колонок: кількість виконань
рядки, номер рядка та сам рядок. При цьому для рядків, що не містять коду,
першій колонці стоятиме знак мінуса, а для рядків, жодного разу не виконаних -
послідовність шарпів: #####.

Google Performance Tools

Google Performance Tools(скорочено GPT) - це розробка співробітників Google,
призначена для пошуку витоків пам'яті та вузьких місць додатків. Як і gprof,
GPT не є зовнішньою по відношенню до програми, що тестується, і
змушує її самостійно вести статистику свого виконання. Однак
використовується для цього не впроваджений на етапі складання програми код, а
бібліотеки, які можуть бути прилінковані до додатку під час складання або
підключені під час запуску.

Всього розробникам доступно дві бібліотеки, що підключаються: tcmalloc (яка,
за запевненням авторів GPT, є найшвидшою у світі реалізацією
функції malloc, а також дозволяє проводити аналіз того, як пам'ять
витрачається, виділяється і тече) і profiler, що генерує звіт про виконання
програми, на зразок gprof. Також у комплект входить утиліта pprof,
призначена для аналізу та візуалізації накопичених даних.

Вихідний код, а також rpm- та deb-пакети всього цього набору доступні на
офіційній сторінці (code.google.com/p/google-perftools), проте я б не
радив морочитися з ручною установкою, так як набір доступний
стандартних репозиторіях Fedora та Ubuntu, і його можна встановити однією простою
командою:

$ sudo apt-get install google-perftools \libgoogle-perftools0
libgoogle-perftools-dev

$ LD_PRELOAD=/usr/lib/libprofiler.so.0.0.0 \
CPUPROFILE=gzip-profile.log ./gzip \
/home/j1m/ubuntu-10.10-desktop-i386.iso

Проте самі гуглівці не радять застосовувати цей метод (очевидно через проблеми
з програмами, написаними на C++), рекомендуючи лінкувати бібліотеку під час
збирання. Що ж, не сперечатимемося.

Для експериментів візьмемо той самий gzip і повторно перезберемо його,
слинкував бинарник з потрібною бібліотекою:

$ cd ~/gzip-1.3.3
$ make clean
$./configure
$ LDFLAGS="-lprofiler" ./configure && make

Тепер gzip знову готовий вести лог свого виконання, але не робитиме цього
за замовчуванням. Щоб активувати профайлер, необхідно оголосити змінну
оточення CPUPFOFILE і присвоїти їй шлях до файлу профілю:

$ CPUPROFILE=gzip-cpu-profile.log ./gzip \
~/ubuntu-10.10-desktop-i386.iso
PROFILE: interrupts/evictions/bytes = 4696/946/91976

Як і у випадку з gprof, звіт, що вийшов, має бінарну форму і може бути
прочитаний лише з використанням спеціальної утиліти. У GPT її роль виконує
perl-скрипт pprof (в Ubuntu, щоб уникнути плутанини з іншою однойменною утилітою
він перейменований в google-pprof), який може генерувати не тільки таблиці та
анотовані вихідники на кшталт gcov, але й візуальні графи викликів. Усього
існує 11 типів виведення цієї утиліти, за кожним з яких закріплено
відповідний аргумент командного рядка:

  1. Текстовий (--text) - таблиця, подібна до висновку gprof;
  2. Callgrind (--callgrind) - висновок у форматі, сумісному з утилітою kcachegrind (з пакета valgrind);
  3. Графічний (--gv) - граф викликів, що негайно відображається на екрані;
  4. Лістинг (--list= ) - анотований лістинг зазначеної функції;
  5. Дизассембльований листинг (--disasm = ) - анотований
    дизассембльований лістинг зазначеної функції;
  6. Символьний (--symbols) - лістинг декодованих символьних імен;
  7. Графічний файл (--dot, --ps, --pdf, --gif) - граф викликів, що зберігається
    у файл;
  8. Сирий (--raw) - підготовка бінарного файлу профілю до передачі по мережі
    (перекодується за допомогою друкованих символів).

Найбільший інтерес для нас представляють текстовий ("-text") і графічний
("-gv") типи дзвінків. Тільки вони можуть надати повну інформацію про виконання
додатки та всіх його проблемних місцях. Текстовий висновок генерується наступним
чином:

$google-pprof --text ./gzip gzip-cpu-profile.log

Як видно на скріншоті, висновок є таблицею з перерахуванням всіх
функцій та витрат за їх виконання. На перший погляд вона здається дуже схожою на
таблицю, що генерується утилітою gprof, але це не так. Будучи всього лише
бібліотекою, GPT не може вести статистику виконання програми так само детально
і точно, як це робить код, впроваджений у додаток. Тому замість
запису всіх фактів виклику та виходу з функцій (поведінка програми, зібраної з
прапором "-pg"), GPT застосовує метод, який називається семплюванням. Сто разів на секунду
бібліотека активує спеціальну функцію, до завдань якої входить збір даних про
тому, в якій точці в даний момент відбувається виконання програми, та запис
цих даних у буфер. Після завершення роботи програми з цих даних формується та
записується на диск профільний файл.

Саме тому у висновку pprof немає інформації про те, скільки разів функція була
викликана за час роботи програми, або скільки відсотків часу пішло на неї
виконання. Натомість для кожної функції вказується кількість перевірок,
час яких було з'ясовано, що на даний момент програма займалася
виконанням цієї функції. Тому кількість перевірок, наведена для кожної
функції можна сміливо вважати за загальний час її виконання.

В усьому іншому таблиця сильно нагадує висновок gprof: за функцією на
рядок за показником на стовпець. Усього стовпців шість:

  1. Кількість перевірок для цієї функції;
  2. Відсоток перевірок на всі інші функції програми;
  3. Кількість перевірок для цієї функції та всіх її нащадків;
  4. Те саме число у відсотках від загальної кількості перевірок;
  5. Ім'я функції.

Спочатку такий підхід до вимірювання часу виконання здається занадто
неточним, але якщо порівняти таблиці, отримані за допомогою gprof, з таблицями
pprof, зрозуміло, що вони показують однакову картину. Більше того, GPT
дозволяє змінити кількість перевірок на секунду часу за допомогою змінної
оточення CPUPROFILE_FREQUENCY, так що точність можна збільшити в десять, сто
або тисячу разів, якщо цього вимагає ситуація (наприклад, якщо необхідно
профілювати виконання дуже невеликої програми).

Безперечною перевагою GPT перед gprof є вміння представляти
інформацію у графічному вигляді. Для активації цієї функції pprof слід
запускати з прапором "--gv" (до речі, для показу графа буде використано
однойменна утиліта):

$google-pprof --gv ./gzip gzip-cpu-profile.log

Граф викликів функцій, що генерується в результаті виконання цієї функції дуже
наочний і набагато простіший для сприйняття та вивчення, ніж аналогічний
текстовий граф, що генерується командою gprof. Ім'я та статистика виконання кожної
функції розміщені у прямокутниках, розмір яких прямо пропорційний
кількості часу, витраченому виконання функції. Усередині прямокутника
розміщені дані про те, скільки часу пішло на виконання самої функції та її
нащадків (час вимірюється у перевірках). Зв'язки між прямокутниками вказують
на черговість виклику функцій, а числові значення, вказані поруч із зв'язками -
тимчасово виконання викликаної функції та її нащадків.

Ще одна перевага GPT полягає у здатності використовувати різні рівні
деталізації для виведення даних, дозволяючи користувачеві самому вибирати одиниці
дроблення. За умовчанням як така одиниця використовується функція, тому
будь-який висновок pprof логічно поділений на функції. Однак за бажання як
одиниці дроблення можна використовувати рядки вихідного коду (аргумент "-lines"),
файли ("--files") або навіть фізичні адреси пам'яті ("--addresses"). Завдяки
такої функціональності GPT дуже зручно використовувати для пошуку вузьких місць у
великих додатках, коли спочатку ти аналізуєш продуктивність на рівні
окремих файлів, потім переходиш до функцій і, нарешті, знаходиш проблемне
місце на рівні вихідного коду чи адрес пам'яті.

І останнє. Як я вже говорив вище, GPT - це не тільки хороший профайлер,
але і інструмент для пошуку витоків пам'яті, тому у нього є один дуже
приємний побічний ефектяк здатність до аналізу споживання пам'яті
додатком. Для цього програма має бути зібрана або запущена з підтримкою
бібліотеки tcmalloc, а в змінну HEAPPROFILE записана адреса для розміщення
профільного файлу Наприклад:

$ LD_PRELOAD=/usr/lib/libtcmalloc.so.0.0.0 \
HEAPPROFILE=gzip-heap-profile.log \
./gzip ~/ubuntu-10.10-desktop-i386.iso
Starting tracking the heap
Dumping heap profile to gzip-heap-profile.log.0001.heap (Exiting)

До отриманого файлу буде додано закінчення 0000.heap. Якщо нацькувати на
цей файл утиліту pprof і вказати прапор "--text", вона виведе на екран таблицю
функцій та рівень споживання пам'яті кожної з них. Стовпці означають все те ж саме
саме, що й у разі звичайного профілювання, з тим винятком, що замість
кількості перевірок та їх процентних відносин таблиця тепер містить кількість
споживаної пам'яті та відсоток від загального споживання пам'яті.

При необхідності цю інформацію можна отримати у графічному вигляді, а також
змінити одиниці дроблення. Бібліотека може бути налаштована за допомогою різних
змінних оточення, найкорисніша з яких носить ім'я HEAP_PROFILE_MMAP.
Вона включає профіль для системного виклику mmap (за промовчанням GPT
збирає статистику тільки для викликів malloc, calloc, realloc та new).

Пара слів про Valgrind

В останній частині статті ми коротко розглянемо способи використання
інструменту Valgrindдля профілювання програм. Valgrind – це дуже потужний
відладчик пам'яті, який здатний знайти такі помилки роботи з пам'яттю, про які
інші утиліти навіть не підозрюють. Він має модульну архітектуру, яка з
протягом часу дозволила йому обрости кількома плагінами, що не належать
безпосередньо до налагодження. Усього таких плагіна три:

  1. Cachegrind - дозволяє збирати статистику з потрапляння даних та
    інструкцій програми в кеш першого та другого рівнів процесора (потужний та
    складний інструмент, який корисний при виконанні профілювання
    низькорівневого коду).
  2. Massif - профайлер купи, схожий за функціональністю з аналогом із пакета GPT.
  3. Callgrind - профайлер, багато в чому схожий на такий у gprof та GPT.

За умовчанням як основний плагін Valgrind використовує memcheck
(налагодження пам'яті), тому для його запуску в режимі профілювання необхідно
вказати потрібний плагін вручну. Наприклад:

$ valgrind --tool = callgrind ./program

Після цього у поточному каталозі буде створено файл з ім'ям
callgrind.out.PID-програми, який можна проаналізувати за допомогою утиліти
callgrind_annotate або графічної програми kcachegrind (встановлюється
окремо). Я не розписуватиму формат генерованих цими програмами даних
(він добре представлений в однойменних man-сторінках), скажу лише, що
callgrind_annotate краще запускати з прапором "--auto", щоб він зміг
самостійно знайти файли вихідних текстів програми.

Для аналізу витрати пам'яті Valgrind слід запускати з аргументом "-tool=massif".
Після цього в поточному каталозі з'явиться файл massif.out.PID-програми, який
може бути проаналізовано за допомогою утиліти ms_print. На відміну від pprof, вона
вміє виводити дані у вигляді стандартної таблиці, а й генерувати
красиві графіки ascii-art.

Висновки

Такі інструменти, як gprof, gcov та GPT, дозволяють провести аналіз роботи
програми та виявити всі його вузькі місця аж до окремої процесорної
інструкції, а підключивши до процесу профілювання ще й Valgrind, можна досягти
дивовижних результатів.

INFO

gprof за промовчанням не виводить профільної інформації для функцій
бібліотеки libc, але ситуацію можна виправити, встановивши пакет libc6-prof та
зібравши тестоване з бібліотекою libc_p: "export LD_FLAGS="-lc_p"".

Активувати профайлер GPT можна не лише за допомогою змінного оточення
CPUPROFILE, але й обрамивши ділянку коду, що тестується, функціями ProfilerStart()
та ProfilerStop(), які оголошені у google/profiler.h.

WARNING

Через вимоги до безпеки GPT не спрацює щодо додатків з
встановленим бітом SUID.