Operating System Basics for Architects

Зачем

Сервис «странно тормозит» — в 80% случаев причина на OS-уровне: FD-leak, page-fault storm, syscall overhead, context-switch storm, OOM-kill, GIL-конвой. Архитектор без OS-модели не отвечает на простые вопросы: «почему Node упёрся в 1024 соединения», «почему postgres съел всю память при fork() для backup», «почему python-сервис не масштабируется добавлением потоков», «почему strace показывает 80% времени в futex». Все эти явления видны и измеримы, но только если знаешь, где смотреть.

Ещё важнее: выбор между process / thread / async на старте проекта определяет потолок производительности. Поменять модель concurrency позже — обычно переписывание с нуля. Postgres process-per-connection живёт с этим решением 30 лет и закрывает дыру pgBouncer'ом сверху; Node навсегда single-threaded; Go получил M

goroutines в 2009 году и сегодня лидирует в network services именно поэтому.

Mental model

Userspace просит — kernel делает. Между ними тонкая граница (syscall), и каждый переход стоит ~100 нс + flush регистров + кэш-эффекты. Хочешь быстрее — батчуй, или вообще убирай переходы (io_uring SQPOLL, shared memory, kernel bypass).

Три ring-уровня железа: ring 3 (userspace) → ring 0 (kernel) → ring -1 / DMA (железо). Процесс видит виртуальный address space (свою «вселенную»), kernel знает физический. MMU + TLB переводят виртуальные адреса в физические на каждом доступе к памяти. Page tables хранят это сопоставление; их обновление = invlpg или TLB shootdown (дорого, особенно в multi-core).

Три модели concurrency:

	Process	Thread	Coroutine / async
Memory	отдельный address space	shared heap	shared heap
Switch cost	~1–10 μs	~1 μs	~0.1 μs (без kernel)
Crash isolation	да	нет (один SIGSEGV — весь процесс)	нет
Communication	IPC: pipe / socket / shm / mq	mutex, atomic, futex	channel, async/await
Scale ceiling	~1–5K	~10K	миллионы (Go, Erlang)
Когда выбирать	изоляция критична (БД, sandbox)	shared state + CPU	network I/O dominated

Что на диаграмме

Четыре группы — это четыре «миры» Linux-системы:

• Userspace (ring 3) — три процесса разной модели: A (multi-thread worker pool с huge FD-table 14K/1M), B (отдельный изолированный процесс, общается с A через /dev/shm), C (Node.js: event loop + libuv thread pool, FD-table 1023/1024 — на грани EMFILE). Каждый процесс имеет собственную FD-table — нумерация дескрипторов локальна процессу; fd=7 у A и fd=7 у B указывают на разные объекты.
• Kernel (ring 0) — единое адресное пространство, через которое проходят все запросы: syscall handler (точка входа), VFS (read/write/open), TCP/IP stack, CFS scheduler, MM (page tables), epoll, io_uring, signals, OOM killer.
• Hardware — CPU с кэшами и TLB, RAM (page frames), NIC, NVMe SSD. Всё взаимодействие с железом идёт через kernel (за редким исключением user-space drivers типа DPDK/SPDK).
• IPC primitives — четыре способа межпроцессного общения: pipe (stream-байты), POSIX mq (с приоритетами), Unix socket (двусторонний поток или дейтаграммы), shared memory (zero-copy, самый быстрый, требует синхронизации сверху).

Узлы FD-table подсвечены как capacity — они моделируют реальный лимит соединений. У process C он намеренно занижен (1023/1024) чтобы сценарий 3 показал EMFILE-каскад.

Сценарии

1. syscall-flow — анатомия одного read(). Прикладной код вызывает read(fd, buf, 4096). libc исполняет инструкцию syscall — CPU переключается с ring 3 на ring 0, регистры сохраняются в kernel stack (это и есть ~100 нс «overhead» каждого syscall'а). Kernel ищет struct file по fd, вызывает f_op->read, идёт в page cache. Page miss — block I/O в NVMe — ~100 μs ожидания (в 100 000 раз медленнее L1). DMA копирует данные в kernel buffer, IRQ будит ожидающий поток, copy_to_user переносит байты в user buffer (TLB walk + memcpy). sysret возвращает управление в userspace. Итог: 1M мелких read'ов с буфером 1 байт = 100 мс одного только overhead'а — отсюда правило батчинга (readv, writev, sendfile, splice).

2. threads-shm-ipc — потоки и shared memory. CFS scheduler выбирает следующий поток по минимальному vruntime в красно-чёрном дереве; квант обычно 4 мс. Поток T1 пишет в shared ring buffer (MAP_SHARED mmap), обозначает готовность через futex_wake. Process B — отдельный процесс! — видит те же физические страницы через свой mmap. Это zero-copy: нет копирования через kernel, только синхронизация через futex (кстати, futex дёшев когда нет contention — uncontended fast-path вообще не идёт в kernel). Control plane идёт через медленный pipe (ack-сообщения), data plane — через shm. Bonus-демонстрация: SIGSEGV ловит висячий указатель в shared heap — coredump, и оба потока процесса B умирают вместе (нет crash isolation внутри процесса).

3. epoll-c10k-fdleak — C10K и FD-leak до EMFILE. Один поток Node.js обслуживает 10K соединений: каждый новый сокет регистрируется в epoll через epoll_ctl(EPOLL_CTL_ADD) (O(log N), RB-tree); epoll_wait возвращает только готовые дескрипторы (O(1), отдельный двусвязный список) — это и есть решение C10K (Kegel, 1999): старый select() требовал бы 10K итераций массива на каждый poll. CPU-тяжёлые задачи (crypto, compress) offload'ятся в libuv thread pool (4 worker'а). Затем — error path забыл close(): FD-table растёт 500 → 800 → 1023, accept() падает с EMFILE, каскад: open(log) тоже не работает (нет fd!), debugging blind, OOM killer выбирает жирный процесс и SIGKILL'ит без shutdown hooks. Фикс: ulimit -n 1048576, try/finally close, lsof мониторинг fd-count, miграция на io_uring.

4. io-uring-async — следующее поколение I/O. Userspace mmap'ит две очереди (SQ — submission, CQ — completion) в shared memory с kernel. Прикладной код пишет SQE напрямую в ring (без syscall!), один io_uring_enter подаёт batch операций. Kernel worker thread исполняет их асинхронно, completion event пишет в CQ ring. В режиме IORING_SETUP_SQPOLL kernel-поток спинит SQ — ноль syscalls на data path (ScyllaDB pattern). Результат: 10M ops/sec на одно ядро vs ~1M у epoll vs ~10K у blocking. Caveat в скрипте показан честно: io_uring имел chain'ы CVE в 2023, отключён в дефолтных профилях Google/CrowdStrike — trade-off security vs perf.

Trade-offs (ADR на узле fdtable-c)

ADR-001: Threads vs Processes vs Async (полный текст — кликни на узел FD table - 1023/1024 процесса C). Краткая выжимка:

• Process per request (Apache prefork, Postgres) — полная crash isolation, отдельный VM space, но context switch 1–10 μs и ~2–10 MB RSS на процесс до полезной работы. Потолок ~1–5K на сервер.
• Thread per request (Tomcat, старый Jetty) — shared memory дёшево, switch ~1 μs, но GIL в Python/Ruby убивает CPU-bound, thread leak/race conditions мучительно отлаживать. Потолок ~10K (8 MB stack × 10K = 80 GB).
• Async + event loop (Nginx, Node, Go) — десятки тысяч соединений на 1 поток через epoll/kqueue, switch ~0.1 μs без kernel involvement. Один blocking call вешает всё — CPU-bound оффлоадить в worker pool.

Решение по задаче: CPU-bound + изоляция (DB engine, browser tab, Lambda) → процессы + cgroups. Mixed I/O + CPU + shared state (Java app server) → thread pool с bounded concurrency (Tomcat maxThreads). Network I/O dominated (HTTP server, proxy, gateway, chat) → async event loop + io_uring/epoll. Не выбирай «потоки» по умолчанию: Python потоки бесполезны для CPU из-за GIL (используй multiprocessing); Java виртуальные потоки (Project Loom, JDK 21+) дают async-производительность с blocking-стилем кода. Никогда не fork() в горячем цикле — exec + page table copy дорог, используй pre-fork worker pool (Gunicorn, Unicorn).

Реальные системы

• Nginx — master process + N worker processes, каждый worker = single-threaded event loop + epoll. Один сервер легко тянет 10K–100K concurrent connections.
• Node.js — libuv event loop + epoll/kqueue + 4-thread default pool для filesystem и DNS (которые в kernel не неблокируемые). Один процесс — ставь cluster для multi-core.
• Go runtime — M
  scheduler: миллионы goroutine'ов на десятках OS-потоков. Net poller — epoll-based, прозрачен для прикладного кода (синхронный API, async внутри). Goroutine начинается с 8 KB stack, растёт автоматически.
• Postgres — process-per-connection (heavy: ~10 MB RSS на connection), поэтому в production обязателен pgBouncer pool. Использует mmap для shared buffers (8 KB pages), fork() для bgworker'ов и checkpointer'ов.
• Redis — single-threaded event loop + epoll, fork() для RDB snapshot (Copy-on-Write — отсюда «двойная память» во время BGSAVE).
• ScyllaDB / Seastar — shard-per-core, ZERO shared state, io_uring + DPDK, kernel bypass там где можно. Самый агрессивный pattern.

Anti-patterns

• «Просто добавь потоков» — для Python CPU-bound бесполезно (GIL сериализует bytecode). Используй multiprocessing или JIT.
• fork() в горячем цикле — каждый exec копирует page tables и FD-table. Pre-fork worker pool — норма (Gunicorn, Apache prefork).
• Игнорировать ulimit -n — дефолтный soft limit 1024 в production = бомба замедленного действия. Ставь 1M в LimitNOFILE= (systemd) или /etc/security/limits.conf.
• Spawning миллион goroutine'ов без bounds — даже по 8 KB начального стека это 8 GB, плюс scheduler overhead. Используй semaphore / errgroup с лимитом.
• O_NONBLOCK + spin loop — это antipattern из 1990-х, эпохи до select. Сжигает CPU без полезной работы. Используй epoll / kqueue / io_uring.
• Логирование внутри signal handler — большинство функций async-signal-unsafe (включая printf, malloc). Safe set очень мал: write, _exit, signal, атомарные read/write. Используй self-pipe trick или signalfd.
• Long-running thread на priority -20 — может вытеснить kernel-критичные таски (kworker, ksoftirqd) и привести к kernel stalls.

Когда НЕ использовать

«OS-thinking» — это не «всё пишем на C с epoll». Большинство приложений работают на uvicorn / Gunicorn / Tomcat / Rails Puma и им хватает. Думать про OS нужно когда:

• Видишь >5% CPU в sys% (top/htop) — syscall overhead становится значимым.
• Connection-bound сервис: HTTP proxy, chat, real-time, websocket-fanout.
• Latency P99 непредсказуем — часто это GC + page faults + scheduler jitter в комбо.
• Профайл показывает futex_wait / epoll_wait / read в top-3 функциях.

В CRUD-сервисе с 50 RPS все эти оптимизации — over-engineering. Сначала измерь, потом оптимизируй.

Дальше читать

• [CONCEPT]memory-hierarchy — почему page fault стоит 100 μs, а L1 cache hit 1 нс
• [CONCEPT]virtualization — как cgroups + namespaces складываются в Docker
• [CONCEPT]containers — следующий уровень изоляции поверх OS primitives
• [CONCEPT]tcp-handshake — что именно делает kernel когда ты пишешь accept()
• [CASE]chat-system-design — выбор concurrency model для real-time
• [CASE]web-crawler — async I/O для десятков тысяч HTTP запросов
• Brendan Gregg, Systems Performance — главы 3 (OS), 6 (CPU), 7 (Memory), 9 (Disk)
• Tanenbaum, Modern Operating Systems — фундамент
• Dan Kegel, The C10K Problem (1999) — http://www.kegel.com/c10k.html — историческая статья, после которой появился epoll
• Robert Love, Linux Kernel Development — что внутри kernel когда ты делаешь read()