Предыстория
В октябре 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 a 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 было найдено оптимальное решение, то осуществляется выдача рекомендаций по изменению процесса. Данный этап инициирует запуск ТБПИ по совершенствованию процесса предприятия (технологического, логистического, организационного бизнес-процесса) с целью устранения узких мест.

Метод прошел апробацию на задаче балансировки ресурсов бизнес-процесса .

Заключение

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

Работа выполнена в рамках договора № 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% всего времени и была вызвана "всего" 22 180 раз.
Возможно, и в этом случае оптимизация могла бы дать результаты.

Промотав файл отчета до середины (кстати, сразу за таблицей идет подробная
справка обо всех ее столбцах, что очень удобно), мы доберемся до так называемого
"графа вызовов" (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.