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

Лет десять назад я делал инструмент сверки таблиц для мультимастера — крайне неэффективным способом: брал снапшот и под ним просто шёл по таблице, матчил строки. С тех пор задача стала только актуальнее: одни и те же данные всё чаще живут в разных дата-центрах, на разных инстансах с надёжным failover’ом, и рано или поздно приходится задумываться о проверке их идентичности.

Готовые инструменты для сравнения таблиц в мире Postgres есть — pg_comparator, pgCompare, ACE. Однако давайте сегодня поразмышляем, стоит ли ради большей эффективности городить огород с дополнительным софтом. Может быть, хватит простой транзакции и golang-скрипта, выполняющего SQL на обоих инстансах?

Я разрабатываю Brawl Town, браузерную драку на Go и PixiJS. В нагрузочном тесте на i7-7700K сервер выдержал 2500 клиентов: тик занимал 28-31 мс при бюджете 50 мс. Рассказываю про дельты в протоколе, компактные записи в пространственной сетке и отрисовку толпы. Показываю замеры и ограничения теста: генератор работал на том же ПК, а боевой сервер заметно слабее.

Между нажатием кнопки и результатом у нас проходит от трёх до шестидесяти секунд: очередь, воркер, внешний API, иногда таймаут. А снаружи — пользователь, у которого на счету ровно одна генерация, и палец, который очень хочет нажать ещё раз.

Разбираю двухфазное списание: резерв при постановке в очередь, списание ровно зарезервированного при успехе, удаление строки при провале. Плюс мьютекс на пользователя через UNIQUE-индекс, почему цену нельзя пересчитывать при списании, что делать с резервами от умерших воркеров и зачем суточные лимиты обновлять скользящим окном, а не кроном в полночь.

После крупного инцидента SaaS-компании приходится отвечать на неудобный вопрос: кто заметил проблему первым — мониторинг или клиенты? У команды Atlassian долгое время не было однозначного ответа. Команда VK Tech перевела статью о том, как небольшая команда перестроила платформу обнаружения инцидентов на Apache Kafka, Apache Flink в Kubernetes и OpenTelemetry. На этой платформе работает AutoHOT — система автоматического создания инцидентов высокой серьёзности. Авторы рассказывают об архитектурных решениях, показателях, которые отслеживали ежемесячно на протяжении восемнадцати месяцев, и о том, что сделали бы иначе.

Результаты оказались неоднозначными. Доля обнаруженных реальных инцидентов среди тех, которые охватывает мониторинг, выросла примерно с 60% до 86% на пике, но в неудачный месяц снова упала до 64%. Точность — доля срабатываний, оказавшихся настоящими инцидентами, — по-прежнему ниже, чем хотелось бы авторам. Они приводят цифры и разбирают ограничения системы, включая пропущенные инциденты и ложные срабатывания.

Статья адресована тем, кто строит потоковый мониторинг на Kafka и Flink и хочет учесть ошибки авторов при проектировании собственной системы.

Обычно на митапах всё довольно предсказуемо: доклады, слайды, кофе-брейк и немного общения между ними. Но в прошлом году мы решили перевернуть привычный формат — собрать Go-сообщество и побрейнштормить архитектуру. Активность была похожа на System Design, но с фаном и мясом!

Так появился Avito Grill & Go. Формат зашёл настолько, что участники попросили повторить. И мы подумали: а почему бы не привезти его в Петербург?

В этот раз собрали 130 Go-разработчиков во дворике Union Bar и разделили их на команды. Ребята придумывали архитектуру необычных сервисов, рисовали её на ватмане и защищали перед остальными. Мы не пытались провести полноценное архитектурное интервью, а хотели скорее поговорить о технологиях, поштормить интересные решения и хорошо провести время.

Меня зовут Иван Нещадин, я тимлид в команде Arch+Bridge Авито. Расскажу, как прошёл этот эксперимент и какие архитектуры придумали участники — от способов распределить 50 зарядных портов между 3000 людьми до отказоустойчивого пивопровода и платформы для поиска компании.

Добавили в HTTP-клиент таймаут, повторы и ограничение одновременных запросов. Кажется, всё предусмотрели, но вызывающий код почему-то ждёт дольше, чем рассчитывали. Я собрал стенд на aiohttp, чтобы разобраться, как так получается и где нужно поставить deadline, чтобы в общий бюджет попало и ожидание в очереди, и все повторные попытки.

Мы дошли до финала: 30 000 ВРМ, 4 NUMA-узла, сервер на 480 логических ядер и APDEX = 0,986 в конфигурации с асинхронной репликой. Но на последнем отрезке пути нас ждали сюрпризы. Один процесс Xorg загружал целое ядро и тормозил тонкие клиенты. INSERT на 15 строк висел больше 20 секунд из-за блокировок BufferMapping. Подключённая реплика заставила rphost съедать вдвое больше памяти и уронила кластер 1С. Рассказываем, как мы с этим справились и что вошло в Postgres Pro Enterprise for 1C 18.6.1.

Привет! Меня зовут Сергей Прокопкин, я развиваю мотивационную программу и отвечаю за realtime-систему трекинга заданий в Авито. 

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

На первый взгляд техническая задача выглядит довольно просто: получаем действия пользователя, проверяем их на соответствие активным заданиям и обновляем прогресс. Но когда поток событий становится большим, а число заданий и аудитория растут, простая схема начинает дорого обходиться. В нашем случае выяснилось, что более 99% обрабатываемых событий вообще не влияли на прогресс пользователей.

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

7 октября мы провели онлайн-презентацию новой, AI-driven версии экосистемы Digital Q. Мы впервые публично показали полную схему конвейера ИИ-агентов, разобрали контур за контуром и продемонстрировали, как он проводит реальную задачу от встречи с заказчиком до подписанного релиза. А теперь обо всем подробнее.

Тест упал на пятом часу, на переходе с 16 800 до 21 000 ВРМ. Потом запрос, который выполнялся меньше секунды, вдруг стал занимать десятки секунд. После этого отчёт вместо 5 секунд начал строиться 800. Во второй части мы разбираем, как с этим справились: от LWLock:PgStatsHash и сбежавшего плана запроса до гигабитной сетевой карты и 3 миллионов файлов временных таблиц. В итоге на 21 000 ВРМ получили APDEX = 0,975.

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

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

Внутри: две ступени сравнения через хэш файла, версии контента, медиа вне репозитория, разбор самой ошибки по трём безобидным кускам кода и ещё пара находок — счётчики, которые всегда равны нулю, и экспортёры, прописанные в конфиге, но не существующие в коде.

Сколько сообщений в секунду выдерживает MQTT‑брокер? Без описания нагрузки этот вопрос почти ничего не говорит. Приём сообщений от множества устройств, доставка одного сообщения тысяче подписчиков и обслуживание сотен тысяч соединений нагружают сервер по‑разному.

Я сравнил Mosquitto, EMQX, FlashMQ, HiveMQ Community Edition и XMQ на одном AWS‑стенде. Меня интересовали доставленная скорость, задержка и потребление CPU и памяти, а также то, что происходит, когда брокер не успевает за заданной нагрузкой.

Сразу обозначу свою заинтересованность: я разработчик XMQ. Генератор нагрузки xmq_scn также входит в этот проект. Поэтому рядом с результатами нужны версии, сценарии, конфигурации и исходные отчёты: читатель должен иметь возможность проверить эксперимент.

Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента».

И сразу, пока вы не пролистали до конца, вопрос к вам.

Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого‑то ваш комментарий станет поводом проверить свой план до аварии, а не после.

А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.

Привет!

В стандартной библиотеке лежит макрос pin!. Стабильный с версии 1.68, живёт в core, зовёт его каждый, кто хоть раз закреплял футуру на стеке. Значащая для нашего разговора строчка внутри у него одна, и повторить её у себя не выйдет: конструкции, на которой она держится, в языке официально нет.

Случай не единственный, второй лежит вообще на виду. Откройте объявление Vec и посмотрите внимательно: там не Vec<T>, а Vec<T, A = Global>, два параметра. Попробуйте назвать второй своими руками, и на пять строк кода прилетят три ошибки, потому что Global нестабилен.

Прикол в том, что на фичах, которых в стабильном Rust как бы нет, держится куча всего, чем мы пользуемся каждый день. В первой части так вышло с gen-блоками, pattern types, специализацией, become и #[loop_match]. Сегодня разберёмся, зачем pin! выписал себе особый пропуск. Почему второй параметр Vec сидит под замком дольше всех остальных. Как компилятор посчитает вашу корзину до копейки ещё до запуска программы. Что лежит внутри толстого указателя, если раскрутить его на запчасти. И почему SIMD руками обгоняет автовекторизацию только до того момента, пока вы не разрешите компилятору лишнего.

Ты не владеешь источником — значит, не владеешь временем. Как поллер по updated_at молча теряет строки, почему exactly-once это свойство твоей записи, и почему сверка важнее потока.

Когда LLM помещается на одной GPU и получает несколько запросов в минуту, настройка движка инференса обычно заканчивается на выборе модели и типа данных. Проблемы начинаются дальше: модель перестает помещаться в память, растет очередь запросов, длинные промпты съедают KV-кэш, а GPU простаивают в ожидании обмена данными друг с другом. 

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

Разберем пять групп настроек: параллелизм: TP, DP, CP, PP и EP, KV-кэш: Radix Cache и HiCache, вычисления и коммуникации в MoE, attention-бекенд, спекулятивное декодирование. Задача — не перечислить все CLI-флаги SGLang, а понять, что именно в пайплайне инференса меняет каждая настройка и в какой ситуации ее имеет смысл трогать. Поехали! 

Обновили Go до 1.25 и оставили привычный automaxprocs? Пустой импорт теперь может отключить встроенное управление GOMAXPROCS и изменить поведение сервиса под CPU‑квотой. Разбираемся, как новый рантайм работает с cgroup, откуда берётся разница на дробных лимитах и что проверить перед удалением старой зависимости.

Битовые массивы кажутся экзотической структурой данных, которую применяют только опытные учёные мужи в специфичных сферах? Не всегда!

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

Под катом — эволюция от классических битовых массивов до современных сжатых форматов и реальный бизнес‑кейс их прикладного применения.

Знакомая картина: в 3 часа ночи падает база данных, Alertmanager засыпает каналами, через 5 минут сеть восстанавливается, но… система остаётся «мёртвой». CPU на воркерах 100 %, Goodput на нуле, а перезапуск подов только усугубляет ситуацию. Все указывает на то, что вы столкнулись с метастабильным отказом — самым коварным типом аварий в распределённых системах.

Меня зовут Артём Баранов, в «Базисе» я занимаюсь автоматизацией и развитием инфраструктуры. В этой статье я хочу рассказать о математике метастабильного отказа и через теорию массового обслуживания — конкретно через модель и формулу Кингмана — проложить мост от математических абстракций к реальным логам, метрикам и алертам. Далее, предложить практикующему SRE-специалисту набор методик для анализа, диагностики и предотвращения катастроф, возникающих в информационных системах по тем или иным причинам (ошибки конфигурирования, сбои «железа» и т. д.). Это позволит инженеру распознать sustaining-эффект по логам и метрикам и осознанно выбрать рычаг (backoff, retry budget, shedding, circuit breaker), а не просто объяснить постфактум, почему возникла предыдущая авария.

Когда говорят о PL/I, воображение часто рисует большие машины и программы из другой эпохи. Но у языка есть и вполне современная сторона: процедуры, массивы, многопоточное выполнение. Если вы писали на Go или Python, базовый сценарий будет понятен: запустить работу в фоне, пока она идёт заняться чем‑то ещё, а затем дождаться результата.

Разберём этот сценарий на примерах, которые опираются на реализованную многозадачность в pli‑llvm — новом открытом кроссплатформенном компиляторе языка PL/I, который был создан на основе спецификации языка TR25 с добавлением некоторых более поздних полезных фишек из IBM Enterprise PL/I.