Анализ и профилирование многопоточного приложения

Question

У нас есть многопоточное приложение, которое выполняет тяжелую обработку пакетов на нескольких этапах конвейера.Приложение находится на C под Linux.

Все приложение работает нормально и не имеет утечек памяти или проблем с безопасностью потоков.Однако, чтобы проанализировать приложение, как мы можем профилировать и анализировать потоки?

В частности, вот что нас интересует:

1. использование ресурсов каждым потоком
2. частота и временные характеристики, с которыми у потоков возникали претензии на получение блокировок
3. Количество накладных расходов из-за синхронизации
4. любых узких мест в системе
5. Какую лучшую пропускную способность системы мы можем получить

Что такоелучшие методы и инструменты доступны для того же?

Answer 1

Взгляните на Intel VTune Amplifier XE (ранее… Intel Thread Profiler), чтобы узнать, отвечает ли он вашим потребностям. Этот и другие средства разработки Intel Linux доступны бесплатно для некоммерческого использования .

В видео Использование временной шкалы в Intel VTune Amplifier XE демонстрируется временная шкала многопоточного приложения. Презентатор использует графический дисплей для отображения активности lock и того, как вырыть строку источника конкретной блокировки, вызывающей сериализацию. В 9:20 докладчик упоминает "с помощью API кадров вы можете программно отмечать определенные события или фазы в вашем коде. И эти отметки появятся на временной шкале."

Answer 2

Я работал над подобной системой несколько лет назад.Вот как я это сделал:

Шаг 1. Избавьтесь от ненужных хронометристов в отдельных темах.Для этого я использовал эту технику .Это важно сделать, потому что общая система обмена сообщениями ограничена скоростью ее частей.

Шаг 2. Эта часть - тяжелая работа, но она окупается.Для каждого потока выведите журнал с отметкой времени, показывающий, когда каждое сообщение было отправлено, получено и обработано.Затем объедините журналы в единую временную шкалу и изучите ее.То, что вы ищете, это: а) ненужные повторные передачи, например, из-за тайм-аутов, б) дополнительная задержка между моментом получения сообщения и его обработкой.Это может произойти, например, если у потока есть несколько сообщений в его входной очереди, некоторые из которых могут быть обработаны быстрее, чем другие.Имеет смысл сначала обработать их.

Возможно, вам придется переключаться между этими двумя.

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

Answer 3

Есть ли у вас гибкость для разработки под Darwin (OSX) и развертывания в Linux? Инструменты анализа производительности превосходны и просты в использовании ( Shark и Thread Viewer полезны для ваших целей).

Конечно, существует много инструментов для повышения производительности Linux. gprof, Valgrind (с Cachegrind, Callgrind, Massif) и Vtune будут делать то, что вам нужно.

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

Answer 4

1) Не знаю. Для linux доступно несколько профилировщиков.

2) Если вы работаете с конвейером, каждый этап должен выполнять достаточную работу, чтобы обеспечить минимальное количество конфликтов в очередях P-C. Вы можете выяснить это с некоторыми временами - если этап занимает 10 мс + для обработки пакета, вы можете забыть о проблемах конкуренции / блокировки. Если это занимает 100 мкс, вы должны рассмотреть возможность объединения пары этапов, чтобы каждый этап выполнял больше работы.

3) То же, что (2), если только не существует отдельной проблемы синхронизации с некоторыми глобальными данными или чем-то еще.

4) Было бы полезно записывать / регистрировать очереди каждую секунду. Самая длинная очередь будет перед сценой с самой узкой шеей.

5) Понятия не имею - не знаю, как работает ваша текущая система, на каком оборудовании она работает и т. Д. Есть несколько «нормальных» оптимизаций - устранение вызовов диспетчера памяти с пулами объектов, добавление дополнительных потоков к этапам с самыми тяжелыми Загрузка процессора и тому подобное, но «какая пропускная способность системы лучшая из всех, что мы можем получить» - слишком сложно сказать.