В 2015-м я написал об инструментарии, который Ruby предоставляет для обнаружения управляемых утечек памяти. В основном статья рассказывала о легко управляемых утечках. На этот раз я расскажу об инструментах и хитростях, которые вы можете применять для ликвидации утечек, которые в Ruby не так легко проанализировать. В частности, я расскажу о mwrap, heaptrack, iseq_collector и chap.
Читать полностью »
Разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. Базы данных из универсальных промышленных монстров переродились в узконаправленные. Docker изменил взгляд на деплой. Но изменилось ли наше представление о логах?
Одна из больших проблем в Яндекс.Вертикалях были логи — 18 ТБ в день и 250 000 логов в секунду, все пишется в файлы. Логи разнородные, потому что много языков: Scala, Java, Python, Go. Потом их собирает Fluent Bit, пишет в Kafka, на одной железной машине работают обработчики, собирают из Kafka и пишут всё на диск. При этом это уже третья версия логов.
Как следствие, возникает проблема долгого поиска. По этим логам поиск идет с помощью grep. На некоторых сервисах grep может достигать часов. Если у вас есть проблемы в продакшн, вы не будете часами искать свои логи. Чтобы решить проблему, в Яндекс решили написать свой велосипед доставки логов для поиска. Что из этого получилось, расскажет Алексей Данилов (danevge) — разработчик команды инфраструктуры в Яндекс.Вертикалях. Разрабатывает, пишет и поддерживает проекты auto.ru и Яндекс.Недвижимость.
Дисклеймер. Статья рассказывает о современной разработке и подходит для микросервисной архитектуры. Здесь представлены различные продукты — это инструменты, которые используют в Яндекс.Вертикалях. Под другие условия возможны аналоги удачнее, но они выполняют практически те же функции.Читать полностью »
Кажется, у меня появилась привычка писать о мощных машинах, где множество ядер простаивают из-за неправильных блокировок. Так что… Да. Опять про это.
Эта история особенно впечатляет. В самом деле, как часто у вас один поток несколько секунд крутится в цикле из семи команд, удерживая блокировку, которая останавливает работу 63 других процессора? Это просто восхитительно, в каком-то ужасном смысле.
Вопреки распространённому мнению, у меня на самом деле нет машины с 64 логическими процессорами, и я никогда не видел этой конкретной проблемы. Но с ней столкнулся мой друг, этот ботан зацепил меня он попросил о помощи, и я решил, что проблема достаточно интересная. Он выслал трассировку ETW с достаточным количеством информации, чтобы коллективный разум в твиттере быстро решил проблему.
Читать полностью »
Для отладки PHP-программ часто используют Xdebug. Однако стандартных возможностей IDE и Xdebug не всегда достаточно. Часть проблем можно решить с помощью Xdebug proxy — pydbgpproxy, но всё же не все. Поэтому я реализовал PHP Xdebug proxy на базе асинхронного фреймворка amphp.
Под катом я расскажу, что не так с pydbgpproxy, чего в нём не хватает и почему я не стал его дорабатывать. Также объясню, как работает PHP Xdebug proxy, и покажу на примере, как его расширять.Читать полностью »
Представляем вашему вниманию третью часть перевода материала о пути, который прошла компания Dropbox, внедряя у себя систему проверки типов Python-кода.
→ Предыдущие части: первая и вторая
Читать полностью »
Коллеги, считаю полезным рассказать об удобном и бесплатном профилировщике кода для Linux/Solaris. Он входит в пакет Sun/Oracle Developer Studio [1]. По моему мнению, другие части этой среды разработки несколько бесполезны, но профилировщик, который называется Performance Analyzer, очень удачный. Он прост в использовании, наглядно и удобно устроен анализ результатов. На мой взгляд, профилировщик все еще превосходит многие аналоги под Linux. При наличии этого инструмента использование gprof видится странной прихотью и потерей времени.
Если вы не планируете использовать Performance Analyzer немедленно, то дальше можно не читать. Просто запомните, что такой продукт существует. Если же интересно взглянуть, то добро пожаловать.
Сегодня публикуем вторую часть перевода материала о том, как в Dropbox организовывали контроль типов нескольких миллионов строк Python-кода.
Сегодня мы предлагаем вашему вниманию первую часть перевода материала о том, как в Dropbox занимаются контролем типов Python-кода.
В Dropbox много пишут на Python. Это — язык, который мы используем чрезвычайно широко — как для бэкенд-сервисов, так и для настольных клиентских приложений. Ещё мы в больших объёмах применяем Go, TypeScript и Rust, но Python — это наш главный язык. Если учитывать наши масштабы, а речь идёт о миллионах строк Python-кода, оказалось, что динамическая типизация такого кода неоправданно усложнила его понимание и начала серьёзно влиять на продуктивность труда. Для смягчения этой проблемы мы приступили к постепенному переводу нашего кода на статическую проверку типов с использованием mypy. Это, вероятно, самая популярная самостоятельная система проверки типов для Python. Mypy — это опенсорсный проект, его основные разработчики трудятся в Dropbox.
Dropbox оказалась одной из первых компаний, которая внедрила статическую проверку типов в Python-коде в подобном масштабе. В наши дни mypy используется в тысячах проектов. Этот инструмент бесчисленное количество раз, что называется, «проверен в бою». Нам, для того, чтобы добраться туда, где мы находимся сейчас, пришлось проделать долгий путь. На этом пути было немало неудачных начинаний и провалившихся экспериментов. Этот материал повествует об истории статической проверки типов в Python — с самого её непростого начала, которое было частью моего научного исследовательского проекта, до сегодняшнего дня, когда проверки типов и подсказки по типам стали привычными для бесчисленного количества разработчиков, которые пишут на Python. Эти механизмы теперь поддерживаются множеством инструментов — таких, как IDE и анализаторы кода.
Читать полностью »
Если вы когда-нибудь занимались программированием, то знакомы с концепцией багов. Если бы они нам не досаждали, процесс разработки стал бы намного быстрее и приятней. Но эти баги просто ждут момента, чтобы испортить наш код, рабочий график и творческий поток. К счастью, существует множество инструментов и стратегий для уничтожения багов даже в коде программистов ретро-игр.
Один из лучших способов отладки кода — использование отладчика. В некоторых версиях эмуляторов FCEUX и Mesen есть встроенный отладчик, позволяющий прерывать в любой момент времени выполнение программы для проверки работоспособности кода.
Отладчик эмулятора FCEUX
Стоит заметить, что этот способ больше подходит для продвинутых программистов, работающих с языком ассемблера. Но мы новички, поэтому будем писать на языке C (cc65). Разумеется, компилятор станет играть по своим собственным правилам, и нам будет трудно разбираться с машинным кодом, скомпилированным из кода на C.
Читать полностью »
В среде SRE-/DevOps-инженеров никого не удивишь, что однажды появляется клиент (или система мониторинга) и сообщает, что «всё пропало»: сайт не работает, оплаты не проходят, жизнь — тлен… Как бы ни хотелось помочь в такой ситуации, сделать это без простого и понятного инструмента бывает очень сложно. Зачастую проблема скрыта в коде самого приложения — нужно лишь локализовать её.
Так сложилось, что мы уже весьма давно и сильно полюбили New Relic. Он был и остаётся отличным средством для мониторинга производительности приложения, а также позволяет инструментировать микросервисную архитектуру (с помощью своего агента) и многое-многое другое. И всё могло быть замечательно, если бы не изменения в ценовой политике сервиса: его стоимость с 2013 года выросла в 3+ раза. Вдобавок, с прошлого года для получения trial-аккаунта требуется общение с персональным менеджером, что затрудняет презентацию продукта потенциальному заказчику.Читать полностью »
