Базы данных
Производственные режимы отказа и стабильность планов
Суть Восемь реальных режимов отказа — устаревшая статистика, ловушка общего плана, коррелированные колонки, неверная настройка SSD, накладные расходы JIT, сброс work_mem, дрейф random_page_cost и перескоки — плюс стратегия обнаружения и предотвращения регрессий планов между деплоями.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеDashboard заказов B2B SaaS-продукта деградирует каждое воскресенье утром. Ко вторнику всё в порядке. Паттерн: пакетный импорт запускается в воскресенье ночью, сдвигая распределения данных; autovacuum не успевает запустить ANALYZE к понедельнику; планировщик выбирает Nested Loop с недооценкой соединения в 1000×. ANALYZE в хуке после пакетной обработки навсегда устраняет инцидент.
Восемь реальных производственных режимов отказа
| Режим отказа | Симптом | Исправление |
|---|---|---|
| Каскад устаревшей статистики | Внезапное замедление после массовой вставки; rows-estimated резко отличается от actual | ANALYZE в post-batch хуке; снизить autovacuum_analyze_scale_factor |
| Ловушка общего плана | Высокое stddev_exec_time; бимодальная задержка на подготовленном операторе | plan_cache_mode = force_custom_plan для роли |
| Взрыв коррелированных колонок | Nested Loop с 1M итераций; rows-estimated ~1000× ниже | CREATE STATISTICS (dependencies, mcv); ANALYZE |
| Неверная настройка random_page_cost (SSD) | Планировщик выбирает Seq Scan там, где должен был бы Index Scan; запросы читают целые таблицы | SET random_page_cost = 1.1 в postgresql.conf |
| Накладные расходы JIT на OLTP | Короткие запросы медленнее ожидаемого; время компиляции JIT превышает экономию выполнения | Поднять jit_above_cost до 500000 или SET jit = off для OLTP-роли |
| Сброс work_mem | Sort Method: external merge; Hash Batches > 1; медленные запросы при соединениях/сортировках | SET work_mem = ‘32MB’ на сессию; не глобально без проверки бюджета памяти |
| Слишком малый effective_cache_size | Планировщик предпочитает Seq Scan даже на SSD с большой RAM, потому что предполагает холодные данные | SET effective_cache_size = ‘24GB’ (~75% общей RAM) |
| Перескоки плана при смене фазы нагрузки | Один и тот же запрос получает разные планы в разное время; autovacuum в конце концов восстанавливает баланс | pg_hint_plan для критических путей; иначе принять вариативность и алертить на неё |
Стабильность планов между деплоями
Наиболее распространённая операционная боль: деплой с новыми таблицами, новыми данными или другими объёмами вызывает регрессии планов на неизменённых запросах.
Пятиуровневая стратегия:
Уровень 1 — настройка константных стоимостей (один раз): Установите random_page_cost = 1.1, effective_cache_size в 75% RAM, work_mem = 16-32MB. Проверьте через EXPLAIN на top-20 запросах. Это обеспечивает правильную ментальную модель вашего железа у планировщика.
Уровень 2 — свежесть статистики: Снизьте autovacuum_analyze_scale_factor = 0.02 на горячих таблицах. Добавьте ANALYZE critical_tables в каждый deploy-хук. Создайте объекты CREATE STATISTICS для коррелированных групп колонок, выявленных через EXPLAIN.
Уровень 3 — кеш планов для косых нагрузок: Установите plan_cache_mode = 'force_custom_plan' на ролях, выполняющих параметризованные запросы с косыми распределениями параметров (выявлены через высокое stddev_exec_time).
Уровень 4 — наблюдаемость: Настройте auto_explain (log_min_duration = 500мс, log_analyze = true, log_buffers = true, log_format = json, sample_rate = 0.05). Архивируйте pg_stat_statements еженедельно (reset + сохранить в файл/S3).
Уровень 5 — процедура деплоя: Перед каждым деплоем делайте снимок pg_stat_statements + EXPLAIN top-20 запросов в JSON. После деплоя: ANALYZE критических таблиц, подождать 5 минут, повторный снимок. Diff ключевых метрик. Флажить любой запрос, чья структура плана изменилась или чей mean_exec_time вырос более чем на 50%.
Проследи
1/5 Старший инженер настраивает Postgres 16 OLTP базу данных на NVMe SSD (32 ГБ RAM, 500 ГБ БД, ~5k QPS), задеплоенную с настройками планировщика по умолчанию.
1
Step 1 of 5
Шаг 1: базовая линия.
Сделать снимок pg_stat_statements: top запросы по total_exec_time, mean_exec_time, stddev. Захватить EXPLAIN (ANALYZE, BUFFERS) для top-20. Отметить: какие используют Seq Scan на больших таблицах? Какие сбрасываются (Hash Batches > 1, Sort Method: external merge)? Какие имеют большой разрыв rows-estimated vs actual? Какие имеют высокое stddev? Сохранить планы как JSON для последующего сравнения.
2
Locked
Шаг 2: настройка стоимостей для SSD.
ALTER SYSTEM SET random_page_cost = 1.1; ALTER SYSTEM SET effective_cache_size = '24GB'; SELECT pg_reload_conf(); Проверить: SHOW random_page_cost. Повторно запустить EXPLAIN на top-20. Ожидать, что некоторые планы сдвинутся с Seq Scan на Index Scan — это правильно на SSD. Для любого сдвига, выглядящего как регрессия, инспектировать per-query перед продолжением.
3
Locked
Шаг 3: обновление и расширение статистики.
ANALYZE; -- вся база данных. Для высококосых колонок: ALTER TABLE ... ALTER COLUMN ... SET STATISTICS 1000. Для коррелированных групп колонок: CREATE STATISTICS (dependencies, mcv) ON col1, col2 FROM tbl. Повторно ANALYZE. Повторный EXPLAIN top запросов; rows-estimated должен отслеживать rows-actual в пределах 2x на большинстве узлов.
4
Locked
Шаг 4: память и JIT.
SET work_mem = '16MB' в postgresql.conf (с бюджетом max_connections: 200 × 16MB = 3.2GB в худшем случае). Снизить autovacuum_analyze_scale_factor на горячих таблицах. Для только-OLTP нагрузок: ALTER SYSTEM SET jit_above_cost = 500000 или SET jit = off для роли приложения.
5
Locked
Шаг 5: наблюдаемость.
Настроить auto_explain (log_min_duration = '500ms', log_analyze = true, log_buffers = true, sample_rate = 0.05). Настроить еженедельный pg_stat_statements_reset() с архивированием снимка предыдущей недели. Настроить алерты: любой top-20 запрос mean_exec_time > 50мс, или stddev_exec_time > 10x mean. Задокументировать все настройки с обоснованием — каждое не-дефолтное значение требует комментария.
✓ Прослежено.
Команде нужно стабилизировать планы выполнения между деплоями для top-20 OLTP запросов. Выберите стратегию.
Правильный ответ для ~90% случаев. Свежая, точная статистика позволяет планировщику принимать верные решения даже при росте данных. CREATE STATISTICS для коррелированных колонок устраняет самый большой класс ошибок оценки строк. auto_explain автоматически улавливает регрессии. Стоимость: несколько ANALYZE в post-deploy хуке + конфигурация auto_explain + еженедельный просмотр дельт pg_stat_statements. Сохраняет способность планировщика адаптироваться при изменении форм данных.
Правильно для критически важных по стабильности запросов, где стоимость регрессии > выгоды адаптации (финансовая отчётность, эндпоинты с фиксированным SLA). Встройте хинты в SQL: /*+ IndexScan(orders idx_x) HashJoin(orders customers) */. Торгует адаптивностью планировщика на предсказуемость — завтрашняя форма данных может сделать сегодняшний хинт неверным. Резервируйте для 1-3 запросов, которые абсолютно не могут деградировать; для остального используйте статистику-прежде-всего.
Заставляет Postgres уважать явный порядок JOIN в SQL — полезно когда разработчики вручную настроили запросы и хотят сохранить настройку при изменении данных. Глобальный флаг — кувалда; устанавливает для каждого запроса. Лучше как per-session или per-role для аналитических нагрузок. Побочный эффект: большие OLTP-запросы могут пропустить оптимальный порядок соединений. Используйте избирательно, не глобально.
Иногда встречается в установках с экстремальным масштабированием. Неверный по умолчанию. Изобретение кеширования планов вне Postgres добавляет операционную сложность, ломает инструментарий и плохо стареет. Используйте только когда ни один нативный механизм Postgres (хинты, статистика, plan_cache_mode) не достаточен — что редко.
Викторина
Completed
Пакетное задание вставляет 20M строк в таблицу orders каждое воскресенье ночью. Каждое понедельное утро запросы, быстрые в пятницу, медленные. Ко вторнику снова нормально. Какова корневая причина и исправление?
Heads-up Полезность индекса зависит от селективности, а не только от размера таблицы. Проблема — в устаревшей статистике, а не в раздутости индексов.
Heads-up Паттерн (медленно в понедельник, нормально ко вторнику) соответствует dogоняющему autovacuum, а не разнице трафика.
Heads-up Конкуренция за блокировки проявляется как ожидающие запросы, а не медленные. И разрешается когда транзакция завершается, а не ко вторнику.
Викторина
Completed
Запрос показывает `Sort Method: external merge Disk: 450MB` в EXPLAIN ANALYZE. Каковы интерпретация и исправление?
Heads-up External merge означает, что данные не поместились в work_mem и Postgres использовал диск — это проблема производительности, не норма.
Heads-up Индекс иногда может устранить сортировку, но симптом external merge — про work_mem, а не наличие индекса.
Heads-up External merge — это запланированная сортировка на диске, а не симптом повреждения.
- 01Объясните, почему разрыв между rows-estimated и rows-actual на каждом узле плана является единственным наиболее важным диагностическим показателем в Postgres.
- 02Спроектируйте стратегию стабильности планов для B2B SaaS Postgres 16 базы данных на NVMe SSD (32 ГБ RAM, 500 ГБ БД, 5k OLTP QPS). Top-20 запросов выявлены через pg_stat_statements. 3 из 20 — тяжёлые агрегации.
Итог
Восемь производственных режимов отказа покрывают большинство регрессий планов Postgres: устаревшая статистика после массовых операций (ANALYZE в post-batch хуке), ловушка общего плана на подготовленных операторах с косыми параметрами (plan_cache_mode = force_custom_plan), ошибки оценки строк для коррелированных колонок (CREATE STATISTICS dependencies + mcv), неверная настройка SSD (random_page_cost = 1.1), накладные расходы JIT на OLTP (поднять jit_above_cost), сброс work_mem (сортировка/хеш сбрасываются на диск — исправить per-session), несоответствие effective_cache_size и перескоки планов при смене фазы данных. Операционная стратегия имеет пять уровней: откалиброванные под SSD константные стоимости, агрессивное обслуживание статистики, избирательные переопределения plan_cache_mode, наблюдаемость auto_explain + pg_stat_statements и процедура деплоя, сравнивающая планы и метрики до и после каждого деплоя. Используйте pg_hint_plan только для 1-3 запросов, где план должен быть закреплён и правильная форма плана постоянно известна; давайте планировщику адаптироваться ко всему остальному.
Практика
Сделай это, чтобы превратить узнавание в навык.
Связанные уроки
встречается в258
- Почему GraphQL получает N+1junior
- Механика DataLoader: батчинг на границе тикаmiddle
- Контракты batch-функции: порядок, формы, ошибкиmiddle
- Federation и lookahead: батчинг за пределами DataLoadermiddle
- Защита сложности запросов: depth, cost, persisted queriesmiddle
- Senior GraphQL API: scheduling-контракт, изоляция арендаторов, наблюдаемостьsenior
- Путь запроса: семь остановок от сокета до ответаjunior
- Accept и парсинг: от очереди ядра до типизированного запросаmiddle
- Маршрутизация и middleware: что выполняется и в каком порядкеmiddle
- Обработчик и ответ: от бизнес-логики до байтов на проводеmiddle
- Стриминг и backpressure: когда клиент читает медленнее, чем вы пишетеsenior
- Таймауты и хвостовая задержка: бюджеты, дедлайны и ловушка fan-outsenior
- Middleware и DI: два паттерна, формирующие любой backendjunior
- Пишем middleware: сигнатуры, next() и три модели фреймворковmiddle
- Инверсия управления: как зависимости добираются до классаmiddle
- Скоупы и время жизни DI: singleton, request, transientmiddle
- DI как шов для тестов: фейки, моки и граница, которая важнаsenior
- DI-контейнеры в продакшене: графы разрешения, циклы и когда не стоитsenior
- Блокирующий vs неблокирующий I/O: два способа ждатьjunior
- Event loop: один поток, упорядоченные фазыmiddle
- Что блокирует цикл: CPU-работа и синхронные вызовыmiddle
- Вынос CPU-работы: worker threads и пул libuvmiddle
- Backpressure и ограниченная конкурентностьsenior
- Пропускная способность под нагрузкой: хвостовая задержка и насыщениеsenior
- Зачем пул: цена создания соединенияjunior
- Размер пула: почему больше не значит быстрееmiddle
- Взятие и таймауты: очередь ожидания — настоящий дроссель задержкиmiddle
- Зачем идемпотентность: безопасные retryjunior
- Серверный state machine: четыре состояния idempotency keymiddle
- Стратегии retry: backoff, jitter и thundering herdmiddle
- Outbox и inbox: effectively-once через dual-write границуmiddle
- Конкурентность и архитектура кеша для идемпотентности на масштабеsenior
- Наблюдаемость, production-инциденты и дизайн для глобального масштабаsenior
- Event loop: один поток, три очередиjunior
- Задачи, микрозадачи и scheduler.yield()middle
- Точность таймеров, троттлинг и фоновая работаmiddle
- Голодание микрозадач, длинные задачи и LoAFsenior
- Event loop Node.js: фазы, nextTick и задержка циклаsenior
- React, Vue и наблюдаемость INP в продакшенеsenior
- Render pipeline: шесть стадий от байтов до пикселейjunior
- Цена стадий и модель процесса рендерераmiddle
- Инвалидация, dirty-биты и containmiddle
- Слои композитора: продвижение, перекрытие и память GPUmiddle
- Флейм-стрип DevTools и жизненный цикл кадраmiddle
- Layout thrash: форсированная синхронная компоновкаsenior
- BeginMainFrame, анимации на потоке compositor и память GPUsenior
- Observability в проде: LoAF, INP и полная поверхность атакиsenior
- Что такое V8 и почему производительность различается в 100 разjunior
- Четырёхуровневый JIT-конвейер V8 и профилированная тиеризацияmiddle
- Hidden classes, деревья переходов и расположение в памятиmiddle
- Inline caches, состояния IC и деоптимизацияmiddle
- Orinoco GC: параллельный scavenger, конкурентная разметка и барьеры записиmiddle
- Спекулятивный движок TurboFan и ловушка deopt-loopsenior
- V8 в production: Isolates, сжатие указателей и реальные аварииsenior
- Жизненный цикл service worker и стратегии кешированияmiddle
- Граничные случаи service worker: version skew, долговременность и ловушка навигацииsenior
- Что делает реконсилер: render vs commitjunior
- Объект fiber и дерево с двойной буферизациейmiddle
- Чистота фазы render и подшаги фазы commitmiddle
- Реконсиляция: эвристики диффа и ловушка ключейmiddle
- Приоритетные lanes, time-slicing и useTransitionmiddle
- Bailout, мемоизация и tearingsenior
- React Profiler, компилятор и продакшн-наблюдаемостьsenior
- Стратегии рендеринга: SSG, SSR, ISR, streaming и гидратацияjunior
- SSG, SSR, ISR, streaming и RSC — как работает каждая стратегияmiddle
- Цена гидратации: selective, progressive, острова, resumabilitymiddle
- Hydration mismatch: причины, обнаружение и правило детерминизмаsenior
- RSC, стратегия на маршрут и production-наблюдаемостьsenior
- Core Web Vitals: что измеряют LCP, INP и CLSjunior
- LCP: четыре фазы, одна доминирующая стоимостьmiddle
- INP: input delay, processing, presentationmiddle
- CLS: почему происходят сдвиги лейаута и как их остановитьmiddle
- Lab vs field: почему они расходятся и как использовать каждыйmiddle
- Трейдоффы метрик, RUM-атрибуция и цикл CI+полеsenior
- Общая картина: от URL до LCP до INP как эстафетаjunior
- Восемь слоёв трассировки: от service worker до второй навигацииmiddle
- Пять канонических поломок: где производство стабильно ломаетсяsenior
- Метод трёх треков: чтение трасс и построение системы мониторингаsenior
- Что такое cache stampede и почему он делает всё хужеjunior
- Лок и single-flight: ограничение параллельных rebuildmiddle
- XFetch: вероятностное раннее истечение без координацииmiddle
- Stale-while-revalidate и CDN request coalescingmiddle
- Детектирование stampede и дизайн TTL для продакшенаmiddle
- Метастабильный сбой, fencing-токены и production-постмортемыsenior
- Роли Raft, term и почему majority-кворум предотвращает split brainjunior
- Как Raft реплицирует log entry и решает, что его безопасно коммититьmiddle
- Выборы лидера в Raft: таймауты, правила голосования и четыре свойства безопасностиmiddle
- Raft в реальном мире: partition, медленный диск и клиентская маршрутизацияmiddle
- Расширения Raft: pre-vote, learner, snapshot и линеаризуемые чтенияsenior
- Raft в production: membership change, Multi-Raft и observabilitysenior
- Где происходит data fetching — и почему это решает LCPjunior
- Fetch waterfall''''ы — диагностика и лечение через Promise.allmiddle
- React Server Components и Suspense streamingmiddle
- Клиентский кэш: TanStack Query, SWR и stale-while-revalidatemiddle
- LCP, prefetch и race conditions в интерактивном fetchingmiddle
- Senior internals: RSC payload, слои кэша и production паденияsenior
- Биты в проводеjunior
- Математика задержкиmiddle
- Bufferbloat и перегрузкаsenior
- Граница физического уровняsenior
- Трёхстороннее рукопожатие TCPjunior
- Номера последовательности и состояние соединенияmiddle
- Управление потоком и перегрузкойmiddle
- BBR, производственная наблюдаемость и за пределами TCPsenior
- DNS: что делает и зачем существуетjunior
- Обход резолвера: перенаправления, типы записей и gluemiddle
- TTL, кеширование и распространение DNSmiddle
- Рукопожатие за 1 RTT: key share и ECDHEmiddle
- Возобновление сессии и 0-RTTmiddle
- CDN: контент по соседствуjunior
- Anycast и GeoDNS: маршрутизация к ближайшему edgemiddle
- Многоуровневый кеш и Cache-Controlmiddle
- Заголовок Vary и cache keysmiddle
- Stale-while-revalidate и cache stampedesenior
- Edge workers и edge-side compositionsenior
- CDN: операции и observabilitysenior
- WebSocket: HTTP-апгрейд до постоянного соединенияjunior
- Формат WebSocket-фрейма: opcodes, маскирование, фрагментацияmiddle
- WebSocket vs SSE vs long-polling: выбор правильного транспортаmiddle
- Backpressure в WebSocket: когда клиенты не успеваютmiddle
- Реконнект: jittered backoff, thundering herd, восстановление сообщенийsenior
- WebSocket в масштабе: HTTP/2 мультиплексирование, permessage-deflate, C10Msenior
- WebSocket в production: прокси, безопасность и распределённая архитектураsenior
- Что делают обратные проксиjunior
- Алгоритмы балансировки: от round-robin до power-of-two-choicesmiddle
- L4 vs L7 балансировка и сохранение IP клиентаmiddle
- Health checks, connection draining и slow startmiddle
- Session affinity, consistent hashing и правильное решениеmiddle
- Retry-бури, circuit breakers и load sheddingsenior
- Устойчивая архитектура LB: anycast, zone-aware маршрутизация и observabilitysenior
- Почему QUIC, а не TCP+TLSjunior
- QUIC-потоки и head-of-line blockingjunior
- Объединённое рукопожатие и 1-RTTmiddle
- Connection ID и миграция сетиmiddle
- Обнаружение потерь и управление перегрузкойmiddle
- Возобновление 0-RTT и шифрование пакетовsenior
- Развёртывание и стоимость CPUsenior
- DDoS: что это и почему работаетjunior
- Атаки усиления и истощение состоянияmiddle
- Ограничение скорости: алгоритмы и архитектураmiddle
- WAF, межсетевые экраны, mTLS и HSTSmiddle
- Отравление DNS-кэша и BGP-перехватsenior
- Эшелонированная защита и экономика атакsenior
- Двенадцать слоёв: один URL, семь действующих лицjunior
- DNS, TCP, TLS по очереди: куда уходят миллисекундыmiddle
- Критический путь рендеринга и Core Web Vitalsmiddle
- Перехват прокси и шлюзы безопасности: rate limiter, WAF, mTLSmiddle
- Альтернативные пути: QUIC 0-RTT, WebSocket upgrade, миграция соединенияmiddle
- Наблюдаемость: распределённые трейсы, USE/RED и семплированиеsenior
- Устойчивость: каскадные повторы, circuit breakers и error budgetsenior
- Что такое три сигнала: метрики, логи, трейсыjunior
- Метрики и cardinality: cost-модель time-series databasemiddle
- Логи и объём: cost-модель структурного логированияmiddle
- Трейсы и сэмплирование: cost-модель distributed tracingmiddle
- Join-ключи и exemplar''''ы: как три сигнала становятся компонуемымиmiddle
- Observability 2.0: широкие события и сдвиг стоимостиsenior
- Режимы сбоя и инженерная практика: cardinality budget''''ы, PII и сэмплированиеsenior
- Зачем нужны структурные логи: дневник против таблицыjunior
- Схема продакшн-лога: поля, которые несёт каждая строкаmiddle
- Log levels и маршрутизация алертовmiddle
- Стратегии sampling и стоимость логовmiddle
- PII-редакция и log injectionsenior
- Propagation trace-контекста в логахsenior
- OTel Logs Data Model и audit-логи как подсистемаsenior
- Сигналы OTel, Semantic Conventions и проводной формат OTLPmiddle
- Авто-инструментирование и ручные спаны: правило 80/20 в OTelmiddle
- Collector OTel: receivers, processors, exporters и паттерны развёртыванияmiddle
- Стратегии сэмплирования: head, tail и parent-basedmiddle
- Vendor-нейтральность, eBPF-инструментирование, Operator и OTel в браузере и serverlesssenior
- Эксплуатация OTel Collector: надёжность, version skew, режимы отказа и управлениеsenior
- RED и USE: два чек-листа, одна дисциплина триажаjunior
- Инструментация RED в Prometheus: счётчики, гистограммы и дисциплина cardinalitymiddle
- USE на Linux: CPU, память, диск, сеть и PSImiddle
- Golden signals, структура дашборда и auto-RED в service meshmiddle
- Cardinality как драйвер затрат: label, PII, exemplars и семплированиеmiddle
- Native histograms, SLO и паттерны production-сбоевmiddle
- SLI, SLO и error budget: надёжность в числахjunior
- Выбор SLI и SLO-целей: отношения, не ощущенияmiddle
- Multi-window multi-burn-rate-алертинг: почему AND лучше ORmiddle
- Error budget policy, latency SLO и составные journeysmiddle
- Iceberg SLI, математика составного SLO и SLA vs SLOsenior
- Продакшн-отказы SLO, самонаблюдаемость, безопасность и общая картинаsenior
- Flame graph: читаем картинку, которая показывает, куда ушло времяjunior
- Sampling vs instrumentation profiling: почему 99 Гц побеждает в productionmiddle
- Типы профилей: CPU, память, off-CPU, mutex — какой когда братьmiddle
- Continuous profiling: always-on flame graphs с eBPF и корреляцией trace-idmiddle
- Как flame graph строится из сэмплов и как использовать его в productionmiddle
- Linux perf, внутренности eBPF, PGO и ограничения sampling''''аsenior
- Profiling в production: безопасность, war stories, OTel profiles и дизайн инфраструктурыsenior
- Debugging-воронка: SLO → RED → trace → profilejunior
- Архитектура OTel: один SDK, четыре сигнала, один wire-форматmiddle
- Экономия на observability: удерживаем затраты в пределах 5% inframiddle
- Петля инцидента: от пейджера до постмортема до предотвращенияmiddle
- Масштаб, безопасность и ROI наблюдаемых системsenior
- Сначала профиль: измерь куда реально уходит времяjunior
- Закон Амдала и self-time: потолок любого ускорения, которое ты можешь выпуститьmiddle
- Измерительный цикл: микробенч, макробенч, prod-профиль, эффект наблюдателяmiddle
- Чтение флейм-графов: формы, профайлеры по языкам и 60-секундный сканmiddle
- Статистические baseline''''ы: почему один запуск — не измерениеmiddle
- История профайлеров и ловушки микробенчей: от Кнута до GWPsenior
- Hardware counters, профили холодного старта и безопасность профилейsenior
- Непрерывное профилирование в масштабе: затраты, CI-гейты, корреляция с трейсами и антипаттерныsenior
- Что делает путь горячим: симптом против причиныjunior
- Пять форм hotspot''''а: CPU, аллокации, кэш, лок, syscallmiddle
- Чтение parent и child chains: где применять правкуmiddle
- JIT deopt, цикл fix-and-verify и PR-time профилированиеmiddle
- Аппаратные счётчики и Intel TMA: диагностика подкатегорийsenior
- False sharing и горячие пути нативных мостовsenior
- Горячие пути в production: безопасность, хвостовая латентность и происхождение инструментовsenior
- Иерархия памяти: почему расстояние важнее числа операцийjunior
- Row-major vs column-major: порядок доступа и разрыв в 9xjunior
- Cache lines и false sharing: когда параллелизм замедляет кодmiddle
- Branch prediction: 10–30 циклов штрафа за неожиданный ifmiddle
- SIMD и data layout: AoS vs SoA и разница в 4–8xmiddle
- Hardware prefetcher, TLB и memory-level parallelismsenior
- Cache-oblivious алгоритмы, PGO и production failuressenior
- Основы GC: за что рантайм берёт налогjunior
- Алгоритмы GC: поколенческая гипотеза, concurrent marking и write barriermiddle
- GC tradeoffs: пауза, throughput, память и давление аллокацийmiddle
- Настройка GC: пейсинг, форма кучи и наблюдаемость аллокацийmiddle
- Внутреннее устройство GC: tri-color инвариант, write barriers и глубокое погружение в рантаймыsenior
- GC в production: наблюдаемость, безопасность, edge cases и управление флотомsenior
- N+1: одна логическая операция, много round-trip''''овjunior
- Семейства фиксов: JOIN, IN, preload и DataLoadermiddle
- Обнаружение N+1: query logs, APM traces и CI gatesmiddle
- DataLoader: батчинг по дереву резолверовmiddle
- Кросс-протокольный N+1: HTTP fan-out и Redis MGETmiddle
- N+1 в масштабе: исчерпание пула, изменения планов и денормализацияsenior
- Batching: амортизируй фиксированную цену каждой операцииjunior
- Окно батчинга: размер и время ожиданияmiddle
- Batching в Kafka и Postgresmiddle
- io_uring и наблюдаемость пакетированияmiddle
- От Nagle до io_uring: эволюция пакетированияmiddle
- Backpressure, изоляция сбоев и безопасность батчей в продакшенеsenior
- Что на самом деле стоит bundle: download, parse, compile, executejunior
- Core Web Vitals: LCP, INP и CLSmiddle
- Code splitting: route-level, component-level, vendor splittingmiddle
- Tree shaking и compression: удаляем то, что не используемmiddle
- Third-party scripts: тихий убийца бюджетаmiddle
- CI enforcement и RUM: делаем бюджеты рабочимиmiddle
- V8 JIT-пайплайн, HTTP-приоритеты и безопасность bundlesenior
- Цикл performance: дисциплина, а не проектjunior
- Классификация и исправление: сопоставление family bottleneck с методамиmiddle
- Observability-стек и CI gates: ловить регрессии до выпускаmiddle
- От инцидента к enforcement: SLO burn до верифицированного исправления за 35 минутmiddle
- Культура, экономика и масштаб performancesenior
- At-most-once, at-least-once, exactly-once: три контракта доставкиjunior
- Три ножки сбоя — где реально происходят дубликаты и потериmiddle
- Consumer-side dedup: самый дешёвый путь к exactly-once processingmiddle
- Kafka exactly-once semantics: idempotent producer и транзакцииmiddle
- SQS visibility timeout, DLQ и outbox patternmiddle
- Exactly-once в production: impossibility-доказательство, гибридные паттерны и реальные инцидентыsenior
- Что такое OAuth и почему пароли — не ответjunior
- Authorization code flow с PKCEmiddle
- Валидация ID-токена и управление JWKS-кешемmiddle
- Ротация refresh-токенов и scope-based least privilegemiddle
- Sender-constrained токены: DPoP и mTLSsenior
- OAuth в production: audience атаки, observability и реальные провалыsenior