False sharing и горячие пути нативных мостов

Команда потратила неделю, делая массив счётчиков lock-free с атомарными операциями. Под нагрузкой он работает медленнее, чем заблокированная версия. Flame graph показывает updateCounter широким, IPC 0.42. Тем временем Rust-библиотека криптографии простаивает 92% времени. Node-сервис вызывает её 10 000 раз в секунду — и 40% CPU в N-API stub, а не в коде криптографии.

False sharing: когда «lock-free» медленнее заблокированного

False sharing происходит, когда несколько потоков записывают в разные поля, которые случайно находятся на одной cache line. MESI coherency-протокол оборудования рассматривает cache line как атомарную единицу владения. Когда один CPU записывает в любой байт 64-байтной линии, он захватывает эксклюзивное владение и инвалидирует линию в кеше каждого другого CPU. Каждый другой CPU, который затем читает или записывает любой байт этой линии, должен заново получить её через coherency fabric — с латентностью L3 или DRAM (~150–300 тактов), а не L1 (~5 тактов).

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

Сигнатура в профилях

False sharing не выглядит как lock contention в стандартном CPU-профиле. Нет видимого mutex, нет заблокированного потока. Вместо этого:

• IPC проседает (обычно 0.3–0.6 на затронутом коде, по сравнению с 2–4 для compute-bound кода).
• Cache-miss rate экстремальный (60–80%), даже если данные малы и «должны» быть горячими.
• Горячая функция выглядит невинно — атомарный инкремент, простая запись в поле.
• Производительность ухудшается с ростом числа потоков, а не улучшается.

Аппаратные счётчики, которые это выявляют

Аппаратное событие MEM_LOAD_L3_HIT_RETIRED.XSNP_HITM (Intel) считает загрузки, обслуженные изменённой копией в кеше другого CPU — прямой сигнал false sharing. В Linux perf stat -e cache-references,cache-misses,instructions в паре с масштабированием числа потоков выявляет это косвенно.

Исправление: выравнивание по cache line

Исправление — гарантировать, что каждое независимо записываемое поле занимает свою cache line. На x86 cache line — 64 байта; на ARM — 64 или 128 байт.

// ДО: 16 uint64 счётчиков делят 2 cache line (8 на линию)
var counters [16]uint64

// ПОСЛЕ: каждый счётчик на своей 64-байтной линии
type paddedCounter struct {
    value uint64
    _     [56]byte // дополнение до 64 байт
}
var counters [16]paddedCounter

В Java @Contended (из sun.misc.Contended или jdk.internal.vm.annotation.Contended) вставляет дополнение автоматически. В Rust crossbeam::CachePadded оборачивает значения. В C++ alignas(64) на полях структуры. Disruptor (Java) и DPDK (C) бакают явное выравнивание cache line в свои базовые структуры данных как не обсуждаемый инвариант.

# perf stat -e cache-references,cache-misses,L1-dcache-load-misses,instructions ./service

 1,250,000,000      cache-references
   950,000,000      cache-misses           # 76% miss rate — экстремальный
 1,200,000,000      L1-dcache-load-misses  # почти каждый L1 доступ промахивается
 3,000,000,000      instructions
                    IPC = 0.42             # CPU stalled 58% of the time

# Profile shows hot leaf:
#   updateCounter(idx int):
#     atomic.AddUint64(&counters[idx], 1)   # supposed lock-free fast path

# counters[] — плоский массив из 16 uint64 значений, 16 worker-
# горутин обращаются к нему (каждая инкрементирует свой индекс).
# CPU: 16 ядер. uint64 — 8 байт; cache line — 64 байта.

Горячие пути нативных мостов: ловушка FFI overhead

Современные runtime’ы соединяются с нативным кодом через FFI: N-API в Node, JNI в Java, ctypes/cffi/Cython в Python, cgo в Go. Каждый переход через мост несёт фиксированные накладные расходы:

• N-API (Node → нативный аддон): ~50–200 нс за вызов.
• JNI (Java → нативный): ~100–500 нс за вызов.
• cgo (Go → C): ~200–500 нс за вызов (включает переключение стека горутины).
• Python ctypes: ~1–5 мкс за вызов.

Когда нативная функция дорогая (миллисекунды), эти накладные расходы несущественны. Когда нативная функция дешёвая (наносекунды), stub моста может доминировать.

Сигнатура в cross-language flame graph

Стандартный однозычный профилировщик показывает только свой стек. Cross-language профиль (eBPF, Datadog continuous profiler, или вручную сшитый perf + async-profiler) показывает оба стека. Сигнатура с точки зрения профилировщика:

• Нативная функция сама по себе узкая (маленькое self-time).
• Bridge stub (Cgo_runtime_cgocall, JNIEnv::CallStaticVoidMethod, napi_call_function) широкий.

Реальный пример

Node-сервис вызывал Rust-рутину криптографии через N-API: 10 000 вызовов в секунду, каждый вычисляет 32-байтный HMAC. Сама Rust-функция занимала ~40 нс. N-API stub добавлял ~160 нс за вызов — работы в 4 раза больше. CPU-профиль: 40% в stub, 8% в реальной криптофункции.

Исправление: пакетировать 64 операции на один N-API вызов. Rust-функция получает срез из 64 входных значений и возвращает срез из 64 выходных. Per-item overhead падает с 200 нс до 43 нс (160 нс stub / 64 элемента). CPU-профиль после: 12% криптофункция, stub невидим.

Семейства исправлений для overhead нативного моста:

1. Пакетирование за переход — передавать срез входных значений, получать срез выходных. Амортизировать фиксированный overhead на N элементов.
2. Перенести цикл в нативный код — вместо N вызовов нативного кода вызвать нативный код один раз с телом цикла внутри нативной функции.
3. Поднять границу — переместить FFI-границу к более крупной операции, чтобы меньше переходов происходило на единицу работы.

Крайние случаи, где «широкий фрейм = большая проблема» лжёт

Три ситуации, где самый широкий leaf не является правильной целью атаки.

1. Коротко живущие горячие пути, выпадающие из сэмплирования

Функция, вызываемая 500 000 раз в секунду по 200 нс каждый раз, работает 100 мс/с — 10% одного CPU-секунды. При стандартной частоте сэмплирования 100 Гц профилировщик срабатывает ~10 раз в секунду. Ожидаемые сэмплы: 1. Реальные сэмплы: 0 или 1, в зависимости от выравнивания.

Фрейм узкий во flame graph, но является главным потребителем. Диагностика: инструментировать дешёвыми счётчиками (атомарные инкременты + гистограмма Prometheus) или временно повысить частоту сэмплирования до 1000 Гц в течение выделенного окна профилирования.

2. Spin-wait, доминирующий в CPU-профиле

CPU-профиль показывает функцию широкой, потому что программа выполняла spin-wait внутри неё — busy-loop, ожидающий выполнения условия. Поток находится на CPU, тратя такты, но не делает реальной работы. Исправление — не оптимизировать тело spin; нужно преобразовать spin в правильное ожидание (futex, condition variable, channel).

Сигнатура: тело функции — плотная ветвь обратно на себя; IPC низкий, несмотря на то что в профиле это CPU-bound; rate переключений контекста низкий (поток никогда не уступает).

3. Сбои разрешения символов

Широкий фрейм [unknown] — это не функция, это стек, который профилировщик не может разрешить. Распространённые причины: JIT-скомпилированный код без perf maps (Node нужен --perf-basic-prof; JVM нужен -XX:+PreserveFramePointer), stripped DWARF debug info, отсутствующие kernel symbols.

Перед тем как рассматривать [unknown] как цель, исправить разрешение символов. Скрытая функция может быть реальным горячим путём.