Отладка *

Загадка базы данных

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.

«Давайте попробуем B-дерево», — предложил я.

«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»

Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.

В итоге мы реализовали B-дерево. Результаты удивили всех...

Программы часто отлаживают применяя printf-отладку.
Однако в этом есть недостаток. Со временем вывод printf сообщений становится настолько частыми и плотным, что становится просто невозможно что-либо прочитать.

Чтобы с этим бороться придумали уровни логирования Log Levels.

Суть в том, чтобы из shell консоли в run time можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.

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

В процессе моих изысканий о том как-же создавть изображения локально, я столкнулся с неочевидной, для себя, проблемой в виде колоссального потребления VRAM, которое не сходилось с тем что написано в карточках моделей и в интернете.

Я попытался разобраться на примере современной FLUX.2-dev. Чтобы хотябы теоретически влезать в доступную мне VRAM на моем оборудовании я выбрал вариант GGUF Q4_K_M. И вот тут началось все самое интересное.

В этой статье, про ИИ, написанной не полностью ИИ, про генерацию изображений - не будет изображений.

В конце этой статьи мы будем запускать эту модель на указанном чипе, но начнем мы с чуть более мощного - он понадобиться чтобы разобраться с проблемой.

Первая проблема с которой я столкнулся - это потребление памяти. Поиски в интернете, описание самой модели говорили о том что она должна помещаться в ~10GB VRAM. Чего должно с запасом хватать для Apple M1 16GB. Однако фактическое зафиксированное потребление памяти составило 21 GB, не зафиксированное 28 GB (после чего я и начал исследование).

Excel не единственный, кто любит превращать любые данные в даты.

Если вы работаете с датами в JavaScript, то, вероятно, рано или поздно пользовались new Date(someString). Это удобно: передаём строку, получаем объект Date. Но привыкнув к Python, я был удивлён тем, насколько свободно JavaScript обращается с форматами дат. Позвольте мне проиллюстрировать это примерами.

Всё началось с тупой идеи. 

У меня есть мышь Logitech MX Vertical, которая постоянно перемещается между моей домашней машиной, рабочим ноутбуком и другими устройствами. Однажды я задумался: у этой штуки есть флэш-память. Она обязана быть, иначе как мышь запоминает настройку DPI между подключениями? А можно ли в этой памяти хранить что-то ещё?

Ага, мне было скучно.

Я решил использовать мышь в качестве крошечного USB-накопителя. Так как она физически перемещается между компьютерами, то, строго говоря, способна и переносить между ними данные.

3 дня борьбы с ROCm, RX580 и Ollama: как я запустил LLM на домашней видеокарте

Я попытался запустить LLM inference на старой AMD RX580 через ROCm и Ollama в Kubernetes. GPU определялся, VRAM занималась, контейнеры запускались — но inference падал с ошибками hipMemGetInfo, а иногда просто выдавал бессмысленный текст.

В статье — полный инженерный разбор:как диагностировать реальный GPU compute (а не просто VRAM usage), почему Vulkan помог найти root cause, какие версии ROCm и kernel оказались рабочими, и как добиться стабильной генерации ~42 tokens/sec на RX580.

Всем привет!

Традиционное вступление в стиле "плач Ярославны": GlobalPlatform, ISO 7816, JavaCard и прочие смежные стандарты - боль. Тонна материала написанная сухим языком так и навивает мысль, что авторы этого всего не инженеры, а юристы. Для примера скажу, что каждый стандарт ETSI начинается со смысловых определений глаголов "shall", "shall not", "should", "should not" и т.д. Нет, в канцелярском стиле ничего плохого нет. Плохо становится когда он плавно переходит поросячью латынь - и это одно из самых терпимых определений. Это же додуматься надо "размазать" требования к несчастной SMS-ске между пятью стандартами (ETSI 102-223/-225/-226 и 131-111/-115).

Ну вот ты преодолел пучины стандартов, затем засел за написание JavaCard-апплета, с чем тоже успешно справился, ну а дальше начинается квест "найди все тулзы". Инструментарий от Oracle для сборки .cap-файлов недоступен из России, благо есть один удобный в открытом доступе. Там же рядышком лежит тулза для установки/удаления апплетов (да и вообще управления жизненным циклом карты).

Итак, ты скомпилировал и загрузил апплет на карту. Классно! А дальше? А дальше поговорим в статье.

Ты понимаешь, что баг хорош, если первым делом думаешь: «Как это вообще может происходить?»

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

Разумеется, сначала я обвинил в этом React.

Да, конечно, в современном веб-приложении может быть множество потенциальных причин проблем с производительностью: сторонний JavaScript, перегруженные серверы, раздутые ресурсы, отсутствующие индексы базы данных; список можно продолжать очень долго. Но опыт десятков лет разработки для веба подсказывал мне, что это была проблема фронтенда. Я просто чувствовал это. При загрузке страница дёргалась. И несмотря на то, что экосистема React сегодня — наименее плохой выбор для веб-фронтенда, она по разным причинам может оказаться хаотичной и тормозной.

Чтобы подтвердить свою теорию, я рассказал Claude¹, что загрузка дэшборда тормозит и что проблемы наверняка в React, попросив проанализировать их и ранжировать по степени серьёзности. Конечно же, Claude обнаружил в React кучу подозрительных аспектов — ненужный повторный рендеринг, отсутствующие мемоизации и так далее. К тому же он подсказал, что мы всё ещё не используем React Compiler. Я попросил Claude выполнить первый проход решения самых простых и самых серьёзных проблем React, но…

Практически ничего не поменялось. Возможно, дело всё-таки не в React.

Итак, я закатал рукава и начал тщательное расследование.

В прошлом месяце я исследовал периодически возникающие всплески задержек в нашем сервисе отчётности и обнаружил нечто, заставившее меня не поверить своим глазам: 102 потока блокировалось одновременно, и все они ждали одной блокировки. Причиной этого оказалась одна строка кода, выглядевшая совершенно невинно.

Это история о том, как DatatypeFactory.newInstance() поставил на колени наш высокопроизводительный Java-сервис, и об удивительно простом решении, позволившем полностью избавиться от проблемы.

На прошлой неделе я попросил Claude устранить однострочный баг. Ему понадобилось 23 тысячи токенов. Потом тот же баг я попросил устранить Gemini. Он потратил 350 тысяч токенов. Да уж, на такое невозможно закрывать глаза.

Поэтому я написал Context Lens — трассировщик контекста, перехватывающий вызовы LLM API, чтобы показать, что же на самом деле находится в окне контекста с разбивкой по этапам. Я подключил его к четырём инструментам кодинга и дал им одну и ту же задачу. Результаты оказались настолько разными, что я решил написать об этом статью.

Вопрос

При работе с этими моделями мы платим за токены. Токены — это довольно сложная тема. По сути, это блоки информации; 1 токен приблизительно равен 4 символам английского текста. Чем больше токенов передаётся в модель, тем больше мы платим.

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

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

В релизе 1.26 языка Go, выпущенном в этом месяце, есть полностью переписанная подкоманда go fix. Go fix использует набор алгоритмов для обнаружения возможностей улучшения кода; часто для этого применяются более новые фичи языка или библиотеки. В этом посте мы сначала покажем, как использовать go fix для модернизации кодовой базы на Go. Во второй части статьи мы расскажем о лежащей в основе этой подкоманды инфраструктуре и её эволюции. В третьей части мы познакомим вас с тематикой инструментов анализа с «самообслуживанием», которые помогают мейнтейнерам модулей и организациям кодироовать собственные правила и рекомендации.

Появился открытый инструмент Coding Agent Explorer — обратный прокси-сервер, который в реальном времени показывает всё общение между вашим ИИ-агентом (пока только Claude Code) и API Anthropic. Вы видите системные промпты, последовательность вызовов инструментов, токены (включая кэш), мышление агента шаг за шагом. Запускается за пару минут, работает локально, ключи маскируются автоматически.

Признаюсь, я питаю слабость к классическому DOOM. Игре уже 31 год, но благодаря открытому исходному коду она живёт на всём — от смартфонов до осциллографов. В силу разных обстоятельств я стал сопровождать несколько пакетов, связанных с DOOM, в Fedora Linux.

Перед каждым релизом Fedora проводит массовую пересборку всех пакетов — и в этот раз chocolate-doom её не пережил. Виновник этому — маленький bool.

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

13 февраля глобальное сообщество отмечало День радио. Этот знаменательный праздник на мировом уровне начали отмечать совсем недавно, с 2011 года, согласно резолюции 36 C/63 Генеральной конференции ЮНЕСКО. У нас в стране его празднуют вот уже более века, а сама дата приурочена к 25 апреля (7 мая) 1895 года, когда российский физик Александр Степанович Попов на заседании Русского физико-химического общества продемонстрировал «прибор, предназначенный для показывания быстрых колебаний в атмосферном электричестве».

У ST есть утилита STM32CubeMonitor , которая позволяет по SWD/JTAG следить за конкретными переменными в физической памяти (REG, RAM, ROM) микроконтроллера.

Передаешь STM32CubeMonitor *.elf файл и подключаешь по SWD Target. Причем эта Tool(а) позволяет строить графики по значениями переменных в памяти. Это как утилита ArtMoney в случае с взломом компьютерных игр на PC, только для микроконтроллера.

STM32CubeMonitor удобна при отладке систем автоматического управления (ПИД регуляторы), цифровых фильтров, триггеров Шмитта и прочей DSP обработки.

В разработке на микроконтроллерах широко распространены J-link программаторы-отладчики. Также доступно клиентское ПО для них Ozone. У J-link есть 20 пиновый разъём. На нем заложены пины для шины SWD и UART. SWD это - двухпроводной полудуплексный интерфейс для программирования микроконтроллеров.

В этой заметке я расскажу как прошить микроконтроллер STM32 по SWD шине при помощи программатора J-link.

Что такое Moltbook, и почему она привлекла наше внимание?

Странная футуристическая соцсеть Moltbook быстро стала виральной как форум, на котором могут публиковать посты и общаться ИИ-агенты. Но обнаруженное нами рассказывает иную историю и позволяет взглянуть на то, что происходит, когда приложения пишут вайб-кодингом без должного соблюдения мер безопасности.

Мы выявили принадлежащую Moltbook неправильно сконфигурированную базу данных Supabase, обеспечивающую полный доступ на чтение и запись ко всем данным платформы. Дыра позволила обнаружить 1,5 миллиона токенов аутентификации API, 35 тысяч почтовых адресов и личную переписку между агентами. Мы немедленно сообщили о находке команде Moltbook, которая с нашей помощью закрыла её в течение считаных часов, а все данные, доступ к которым был получен в процессе поиска и проверки исправления, удалены.

Что делает ваше FastAPI-приложение, когда клиент неожиданно закрывает соединение? По умолчанию — ничего. Если сервису важно экономить ресурсы (например, при работе с LLM), дисконнекты приходится обрабатывать явно, иначе GPU продолжит генерировать токены в пустоту.

В FastAPI есть встроенные механизмы отмены обработки запроса при дисконнекте клиента. Однако просто включить их недостаточно: нужно подготовить ваш код к этому. Иначе возможны проблемы: зависшие транзакции и сломанный пул соединений с БД.