Высоконагруженные системы *

Представьте, разработчики добавили прозрачное шифрование в файловую систему, собрали ядро и прогнали Fio — пропускная способность не изменилась. Однако после раскатки на продакшен производительность резко упала. Дело не в том, что бенчмарк ошибся: он честно измерил предел быстродействия жесткого диска, а накладные расходы на шифрование остались скрыты за дисковыми задержками. Так и возникает одна из самых типичных ошибок storage-бенчмаркинга.

Хранение до сих пор кажется многим инженерам простой подсистемой: файловая система, блочное устройство, метрика throughput. На практике это одна из самых коварных частей стека — с иерархией памяти в 4–8 порядков разницы между самой быстрой и самой медленной операцией, слоями виртуализации (LVM, программные RAID, NFS) и переключениями контекста между ядром и user-space.

Чтобы разобраться, как корректно измерять производительность систем хранения, обратимся к докладу Эреза Цадока, профессора Университета Стони-Брук, возглавляющего Лабораторию файловых систем и хранения данных.

Все подробности — под катом.

Продолжаем исследовать настройки памяти в Postgres и сегодня поговорим о связке настроек в ОС и СУБД. Речь пойдет о связке hugepages (Linux) и shared_buffers (Postgres).

Триггером для исследования послужила реальная жизненная ситуация у нашего клиента на поддержке производительности его ИТ-системы. Однажды утром…поступило обращение, что Postgres перестал запускаться вроде бы без видимых на то предпосылок: «мамой клянусь, ничего не делали с базой».

Привет, бойцы, вы готовы победить перенос данных?

Есть задача: перенести данные из PostgreSQL в Kafka. Первая мысль: написать небольшой сервис.

Он будет выполнять SELECT, превращать строки в сообщения и отправлять их через Kafka Producer. На схеме все выглядит почти безобидно:

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

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

Помните DFlash? В начале года о нём много шумели: способ ускорить любую LLM, не трогая саму модель. Nvidia тогда выкатила заголовки «До 15x к пропускной способности на Blackwell». Цифра весомая, звучит как революция.

Мы, конечно, решили покрутить это вручную. Для этого взяли драфтер DFlash для Gemma 4 26B, который лежит прямо в репозитории модели, прогнали на своём стенде.

Но вместо 15x получили 2,3x, и только пока на карте висит один‑единственный запрос… Если запустить 4 пользователей одновременно — ускорение исчезает, а на 8 параллельных запросах DFlash начинает проигрывать.

Сейчас расскажу, откуда берутся магические 15x и почему наши графики расходятся с вендорскими.

Разворачивать новый кластер базы данных каждую неделю — так себе удовольствие, особенно когда обслуживание десятков кластеров съедает время дежурных. Когда кластеров стало много, локальные аномалии стало сложнее замечать на общих дашбордах.

С этой проблемой мы столкнулись в Яндекс Трекере: за год количество активных организаций и кластеров выросло вдвое, а нагрузка на сервис поднялась всего на 13%. Получилось парадоксально: потребление ресурсов и сложность эксплуатации росли вместе с числом организаций, хотя реальная нагрузка увеличивалась значительно медленнее.

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

Поэтому я сел за доработку согласно предыдущему плану, что я писал в той статье. Я решил идти по первому пути и сделать логирование асинхронным. Дело в том, что так это становится изолированной переменной, ведь банально легче доработать и тестировать, чем заниматься рефакторингом всего кода и разносить его по разным процессам. После доработки я конечно же решил протестировать новую версию и я очень удивился результатам. Изначально throughput действительно вырос, что обрадовало меня.

Я уже думал писать статью, но решил мимолетом запустить 175 воркеров. Это решение создало неожиданную проблему - задача оказалась обработана за 11 секунд до ее создания.

Восемь новых пакетов и REST DSL вокруг прежних 56 глаголов маршрута; из ядра ушёл Newtonsoft.Json. Что ломает мажор и как мигрировать за десять минут.

Готовится четвёртая версия redb.Route, интеграционного движка для .NET в духе Apache Camel. В 3.x была закрыта ширина по паттернам: 56 глаголов DSL, тридцать с лишним коннекторов, свой язык выражений, скомпилированный в IL (в 4.0 он качественно переработан, об этом ниже). 4.0 закрывает то, что вокруг паттернов: как протестировать маршрут без брокеров, как собрать тело сообщения, как читать CSV и Avro, как выставить REST-фасад, как кэшировать ответ сервиса. Восемь новых пакетов, REST DSL внутри HTTP-коннектора, переработанный язык выражений и ядро, которое стало легче, а не тяжелее. За год это первый мажор такого масштаба: не смена номера под несколько ломающих правок, а качественное расширение функционала, и ломающих изменений в нём как раз немного.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Когда меня спрашивают, как выбрать интеграционную платформу, я обычно советую не ограничиваться сравнением функций и демонстрацией вендора. Гораздо полезнее проверить платформу на конкретной задаче из собственного ИТ-ландшафта.

Недавно для одного из заказчиков мы провели такой пилот: вместо существующей цепочки COM-обменов проверили централизованную схему через DATAREON Platform. Всего три интеграционных потока позволили проверить не только саму платформу, но и ключевую архитектурную гипотезу — может ли одна из систем стать единым источником данных, а зависимость от промежуточной системы быть устранена.

На этом примере разберу, что именно имеет смысл проверять во время пилота ESB и почему пилот не должен превращаться в формальную передачу нескольких сообщений из точки А в точку Б.

Четырнадцать копеек в месячном отчёте могут остановить закрытие периода на часы. Разберём, откуда берутся такие расхождения в денежных расчётах, почему привычная арифметика подводит в коде и где именно бэкенд‑разработчику стоит контролировать точность.

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу продуктовым направлением «Интеграционная платформа» в «Диасофт». Той самой Digital Q.Integration, которую вы имеете полное право не покупать.

Под каждой моей статьей появляется один и тот же комментарий. Слова разные, смысл один: зачем вообще нужна интеграционная платформа, если есть Kafka, брокер сообщений? Один сервис положил сообщение, второй забрал. В чем, собственно, проблема?

Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.

Дальше будет про то, где проходит граница между брокером и платформой, почему ее так трудно нащупать, почему настоящая причина «самописа» вообще не техническая и что во всей этой истории изменил ИИ. По последнему пункту спойлер: ничего хорошего.

Графический ускоритель NVIDIA RTX PRO 6000 Blackwell Server Edition в сравнении с более распространенными H100 интересен прежде всего аппаратной поддержкой NVFP4 — четырехбитного формата весов с двухуровневым масштабированием, представленного в 2025 году. Как переход моделей на NVFP4-квантизацию влияет на производительность? Что и при каких профилях нагрузки с учетом этого перехода окажется предпочтительней — ускоритель нового семейства Blackwell или старый знакомый H100?

Меня зовут Алексей, я инженер по разработке ПО искусственного интеллекта в YADRO. В ходе статьи я получу подробные ответы на эти вопросы, а помогут в этом YADRO G4208P G3 — производительные серверы для задач ИИ, машинного обучения и глубокой аналитики. В один такой сервер я установлю четыре RTX PRO 6000, в другой — восемь H100 NVL. Оценивать буду на моделях различного размера и архитектуры: Qwen3.6-27B (dense), Qwen3.6-35B-A3B (MoE) в форматах FP8 и NVFP4, а также DeepSeek-V4-Flash в форматах Mixed FP4 и NVFP4. Использую vLLM в сценариях offline и server — vLLM 0.23.0 для Qwen, vLLM 0.26 для DeepSeek-V4-Flash — а также Docker-image на основе nvidia/cuda:13.2.0-cudnndevel-ubuntu22.04.

История об асинхронном серверном EAV‑движке, epoll'е, битовых полях и шардинге, который не смог.

Это должен был быть очередной вялотекущий рутинный проект TCP сервера, listen socket, пул потоков, пул соединений, СУБД и синхронизация всего этого добра. Сказать, что скучно — ничего не сказать.

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

Этот сервер не стоит миллион рублей. Это обычная облачная виртуалка: 4 vCPU, 4.5 ГБ RAM, AlmaLinux 8. И она выдала 1М+ RPS на пакетах по 4 байта. Сервер стоял на 40% CPU.

Я прогнал тесты ещё несколько раз — результат не менялся. Сравнил счетчик сервера со счетчиками эмуляторов. Сервер стабильно держал 1М с копейками. Запросил информацию по производительности NGINX. Да ладно!?

Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система.

По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо.

Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало.

Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.

Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу направлением интеграции и развитием платформы Digital Q.Integration в «Диасофт».

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg

HurriCache это распределенная key-value база данных с поддерожкой как простых типов ключ значение так и конейнеров, блокировок, работы с atomics и многое другое. HurriCache может работать как standalone так и в кластере. В данной статье не буду сравнивать ее ни с каким либо продуктом, просто расскажу о том что умеет решение а остальные выводы пускай сделают пользователи.

Привет, Хабр!

На связи Илья Виссарионов, директор департамента «Аппаратно‑системная платформа» компании «Диасофт».
 
Про DevSecOps написаны тонны текстов, но почти все они – про инструменты: какой SAST выбрать, куда «воткнуть» Trivy, как подружить сканеры с GitLab. Реальная проблема 2026 года в другом. Сканеры давно стоят на всех стадиях пайплайна, базы уязвимостей обновляются ежедневно, а криты все равно доезжают до заказчика. Проблема сместилась в другую плоскость: как приоритизировать, чинить и ретестить находки, когда у тебя 2000+ развертываний в день и больше сотни команд. Проще говоря – как управлять security-долгом на конвейере.

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

Пару лет назад мы устроили настоящее расследование серии инцидентов в поисках скрытого дефекта нашего Redis-клиента. Команда воспроизводила сбои под контролируемой нагрузкой, проверяла одну гипотезу за другой, обновляла Jedis, экспериментировала с таймаутами и размерами пулов — но ничего не помогало. А помогли новые метрики и логи, настойчивость команды, ночные эксперименты и готовность разбирать поведение системы до последнего соединения. Получилась история с неожиданными поворотами, ложными следами и одной лишней строчкой кода в роли главного подозреваемого — а её итогом стал Redis-клиент, который оказался устойчивее, чем был до начала расследования.

Меня зовут Коля Грибанов, я тимлид команды «Платформа» в hh.ru. В статье расскажу, почему потеря одной ноды Redis вызывала шторм из десятков тысяч соединений, и как мы шаг за шагом искали причину инцидентов.

На одном собеседовании меня спросили про VIEW. Я ответил честно: в живых проектах они мне почти не попадались; для агрегатов надёжнее держать отдельную таблицу; а сами представления - вещь настолько нишевая, что за карьеру пригождались считанные разы. Разделение прав, долгие миграции, совместимость со старым ПО - вот и весь список. Ответ приняли прохладно. Один из собеседников сказал: “Ничего ты не понимаешь во VIEW” - и все посмеялись.

Прошло много времени. VIEW в моём коде так и не прибавилось, а вопрос остался, а вдруг с тех пор всё изменилось? Движки вышли новые. Поэтому я поднял MySQL 8.4 и PostgreSQL 17, залил одинаковые данные и прогнал основные сценарии один за другим.