Брендан Грег (Brendan Gregg), один из разработчиков DTrace, представил (http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-perf.../) проект FlameGraph (https://github.com/brendangregg/FlameGraph), одна из областей использования которого связана с выявлением узких мест, влияющих на производительность ядра Linux. FlameGraph создан как средство для наглядной визуализации проблемных мест в ядре, потребляющих наибольшее число процессорных ресурсов. Код проекта написан на языке Perl и открыт (https://github.com/brendangregg/FlameGraph) под лицензией CDDL.
В качестве исходных данных поддерживается сбор информации о состоянии системы через такие механизмы, как DTrace, perf_events и SystemTap. Практически, FlameGraph может визуализировать не только статистику работы ядра, но и данные о выполнении любых приложений, которые могут быть получены при помощи вышеотмеченных инструментов DTrace, perf_events и SystemTap. На графиках также могут быть проанализированы сетевые операции, файловый ввод/вывод, статистка выполнения процессов и другие данные. Результаты анализа генерируются в виде графика, экспортируемого в формате SVG.
Формирование графика производится в три этапа: накопление данных, сброс накопленной статистики и создание графика. Например:
<font color="#461b7e">
perf record -a -g -F 1000 sleep 60
perf script | ./stackcollapse-perf.pl > out.perf-folded
cat out.perf-folded | ./flamegraph.pl > perf-kernel.svg
</font>Последний этап можно расширить, отфильтровав только интересующую информацию (например, статистику по потреблению CPU, работе ext4 или определённым системным вызовам):
<font color="#461b7e">
grep -v cpu_idle out.perf-folded | ./flamegraph.pl > nonidle.svg
grep ext4 out.perf-folded | ./flamegraph.pl > ext4internals.svg
egrep 'system_call.*sys_(read|write)' out.perf-folded | ./flamegraph.pl > rw.svg
</font>Как правило в результате работы DTrace, perf_events и SystemTap накапливается большой объем данных. Обобщённую информацию можно получить при помощи команды "perf report", но результаты достаточно трудны для анализа, так как отчёт создаётся в текстовом представлении, как правило на нескольких страницах, которые невозможно сразу охватить взглядом и требуется сопоставление относительных процентов. В случае FlameGraph данные представлены на одном экране с выделением цветом проблемных мест и возможностью получения подробностей при наведении курсора на интересующую область.
<center><img src="http://www.opennet.me/opennews/pics_base/0_1332238711.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
Для сравнения, часть вывода "perf report":<center><img src="http://www.opennet.me/opennews/pics_base/0_1332238884.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-perf.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33403
Я джва года этого ждал. Нет, серьезно, я заколебался в цифры втыкать, графики для обзора ситуации в целом - самое то.
Графики - !Ъ. Вывод в консоль с последующим разбором скриптами - Ъ!
> Графики - !Ъ.Особенно ASCII-графики =)
А чё?! http://i32.fastpic.ru/big/2012/0320/b8/e7d11e9fc4a73a07cd95b...
> А чё?! http://i32.fastpic.ru/big/2012/0320/b8/e7d11e9fc4a73a07cd95b...Вам все хиханьки, а я вполне серьёзно.
У меня в свое время лог зашумленности сети велся как-то так:
|********** | 40%
|**** | 20%
|******* | 30%
|***** | 25%
...2d график, поддающийся парсингу и аналитике =)
Народ, кто в курсе, данные позволяют получать такой же подробный отчет как после Devel::NYTProf ?
Это ж трейс ядра, а не Perl.
Я как раз щас плотно занимаюсь трейсом Perl на Systemtap - но результаты не радуют, честно сказать - до Devel::NYTProf там как до Луны... :(
>Это ж трейс ядра, а не Perl.Я все понимаю. Ну а вопрос был про уровень детализации и Devel::NYTProf здесь упомянут лишь для сравнения (Perl тут не при чем).
>Я как раз щас плотно занимаюсь трейсом Perl на Systemtap - но результаты не радуют, честно сказать - до Devel::NYTProf там как до Луны... :(
Благодарю за ответ.
CDDL… Благодаря этой лицензии этот проект проанализируют и перепишут под GPL… как это было с ZFS :)Неужели сторонники GPL настолько фанатики лицензии?
Неужели они не могут взять и использовать модуль ядра, который написан под лицензией CDDL?
После перехода GCC на GPLv3 от этого компилятора отказалась BSD, а после — Apple… А потом LLVM стал более популярным, чем GCC
> CDDL… Благодаря этой лицензии этот проект проанализируют и перепишут под GPL…
> как это было с ZFS :)
> Неужели сторонники GPL настолько фанатики лицензии?
> Неужели они не могут взять и использовать модуль ядра, который написан под
> лицензией CDDL?
> После перехода GCC на GPLv3 от этого компилятора отказалась BSD, а после
> — Apple… А потом LLVM стал более популярным, чем GCCИногда интересно узнать, что было бы с IT, если бы не было Столлмана с его твердостью убеждений.
> Неужели сторонники GPL настолько фанатики лицензии?
> Неужели они не могут взять и использовать модуль ядра, который написан под
> лицензией CDDL?Неужели сторонники EULA настолько фанатики лицензии?
Неужели пожилая учительница не может просто взять и использовать копию Windows, не отдавая американским корпорациям последние деньги?> А потом LLVM стал более популярным, чем GCC
Х(
>> Неужели сторонники GPL настолько фанатики лицензии?
>> Неужели они не могут взять и использовать модуль ядра, который написан под
>> лицензией CDDL?
>Неужели сторонники EULA настолько фанатики лицензии?
>Неужели пожилая учительница не может просто взять и использовать копию Windows, не отдавая американским корпорациям последние деньги?+1. Лучшего ответа не найти.
