Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!

Ранее в заметке Профилирование кода на C/C++ в Linux и FreeBSD вскользь упоминалось, что аналогом perf из мира Linux во FreeBSD является утилита pmcstat. Однако не сообщалось, как именно этим pmcstat пользоваться, просто потому что на тот момент я этого и не умел. Не так давно, благодаря помощи со стороны Федора Сигаева, мне все-таки удалось осилить pmcstat. А теперь, благодаря помощи с моей стороны, осилить удастся и вам!

Некоторое время назад мы с вами научились пользоваться DTrace. SystemTap представляет собой нечто похожее, но сильно заточенное под Linux и с рядом важных отличий. Во-первых, SystemTap не требует ручного добавления пробов в код ядра или приложений. Он работает и так, правда, требуя взамен знания исходников. Во-вторых, скрипты SystemTap транслируются в язык C и загружаются в ядро в виде модулей. За это приходится платить временем компиляции скриптов. Зато скриптовый язык SystemTap намного мощнее, чем у DTrace.

DTrace — это такая штука, присутствующая во FreeBSD, NetBSD, MacOS, Solaris и Linux. DTrace предназначен для динамической трассировки ядра системы и приложений в реальном времени, главным образом с целью их профайлинга и отладки. Сегодня мы попробуем поработать с DTrace во FreeBSD. Кроме того, мы установим DTrace и в Ubuntu, хотя по поводу стабильности такой конфигурации и остаются вопросы.

Рассмотрим типичную ситуацию — приходит пользователь и говорит «я делаю в приложении то-то и то-то и у меня все сильно тормозит». Как понять, в чем проблема, и исправить ее? Вот об этом мы и поговорим в данной заметке. Приведенный список методов не претендует на полноту, однако это то, что в настоящее время я чаще всего использую на практике. Несмотря на то, что пишу я сейчас в основном на C, описанные методы будут также применимы в проектах, использующих С++, и, возможно, другие языки программирования.

Любые сайтики и бэкенды должны писать метрики, это бесспорно. Однако возникает вопрос, куда именно их писать. Есть неплохие SaaS решения, например, Datadog. Но Datadog на момент написания этих строк стоял 15$ в месяц за один хост. При определенном количестве хостов в какой-то момент вы можете обнаружить, что 30% стоимости всей инфраструктуры приходится на метрики. В связи с чем возникает желание перевести все на self hosted решение. О том, как поднять такой вот self hosted недо Datadog, и пойдет речь в посте.

Рантайм Go содержит встроенный профайлер, но по умолчанию он выключен. Существует несколько способов его эксплуатации, самый «низкоуровневый» — через библиотеку runtime/pprof. Russ Cox, один из главных разработчиков Go, разместил хорошую статью по ее использованию. Однако я бы порекомендовал пакет-обертку profile, он чуть проще в настройке.

Редкое серьезное приложение в наши дни обходится без кэширования чего-либо. Какой-нибудь LRU кэш элементарно реализуется, например, при помощи хэш-таблиц и двусвязных списков. Но не факт, что ваше решение будет отличаться особой эффективностью, поэтому лучше воспользоваться готовой реализацией. Часто в качестве такой реализации рекомендуют Guava или LruMap из twitter-util. Но у этих решений есть свои минусы, в частности, стэк Twitter’а традиционно привязывает вас к Scala 2.10, а Guava просто страшна.

Чем больше метрик вы пишите, тем лучше. Метрики помогают найти в программе места, нуждающиеся в оптимизации. По метрикам вы можете понять, что именно послужило причиной сбоя в ночь с субботы на воскресенье. Если в очередном билде имеется баг, который не удалось найти в тестовом окружении, вы сразу же узнаете об этом во время выкатки. Одним из наиболее распространенных решений для сбора метрик является Graphite.

Ни для кого не секрет, что программисты очень любят бенчмарки. Ведь что может быть лучше, чем взглянуть на пару графиков, а потом с умным видом рассуждать о том, что Common Lisp быстрее PHP, а игры под FreeBSD идут быстрее, чем под Linux? А тем временем многие небезосновательно полагают, что бенчмаркам вообще нельзя верить. Я бы не был уж настолько категоричен, но на самом деле в этом есть существенная доля правды. Давайте разберемся, почему.