Backend VK Hub

HOT updates и FILLFACTOR — как избежать bloat на UPDATE-heavy таблицах В PostgreSQL каждый UPDATE из-за MVCC создаёт новую версию строки, а старая помечается как dead и живёт до VACUUM. Плюс обновляются все индексы, даже те, где изменённое поле не участвует. На UPDATE-heavy таблицах это даёт bloat и постоянную работу autovacuum. Есть механизм, пропускающий эту работу, — HOT update, heap-only tuple. Работает не всегда, но настраивается одним параметром. Условий два: новая версия помещается на ту же страницу, что и старая, и ни одно индексируемое поле не менялось. При этом PostgreSQL пишет новую версию рядом со старой на той же странице и ставит указатель со старой на новую. Индексы остаются — они по-прежнему указывают на «голову цепочки», живая версия достаётся за один hop. VACUUM собирает dead tuples внутри страницы без полного прохода. Первое условие обеспечивает FILLFACTOR — процент заполнения страницы при вставке. По умолчанию 100, страницы заполняются под пробку. Для read-only это оптимально, для UPDATE-heavy ломает HOT: свободного места нет, новая версия уходит на другую страницу, индексы правятся. Настраивается при создании таблицы или через ALTER.

CREATE TABLE user_stats (
    user_id bigint PRIMARY KEY,
    last_seen timestamptz,
    view_count int
) WITH (fillfactor = 80);

ALTER TABLE user_stats SET (fillfactor = 80);

После ALTER существующие страницы перезаполнятся при VACUUM FULL. На проде без окна обслуживания — pg_repack, без блокировки. Проверяется через pg_stat_user_tables:

SELECT relname, n_tup_upd, n_tup_hot_upd,
       round(100.0 * n_tup_hot_upd / NULLIF(n_tup_upd, 0), 1) AS hot_ratio
FROM pg_stat_user_tables
WHERE n_tup_upd > 0
ORDER BY n_tup_upd DESC;

hot_ratio показывает долю UPDATE, прошедших как HOT. Целевое значение на UPDATE-heavy таблицах — 80% и выше. При низком ratio первое, что стоит проверить, — не FILLFACTOR, а второе условие: какие индексы задевают изменяемые поля. Второе условие ломается чаще. Типичный пример — составной индекс (user_id, updated_at) на таблице, где UPDATE меняет updated_at. Каждый UPDATE трогает индекс, HOT не работает, hot_ratio близок к нулю. Варианта два: убрать updated_at из индекса, если он не даёт выигрыша на чтении, либо разнести схему — собрать часто меняющиеся поля в отдельную таблицу без лишних индексов. Второй подход — стандартный для горячих счётчиков. FILLFACTOR понижают на таблицах с регулярными UPDATE: счётчики, статистика, presence, состояние сессий. Значения 70–80 покрывают большинство случаев. На read-heavy таблицах менять не нужно. Порядок действий на таблице с подозрением на bloat: посмотреть hot_ratio, при низком — проверить индексы на изменяемых полях, при необходимости почистить лишние и понизить FILLFACTOR. Работы немного, эффект на write-нагрузку и autovacuum обычно ощутимый. А вы у себя FILLFACTOR настраивали на UPDATE-heavy таблицах? #backendvkhub #postgresql

Типы индексов в PostgreSQL — не только btree PostgreSQL знает шесть типов индексов. Большинство разработчиков всю жизнь работает с одним — btree. Остальные пять закрывают целые классы задач, где btree либо не работает, либо съедает в разы больше места. В карточках пройдёмся по каждому — от базового btree до BRIN, который сжимает индекс на терабайтную таблицу до десятков килобайт. #backendvkhub #postgresql

Очередь задач в PostgreSQL без Redis и гонок Пять воркеров разгребают задачи. Первое, что приходит: SELECT с pending, потом UPDATE в processing. Работает, пока воркеры не начинают хватать одну строку. Задача выполняется дважды, метрики летят, начинается ад. Классика — Redis, RabbitMQ, Kafka. Но если PostgreSQL в стеке, всё закрывается одной конструкцией из PG 9.5: SELECT ... FOR UPDATE SKIP LOCKED. На ней построены Sidekiq, PG-boss, GoodJob, Solid Queue, River. Таблица jobs:

CREATE TABLE jobs (
    id bigserial PRIMARY KEY,
    payload jsonb NOT NULL,
    status text NOT NULL DEFAULT 'pending',
    created_at timestamptz NOT NULL DEFAULT now()
);

Воркер забирает следующую задачу так:

BEGIN;

WITH next AS (
    SELECT id FROM jobs
    WHERE status = 'pending'
    ORDER BY id
    FOR UPDATE SKIP LOCKED
    LIMIT 1
)
UPDATE jobs
SET status = 'processing'
WHERE id IN (SELECT id FROM next)
RETURNING *;

COMMIT;

Основная пара — FOR UPDATE SKIP LOCKED. Первое берёт row-level lock, второе — если строка заблокирована, не ждём, берём следующую. Воркеры не толкаются, каждый забирает свою задачу. CTE с UPDATE атомарно вытаскивает строку и меняет статус в одной короткой транзакции, иначе lock снимется только на COMMIT. Если задачи лёгкие, меняем LIMIT 1 на LIMIT 10 — воркер забирает пачку, сеть до базы окупается на пачке. О чём часто забывают Без индекса SELECT превращается в seq scan, и очередь встаёт на минимальной нагрузке. Partial index на pending — то, что нужно:

CREATE INDEX idx_jobs_pending 
    ON jobs (id) 
    WHERE status = 'pending';

Индекс маленький — только необработанные задачи. После смены статуса строка выпадает из индекса, bloat не копится. Второе — воркер может упасть посреди работы. Задача останется в processing навсегда. Решение — lease pattern: колонка taken_at и крон, возвращающий застрявшее в pending:

UPDATE jobs 
SET status = 'pending', taken_at = NULL
WHERE status = 'processing' 
  AND taken_at < now() - interval '10 minutes';

Retry живёт в колонке attempts с лимитом попыток. Транзакция с FOR UPDATE держит lock до COMMIT, закрываем быстро. Работа с payload идёт после, финальный статус фиксируем отдельным UPDATE. Приоритеты через ORDER BY, отложенные задачи через WHERE scheduled_at <= now(). Где это перестаёт работать? На миллионах задач в час PostgreSQL страдает от write amplification: несколько UPDATE на задачу, autovacuum не успевает, копится bloat. Тогда пора на Kafka. Но для сотен тысяч в час SKIP LOCKED работает отлично: транзакционность, retry, приоритеты, delayed jobs — всё в одной базе рядом с прикладными данными. Если PostgreSQL в стеке и объёмы разумные, SKIP LOCKED закрывает большинство сценариев без брокера. Не зря на нём построены Sidekiq, PG-boss, GoodJob, Solid Queue, River и куча самописных очередей, которые работают годами. #backendvkhub #postgresql

📢 24 июля приглашаем на митап «Старый добрый Go в мире AI-агентов» Как меняется роль Go с приходом AI-агентов? Где он остаётся незаменимым и где встраивается в новые сценарии? Поговорим об этом 24 июля в офисе VK в Санкт-Петербурге. Своим опытом поделятся инженеры из VK, Фланта, h3llo cloud и MWS Cloud Platform. Обсудим: 🔵как безопасно давать AI доступ к проду с помощью Go и MCP 🔵как AI-агенты работают с инфраструктурой данных 🔵как DRA-драйвер на Go меняет подход к работе с GPU 🔵действительно ли простота Go — преимущество или уже ограничение Митап организован совместно с каналом IT-подкастов «Алло, Ада». 📍 24 июля, 18:30 Офис VK, Санкт-Петербург, бизнес-центр «У Красного моста», набережная реки Мойки, 73 Регистрация До встречи! #backendvkhub #meetup #go #митап

Мало кто помнит про xid wraparound. А зря Есть аварии в PostgreSQL, которые случаются раз в несколько лет. База останавливает запись, чинить приходится через postgres --single. Wraparound из этой оперы: штука узкая, тихая, последствия громкие. У транзакций есть номер xid: 32 бита, 4 миллиарда значений. Реально используется половина: MVCC сравнивает xid через круговую арифметику, чтобы понять, в прошлом строка относительно текущей транзакции или в будущем. Такое сравнение работает только в пределах 2 миллиардов. А что случится, когда счётчик пройдёт границу? На OLTP с сотнями транзакций в секунду это пара лет. Старые строки вдруг оказываются в будущем, приложение их не видит. Данные физически лежат на диске, а SELECT возвращает пустоту. По факту это потеря данных. Спасёт VACUUM FREEZE. Он проходит по старым строкам и меняет их xmin на замороженный xid, который всегда воспринимается как «в далёком прошлом», независимо от счётчика. Freeze нужен не для места на диске, а для сохранности данных: VACUUM освобождает место, VACUUM FREEZE защищает от wraparound. Autovacuum запускает freeze при достижении autovacuum_freeze_max_age, по умолчанию 200 миллионов транзакций от старейшего замороженного xid таблицы. С PG 12 freeze легче, раньше он блокировал DDL. Но на терабайтных таблицах всё равно идёт долго. Если приложение генерирует транзакции быстрее, чем autovacuum морозит, счётчик подходит к критической зоне. За 40 миллионов до конца PG отправляет в логи database is not accepting commands to avoid wraparound data loss. За 3 миллиона переходит в single-user mode: клиентам ошибка, база стоит, поддержка получает много звонков. Что смотреть в проде? Возраст xid по базам:

SELECT datname, age(datfrozenxid) AS age
FROM pg_database
ORDER BY age DESC;

И отдельно по самым старым таблицам — обычно именно там всё копится:

SELECT relname, age(relfrozenxid) AS age
FROM pg_class
WHERE relkind IN ('r', 'm') 
  AND age(relfrozenxid) > 100000000
ORDER BY age DESC;

age() показывает разрыв между текущим xid и старейшим замороженным. 200 миллионов норма, autovacuum вот-вот сработает. 500 — стоит разбираться, почему не справляется. Миллиард — руками звать VACUUM FREEZE. Полтора — паника. Мониторинг обязателен на любой нагруженной базе. Есть побочка, парализующая autovacuum. Длинные транзакции блокируют freeze: старейший активный xid определяет, что можно морозить. Один забытый BEGIN у аналитика — и в понедельник age за трое суток удвоился, freeze не сдвинулся. Мониторинг xact_start из pg_stat_activity идёт в паре с возрастом xid. Полный фикс — XID64, 64-битный счётчик. В mainstream пока не приземлился, живём с 32-битным и следим. Wraparound редко случается в маленьких проектах, но с ростом transaction rate вероятность растёт нелинейно. Проспать алерт один раз — и в лучшем случае теряешь час на single-user, в худшем ищешь причину, почему автовакуум встал. А у вас в мониторинге стоит алерт на возраст xid? #backendvkhub #postgresql

PostgreSQL JSONB — операторы, индексы и когда они не нужны JSONB в PostgreSQL давно стал стандартом для гибких схем — настройки, метаданные, поля, которые не фиксируются заранее. Большинство ограничивается data->>'field' и на этом останавливается. На деле там полноценный язык запросов и пара видов индексов, которые делают поиск по JSONB сравнимым по скорости с поиском по обычным колонкам. В карточках разберёмся с операторами, поиском по структуре, JSONPath и индексами, а в конце узнаем, когда JSONB вообще не стоит брать. #backendvkhub #postgresql

LISTEN/NOTIFY — встроенный pub/sub в PostgreSQL. Если в проекте уже стоит PG, для уведомлений между процессами не нужны Redis или RabbitMQ — обходимся двумя SQL-командами. Cache invalidation, realtime-обновления через WebSocket, координация воркеров — всё закрывается без дополнительной инфраструктуры. Базовое:

— в одной сессии
LISTEN cache_invalidate;

— в любой другой сессии (или из триггера)
NOTIFY cache_invalidate, '{"key":"user:123"}';

Слушающая сессия получит уведомление. Канал — обычное имя, регистронезависимое. Через pg_notify() то же самое, но удобнее в триггерах с динамическим payload:

SELECT pg_notify('cache_invalidate', json_build_object('key', 'user:' || id)::text)
FROM updated_rows;

Главный кейс — триггер на изменения:

CREATE OR REPLACE FUNCTION notify_user_change()
RETURNS trigger AS $$
BEGIN
    PERFORM pg_notify(
        'user_changed', 
        json_build_object('id', NEW.id, 'op', TG_OP)::text
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER user_changes
AFTER INSERT OR UPDATE OR DELETE ON users
FOR EACH ROW EXECUTE FUNCTION notify_user_change();

Любое изменение в users шлёт уведомление подписчикам — идеально для инвалидации кеша или WebSocket-бэкенда. Получение в Node.js через pg:

client.on('notification', (msg) => {
    invalidateCache(JSON.parse(msg.payload));
});
await client.query('LISTEN cache_invalidate');

В Go — pgx.WaitForNotification, в Python — psycopg.notifies после autocommit=True. Ограничения Payload — до 8 000 байт. Если данных больше, кладём в payload только id, а сами данные читаем отдельным запросом — это даже правильнее, за время доставки данные могли измениться. NOTIFY срабатывает только после COMMIT — подписчик не увидит уведомление о rollback-изменениях. Главная ловушка — PgBouncer в transaction pooling. LISTEN — session-level state, соединение должно жить постоянно. Через transaction pooler подписка ломается: соединение возвращается в пул после COMMIT, и LISTEN уходит с ним. Решение — отдельный пул прямых соединений для подписчиков либо session pooling для этой части. Гарантии доставки нет. Если подписчика не было в момент NOTIFY — событие потеряно. Для критичных сценариев — транзакционная outbox-таблица плюс LISTEN/NOTIFY сигнализирует воркеру: посмотри в таблицу. Реальные сценарии Cache invalidation: триггер → NOTIFY → бэкенды сбрасывают свой in-memory cache. Realtime через WebSocket: бэкенд получает NOTIFY и пушит в открытые сессии — так работают Supabase Realtime и подобные продукты. Координация воркеров: новая задача → NOTIFY → свободный воркер просыпается и забирает, без polling каждые N секунд. LISTEN/NOTIFY закрывает большую часть быстрых сценариев координации без отдельной инфраструктуры. Главное — лимит payload и transaction pooling. #backendvkhub #postgresql

🔵Postgres Pro Standard 18.4.1 — встроенная отказоустойчивость Технология BiHA на базе Raft стала доступна в Standard-редакции, автоматизируя репликацию и failover. Ещё один шаг к снижению сложности эксплуатации критичных PostgreSQL-кластеров. 🔵nenya — AI Gateway на Go Появился лёгкий open-source шлюз для маршрутизации и контроля запросов к LLM-провайдерам. Формируется отдельный класс инфраструктурных решений для управления AI-трафиком и политиками безопасности. 🔵jqwik и prompt injection — новый класс рисков Автор фреймворка намеренно добавил в релиз скрытую инструкцию для ИИ-агентов, вызвав дискуссию о безопасности зависимостей в эпоху агентской разработки. Supply-chain риски начинают распространяться не только на код, но и на взаимодействие с агентами. 🔵Spring Boot 3.5 теперь без open-source поддержки С 30 июня 2026 года Spring Boot 3.5 прекратил получать публичные исправления безопасности и багфиксы, что создаёт риски для команд, использующих этот стек. Пора обновляться до Spring Boot 4. 🔵Утечка данных 10,9 млн клиентов из-за пропавшего бэкапа Японская энергетическая компания потеряла HDD с резервной копией клиентских данных. История напоминает, что надёжный бэкап без контроля хранения и шифрования не гарантирует безопасность. 📌 Новые статьи от инженеров VK на Хабре PostgreSQL не тормозит. Почему мы перестали масштабировать базу данных и начали масштабировать архитектуру Может ли Service сломать ваш K8s кластер? Как мы тестировали Tarantool Database на 640 инстансов #дайджест #backendvkhub

Cassandra как метастор для S3: как мы пришли к локальному скану и Kafka В VK работает собственная S3-совместимая реализация — one-object-storage. Метаданные объектов лежат в Cassandra, и на масштабе в миллиарды объектов простая база ловит сразу несколько архитектурных ловушек. В карточках рассмотрим, что хранит метастор, почему партиционирование выстрелило, что такое tombstones и почему перестало хватать договорённостей с клиентами, как пришли к локальному скану и переезду очереди на Kafka. И это только часть истории. В полной статье на Хабре — про фильтр Блума для чистки пустых директорий (потому что локально определить пустоту нельзя — директория и её содержимое лежат на разных хостах), snapshot-статистику в реальном времени для ограничения размера бакета, и почему обычные снапшоты не покрывают всю задачу. Цифры в проде: 14 млн RPM на скан 18 хостов, до 1.1 млн RPM на чистку в пике. #backendvkhub #s3 #kafka #cassandra #статья #кейс

Как читать планы PostgreSQL и не дёргать DBA EXPLAIN — встроенная команда PostgreSQL для разбора планов запросов. Большинство знают, что она есть, но реально читать вывод — навык, который приходит с практикой. Разберём, как читать план, на что смотреть в первую очередь и какие сигналы скрываются за безобидным Seq Scan. Три режима:

EXPLAIN SELECT * FROM users WHERE email = '...';
-- только план, запрос не выполняется

EXPLAIN ANALYZE SELECT * FROM users WHERE email = '...';
-- план + реальное выполнение (запрос ВЫПОЛНИТСЯ)

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM users WHERE email = '...';
-- + сколько страниц прочитано из кеша и с диска

EXPLAIN без ANALYZE — оценки, EXPLAIN ANALYZE — реальные числа. ANALYZE действительно выполняет запрос, поэтому на UPDATE и DELETE безопаснее обернуть в BEGIN ... ROLLBACK. Типичный вывод:

Limit  (cost=0.43..8.45 rows=1) 
       (actual time=0.234..0.234 rows=1 loops=1)
  Buffers: shared hit=4
  ->  Index Scan using users_email_idx on users  
        (cost=0.43..8.45 rows=1)
        Buffers: shared hit=4
Planning Time: 0.124 ms
Execution Time: 0.279 ms

Дерево читается снизу вверх: Index Scan находит строку, потом Limit её обрезает. В каждой строке два главных числа — cost (оценка планировщика) и actual time (реальное время). Что смотрим первым — расхождение между rows (оценка) и actual rows (факт). Если планировщик ожидал 10 строк, а получил 100 000, он выбрал план под маленькую выборку (обычно Nested Loop) и просел на больших данных:

Nested Loop  (rows=10, actual rows=100000)

Лечится это через ANALYZE table_name для пересбора статистики или default_statistics_target = 1000 для более детальной выборки. BUFFERS показывает работу с диском: Buffers: shared hit=42 read=128. hit — страницы из shared buffers, read — с диска. Чем выше read, тем медленнее запрос. Сигналы медленного запроса Seq Scan на большой таблице с фильтром — нет индекса или планировщик решил, что он не нужен. Hash Join с Batches > 1 означает, что хеш-таблица не поместилась в work_mem. Sort с пометкой external merge Disk — память кончилась, сортировка ушла на диск. В двух последних случаях поднимаем work_mem для сессии. Полезный приём для прода — auto_explain, чтобы планы медленных запросов сами писались в логи:

LOAD 'auto_explain';
SET auto_explain.log_min_duration = 1000;
SET auto_explain.log_analyze = true;

После этого все запросы дольше секунды попадут в логи вместе с реальным планом. Спасает кучу времени в дебаге. EXPLAIN — основной инструмент оптимизации SQL. Стоит хотя бы раз пройтись по топу медленных запросов из pg_stat_statements через EXPLAIN ANALYZE — обычно там пара-тройка запросов с расходящейся статистикой, которые после правки уносят 80% нагрузки. А вы где находили самые неожиданные узкие места через EXPLAIN? Делитесь в комментариях — особенно интересны кейсы, где статистика расходилась с реальностью в десятки раз. #backendvkhub #postgresql

LATERAL JOIN в PostgreSQL — то, что вы пропустили, но используете каждый день LATERAL JOIN — конструкция, о которой большинство узнаёт случайно, лет через пять работы с SQL. До этого решают те же задачи через коррелированные подзапросы или window functions, иногда теряя производительность в разы. Суть простая: LATERAL разрешает использовать в правой части JOIN колонки из левой таблицы. Без LATERAL такое не работает:

SELECT u.name, p.title
FROM users u
JOIN (
    SELECT * FROM posts 
    WHERE author_id = u.id LIMIT 3
) p ON true;
-- ERROR: invalid reference to FROM-clause entry for table "u"

Подзапрос не видит таблицу слева — это поведение JOIN по дефолту. Без LATERAL правая часть выполняется один раз, до соединения, и понятия не имеет про u.id. С LATERAL подзапрос видит контекст:

SELECT u.name, p.title
FROM users u
LEFT JOIN LATERAL (
    SELECT title 
    FROM posts 
    WHERE author_id = u.id 
    ORDER BY created_at DESC 
    LIMIT 3
) p ON true;

Для каждой строки слева исполняется свой подзапрос со своим u.id. На выходе — каждый пользователь и его три последних поста. ON true — формальность, условие соединения уже внутри. Главная история, ради которой стоит знать LATERAL, — топ-N по группе. Та же задача через ROW_NUMBER пишется чуть короче, но работает иначе:

WITH ranked AS (
    SELECT *, ROW_NUMBER() OVER (
        PARTITION BY author_id 
        ORDER BY created_at DESC
    ) AS rn
    FROM posts
)
SELECT u.name, p.title
FROM users u
JOIN ranked p ON p.author_id = u.id AND p.rn <= 3;

Запрос работает, но проходит по всем posts целиком — окно строится для всей таблицы, фильтр по rn срабатывает уже после. LATERAL с индексом на (author_id, created_at DESC) читает по три строки на каждого пользователя через index scan. На таблицах в десятки миллионов записей разница на порядки — десятки миллисекунд против минут. Второй частый кейс — развернуть JSON-массив с привязкой к строке:

SELECT 
    o.id AS order_id, 
    item->>'product_id' AS product_id,
    (item->>'qty')::int AS qty,
    p.name
FROM orders o
CROSS JOIN LATERAL jsonb_array_elements(o.items) AS item
JOIN products p ON p.id = (item->>'product_id')::int;

jsonb_array_elements — set-returning функция, она и так неявно подразумевает LATERAL, но писать его явно — хороший тон: читатель сразу видит, что выражение справа зависит от строки слева. CROSS JOIN LATERAL от LEFT JOIN LATERAL отличается тем, что заказы без позиций просто не попадут в результат. Где LATERAL выигрывает: топ-N по группе с подходящим индексом, разворачивание массивов и JSON в строки, вызов set-returning функций с аргументом из левой таблицы, агрегации с фильтром, зависящим от строки. Везде, где нужна логика «для каждой строки слева — свой запрос справа». Где не нужен: простые соединения по равенству ключей, обычные подзапросы в SELECT. LATERAL не делает запрос быстрее по умолчанию, но на правильном паттерне переписывает CTE с window functions в 2–5 раз быстрее. #backendvkhub #postgresql

До Go 1.25 GOMAXPROCS по умолчанию равнялся runtime.NumCPU(). В контейнере это количество CPU ноды, а не пода. Планировщик получал параллелизм на 32 ядра, cgroup разрешал 2. CFS выжигал квоту за долю периода и троттлил cgroup до следующего окна. Коротко о модели: M/P/G Три сущности в планировщике: M (поток ОС), P (токен выполнения), G (горутина). GOMAXPROCS задаёт число P, то есть сколько горутин могут выполняться параллельно. M без P не запускает Go-код. Выставить GOMAXPROCS = 32 на контейнере с лимитом 2 CPU — значит попросить планировщик выполнить работу, которую cgroup не пустит. Почему страдает P99, а не средний RPS CFS работает с полосой пропускания CPU через период/квоту. Контейнер с limits.cpu: 2000m получает 2 CPU на каждый период. Если Go стартует 32 P и планирует работу 32 потоков, то квота сгорает быстро и дальше cgroup простаивает до следующего периода. Троттлинг бьёт по P95/P99/P99.9, а не по средней пропускной способности. Горутина с состоянием приложения держит очередь выполнения, за ней стоят другие. Среднее RPS почти не страдает, но хвост распределения уползает вправо. automaxprocs как костыль uber-go/automaxprocs делал ровно одно: выставлял GOMAXPROCS = cpu.cfs_quota_us / cpu.cfs_period_us. Решение стало де-факто стандартом для Go-сервисов в Kubernetes. Работало, но требовало зависимости в каждом сервисе и не ловило изменение лимита на лету. Что сделал Go 1.25 Рантайм читает cgroup при старте и вычисляет min(visible CPUs, effective cgroup limit). Для cgroups v2 это cpu.max, для v1 — cpu.cfs_quota_us и cpu.cfs_period_us. Файловые дескрипторы остаются открытыми, значения лимитов периодически перечитываются, а GOMAXPROCS при необходимости пересчитывается без рестарта процесса. CFS лимит задаёт среднюю пропускную способность, а не число ядер. Контейнер с 1500m имеет право на 1.5 CPU в среднем. Рантайм округляет вверх: ceil(1.5) = 2. Это смещение в сторону пропускной способности, что для ultra-low-latency сервисов может оказаться избыточным. В крупных кластерах фича убирает класс случайных троттлинг-выбросов: поды перестают наследовать масштаб параллелизма хоста по умолчанию. Явный вызов GOMAXPROCS полностью отключает автоматическое поведение. Для раздельного управления есть GODEBUG-флаги:

GODEBUG=containermaxprocs=0  # выключить чтение cgroup
GODEBUG=updatemaxprocs=0     # выключить динамическое обновление

Что не решено Рантайм использует только limits.cpu, не requests. Под без лимита ведёт себя как обычный процесс на хосте. NUMA, cpuset pinning, CPU Manager static — вне зоны ответственности. Квоту рантайм вычитает один раз при старте, миграцию процесса в другой cgroup он не замечает. Учёта топологии тоже нет. Рантайм не моделирует локальность сокетов, разделение кеша, размещение в NUMA. На многосокетной машине контексты P всё равно могут оказаться на далёких ядрах. Это отдельная задача, не квота cgroup. Формулы GOMAXPROCS = requests.cpu и requests.cpu × 2 являются исключительно эмпирическими, официальной поддержки таких механизмов в рантайме нет. Kubernetes requests — это сигнал для планирования, а не принудительное ограничение. Для CPU-bound сервисов штатное значение по умолчанию теперь близко к оптимальному. Для I/O-нагруженных с сетевыми патологиями троттлинг и P99 нужно измерять вместе, прежде чем что-то менять. Для NUMA-чувствительной нагрузки cgroup-aware GOMAXPROCS проблему не закрывает. Для сервиса на Go 1.25+ под Linux и Kubernetes automaxprocs можно удалить. GOMAXPROCS превратился из обязательной K8s-настройки в экспертное переопределение для тюнинга по результатам профилирования. #backendvkhub #go

Современный взгляд на паттерны проектирования Культовая книга Design Patterns «Банды четырёх» вышла в 1994 году. Многие паттерны из неё уже встроены в языки и фреймворки, а вместе с классическими появились паттерны распределённых систем. Объясняем в карточках современный взгляд на паттерны проектирования. #backendvk #designpatterns

🔵 Incus 7.0 LTS — контейнеры и VM до 2031 года Вышел новый LTS-релиз платформы управления контейнерами и виртуальными машинами. Среди ключевых изменений — поддержка OCI-контейнеров, встроенное S3-хранилище, новые драйверы хранения и отказ от устаревших cgroupv1 и iptables. 🔵 Bumblebee — защита AI-разработки от supply-chain атак Perplexity открыла исходный код сканера, который анализирует зависимости npm, PyPI и Go Modules без выполнения кода. Инструмент помогает выявлять риски в AI- и developer-инфраструктуре ещё до попадания вредоносных пакетов в пайплайны. 🔵 JavaOne 2026 — курс на HTTP/3 и современную многопоточность На конференции показали ключевые изменения JDK 26: поддержку HTTP/3, развитие Structured Concurrency и новые возможности языка. Основной фокус — производительность, сетевые приложения и упрощение конкурентного программирования. 🔵 JEP 533 — Structured Concurrency становится всё ближе к релизу API для управления группами связанных задач вышло на очередной этап превью. Подход упрощает отмену операций, обработку ошибок и делает многопоточный код заметно предсказуемее. 🔵 JEP 534 — компактные заголовки объектов в HotSpot OpenJDK планирует включить Compact Object Headers по умолчанию. Изменение уменьшает потребление памяти и может дать дополнительный выигрыш в производительности за счёт лучшей работы процессорного кэша. 🔵 Go SIM DB — база данных для AI-агентов вместо LSP В сообществе обсуждают новый подход к анализу кодовых баз: SQLite-совместимое хранилище, оптимизированное для работы AI-инструментов. Тренд показывает, как экосистема разработки начинает адаптироваться под агентные сценарии. #backendvkhub #дайджест

Классический сценарий в проде: запрос не меняли, данные те же, а время выросло в разы — и не сразу, а после некоторого числа выполнений. Причина почти всегда в том, как PostgreSQL кэширует планы за параметризованными запросами. #backendvkhub #postgresql

Проблема двойной записи и transactional outbox Типичная задача: сервис создаёт заказ и должен и сохранить его в базу, и сообщить о нём другим сервисам — через Kafka, RabbitMQ или вызов API. Очевидное решение выглядит так:

    db.insert(order)                        # запись в БД
    kafka.publish("order.created", order)   # публикация события

Этот код содержит баг, который не виден на тесте и проявляется под нагрузкой или при сбоях. Две операции идут в две разные системы, и общей транзакции между ними нет. Разберём поведение при сбое. Если процесс упадёт после db.insert, но до kafka.publish — заказ в базе есть, события нет, другие сервисы о заказе не узнают. Если поменять порядок и публиковать первым — при падении после publish событие ушло, а заказа в базе нет: подписчики обработают заказ, которого не существует. Любой порядок двух записей в две системы оставляет окно, в котором состояние рассинхронизировано. Это и есть dual-write problem. Сетевой ретрай не спасает. Брокер может принять сообщение, но ответ потеряется по таймауту — сервис не знает, опубликовалось ли событие, и повторная отправка либо продублирует его, либо снова упрётся в ту же неопределённость. Корень проблемы — попытка получить атомарность поверх двух систем без распределённой транзакции. Решение — свести задачу к одной системе, где атомарность уже есть. У базы есть транзакции; значит, факт «событие нужно отправить» должен записываться в ту же базу и в той же транзакции, что и сам заказ. Это паттерн transactional outbox. К таблицам данных добавляется таблица исходящих сообщений:

    id            bigserial PRIMARY KEY,
    topic         text NOT NULL,
    payload       jsonb NOT NULL,
    created_at    timestamptz DEFAULT now(),
    published_at  timestamptz
);

Сервис записывает заказ и сообщение одной транзакцией:

    with db.transaction():
        db.insert(order)
        db.insert_outbox("order.created", order)

Сбой между двумя записями теперь невозможен: либо транзакция коммитится целиком — и заказ, и строка в outbox, либо откатывается целиком. Состояние БД всегда согласовано. Остаётся доставить то, что лежит в outbox, в брокер. Этим занимается отдельный процесс — релей. Он читает неопубликованные строки и отправляет их:

    rows = db.query(
        "SELECT * FROM outbox WHERE published_at IS NULL "
        "ORDER BY id LIMIT 100"
    )
    for row in rows:
        kafka.publish(row.topic, row.payload)
        db.execute(
            "UPDATE outbox SET published_at = now() WHERE id = %s",
            row.id,
        )

Здесь важно то, что релей может опубликовать сообщение в Kafka и упасть до того, как проставит published_at. На следующем проходе он отправит то же сообщение снова. Outbox гарантирует доставку at-least-once — каждое событие дойдёт хотя бы раз, но возможны повторы. Поэтому потребители событий обязаны быть идемпотентными: повторная обработка того же события не должна давать повторный эффект. Это связывает outbox с идемпотентностью на стороне потребителя — первый паттерн гарантирует, что событие не потеряется, второй, что повтор не навредит. У polling-релея есть цена, он постоянно опрашивает таблицу. Альтернатива — change data capture: релей читает не таблицу, а WAL базы (через Debezium и подобные инструменты) и реагирует на коммиты в outbox без опроса. Механика доставки другая, контракт тот же: запись данных и события атомарна, доставка — at-least-once. Практический вывод очень простой. Как только в коде рядом стоят запись в базу и обращение к внешней системе — брокеру, платёжному шлюзу, другому сервису, — это уже кандидат на dual-write баг. Если обе операции должны произойти вместе, одну из них нужно свести к записи в ту же базу, а фактическое действие вынести в отдельный надёжный процесс. #backendvkhub

До 18-й версии PostgreSQL читал страницы с диска синхронно: на каждый промах кеша вызывался блокирующий pread(), бэкенд останавливался и ждал ответ ядра. На AWS EBS gp3 это около 1–2 мс на блок, и большое последовательное сканирование упиралось не в диск, а в накопленное ожидание. Спасались привычным набором: увеличенный shared_buffers, parallel workers, реплики на чтение. В 18 появилась подсистема AIO и параметр io_method с тремя значениями: sync, worker (по умолчанию), io_uring. Параметр требует рестарта.

io_method = io_uring
io_workers = 3                  # учитывается только для worker
effective_io_concurrency = 16   # дефолт в 18, было 1
io_combine_limit = 128kB

sync повторяет поведение 17 — для отката, если новая подсистема даёт регрессию. worker поднимает фоновые процессы, принимающие read-запросы через shared memory; бэкенд кладёт пачку запросов и продолжает обрабатывать предыдущие страницы. Издержки — context switch и конкуренция за очередь. io_uring обращается к ядру напрямую через ring buffer Linux 5.1+, без syscall на каждый блок; требует сборки с --with-liburing и kernel.io_uring_disabled = 0. Бенчмарки pganalyze и CYBERTEC на c7i.8xlarge с EBS показывают прирост 2-3× по throughput на cold-cache sequential scan при переходе с sync на io_uring. На локальном NVMe эффект скромнее: BetterStack получили 24% (2913 → 2221 мс), PlanetScale на своих Metal-серверах разницы между worker и io_uring практически не увидели, диск перестал быть узким местом. Для наблюдения появилось два инструмента. Функция pg_get_aios() возвращает все запланированные операции с их состоянием:

FROM pg_get_aios();

В pg_stat_io добавились разрезы по асинхронным чтениям — видно, сколько байт прошло мимо синхронного пути и сколько времени ушло на ожидание completion. Еще есть несколько мест, где легко ошибиться. Во-первых, AIO работает только на чтения: WAL и обычные writes остались синхронными. Во-вторых, EXPLAIN ANALYZE может занижать I/O time, потому что часть работы делается в воркерах и backend этого не видит, — для диагностики берите pg_stat_io. В-третьих, effective_io_concurrency теперь напрямую управляет числом параллельных read-ahead запросов: на network storage его имеет смысл повышать до 32–64, на локальном NVMe оптимум обычно меньше. Neon и Supabase пока держат io_method = sync — их prefetch-механика интегрирована с собственным storage layer и переписывается под новый интерфейс отдельно. Если обновляетесь на 18 на своих серверах, начните с worker, снимите профиль через pgbench и pg_stat_io, и только потом переключайтесь на io_uring, если у storage остался запас. #backendvkhub #asyncio #postgresql

Ранее мы кратко писали о том, что в марте вышла Java 26 с 10 JEP. Structured Concurrency, Scoped Values, Flexible Main Methods, Derived Record Creation, HTTP/3, улучшения G1 GC. Релиз платформенный, ускоряет JVM и упрощает конкурентность. ➡️ Разобрали подробности в карточках. #backendvk #java26

Джависты, помогите по-братски примите участие в большом исследовании! 💙 Вместе с JUG Ru Group составляем полную картину современной Java-разработки. Пожалуйста, пройдите опрос, он займёт не больше 20 минут. По итогам мы сделаем большой отчёт и поделимся результатами с вами! P. S. Среди участников опроса JUG Ru Group разыграет 5 офлайн- и 10 онлайн-билетов на свои конференции. Ваш шанс 😏

python tooling на Rust uv, ruff, ty — три инструмента, которые заменяют солянку из pyenv, pip, venv, conda, Poetry, Black, Flake8, isort и mypy. Все три написаны на Rust, потому что сам python медленно делает то, что должно быть быстрым — разрешение зависимостей, парсинг AST и статический анализ. Когда pip install занимает минуту, а полный линтинг работает полминуты, то разработчик либо отключает проверки, либо привыкают к медленному CI. Использование Rust устраняет этот компромисс. На типичном проекте pip install -r requirements.txt занимает 60-120 секунд, uv sync на том же наборе 5-10 секунд. ruff check сканирует сотни тысяч строк за секунду, заменяя Flake8, Black и isort одним бинарником. ty check проверяет 50к строк за 150 мс, в то время как mypy на том же коде будет работать больше секунды. ➡️ Единый стек

# было
pip install -r requirements.txt
black . && flake8 . && isort .
mypy .

# стало
uv sync
uvx ruff check --fix .
uvx ty check .

Инструменты Astral объединены конфигурацией через pyproject.toml и лаунчером uvx. Workspaces для монорепозиториев заимствованы из Cargo: несколько пакетов, один uv.lock, консистентные зависимости между сервисами. К началу 2026 года uv стал дефолтным инсталлером во многих CI-пайплайнах и сократил шаг установки с двух минут до десяти секунд. Ruff включает 800+ линт-правил с автофиксом и встроенный LSP-сервер на Rust (стабилизирован в 0.5.3). Ty работает как language server с навигацией, подсказками типов и автоимпортами. Одна команда для установки окружения, одна для линтера, одна для проверки типов. Lockfile один на весь монорепозиторий. ➡️ Ограничения Ty в бете и пока не поддерживает плагины для Pydantic, Django, SQLAlchemy. Глобальный кэш uv разрастается до 20 ГБ за год. Кроме того, uv строго разрешает зависимости, поэтому проекты с грязной историей pip freeze могут не собраться и требуют чистки freeze-файлов. Результат работы Ruff практически идентичен связке black + flake8 + isort, но при миграции на него диффы в гите всё же появятся. Astral куплена OpenAI в марте 2026. Инструменты open source, но зависимость от одного вендора необходимо учитывать при выборе инфраструктуры. Если заводите новый проект, то смело берите uv + ruff + ty с первого дня. Миграцию же старого проект лучше начинать с uv и ruff, а ty подключать параллельно с mypy с флагом --add-ignore и переводить ошибки по мере роста уверенности. 👇 А вы уже перешли на связку uv + ruff + ty? #backendvk #python #pythontooling