Память

У процесса своё виртуальное адресное пространство, своя таблица файловых дескрипторов, свой cwd, свои uid/gid и свои обработчики сигналов. Потоки одного процесса делят абсолютно всё это: код, кучу, глобальные переменные, дескрипторы. Потоку принадлежат только стек (обычно 8 МиБ виртуально, по ulimit -s), регистры, TLS, маска сигналов, приоритет и привязка к ядрам. Отсюда и разница в модели программирования: два процесса нужно связывать через IPC, а два потока уже видят одну память, и потому им нужны мьютексы.

В Linux и то и другое живёт как одна структура task_struct, созданная clone() с разными флагами. С CLONE_VM|CLONE_FILES|CLONE_FS|CLONE_SIGHAND|CLONE_THREAD получается поток (тот же PID), без них процесс. Планировщик их не различает.

Переключение контекста

Прямая стоимость переключения сводится к сохранению и восстановлению регистров и работе планировщика, это десятые доли микросекунды. Но главная цена косвенная. При переключении между процессами меняется таблица страниц (CR3), TLB и кэши L1/L2 остывают (без PCID/ASID TLB сбрасывается целиком), и следующие сотни обращений к памяти будут медленными. Между потоками одного процесса таблица страниц та же, поэтому TLB выживает и переключение дешевле. Плюс само создание: fork() стоит от десятков микросекунд до миллисекунд (растёт с памятью процесса), clone() потока единицы микросекунд.

Где здесь горутина

Горутина живёт в куче процесса Go как структура runtime.g. Планировщик Go работает по схеме G–M–P: G это горутина, M поток ОС, P логический процессор (их GOMAXPROCS, по умолчанию по числу доступных ядер). Рантайм мультиплексирует тысячи G на десяток M. Переключить горутину значит сменить несколько регистров и перейти на другой стек: без входа в ядро, 50–200 нс. Стек начинается с 2 КиБ (с Go 1.19 рантайм может сразу дать больше, по среднему размеру стеков на прошлой сборке мусора) и растёт копированием, а не резервируется на 8 МиБ. Поэтому миллион горутин живёт спокойно, а миллион потоков нет: только под стеки ушло бы 8 ТиБ виртуальной памяти, и планировщик ядра захлебнулся бы.

Сегменты

Снизу вверх: .text (код, r-x), .rodata (константы, r--), .data (инициализированные глобалы), .bss (глобальные нули, в файле места не занимают), куча (растёт вверх), область mmap (библиотеки, файлы, крупные аллокации, арены Go), стек (растёт вниз от верхней границы пользовательской части). Живьём это видно через cat /proc/PID/maps.

Виртуальная память

Адрес, которым оперирует программа, - виртуальный. Перевод в физический делает MMU по четырёхуровневой таблице страниц; результаты кэшируются в TLB. Единица - страница 4 КиБ. Это даёт три вещи: изоляцию (чужие страницы просто не отображены), возможность дать процессу больше памяти, чем есть физически, и разделение общих страниц (один .text libc на все процессы).

Как ОС управляет

• Ленивое выделение. mmap только резервирует диапазон. Физическую страницу выдают при первом обращении, и это minor page fault (микросекунда).
• Major page fault ловим, когда нужной страницы в RAM нет: читаем с диска или из swap: десятки микросекунд на SSD, миллисекунды на HDD.
• Copy-on-write. При fork() копируются не данные, а таблицы страниц; все страницы становятся read-only, и физическое копирование происходит постранично при первой записи.
• Page cache. Вся свободная память уходит под кэш файлов и отдаётся мгновенно, когда нужна.
• Overcommit и OOM killer. Ядро обещает больше, чем имеет; когда память кончилась реально, выбирается жертва по oom_score и получает SIGKILL.

Как это устроено в ОС

Каждый вызов функции кладёт на стек кадр: адрес возврата, сохранённые регистры, локальные переменные и аргументы. Стек растёт вниз, к меньшим адресам. Снизу стоит guard page - страница без прав доступа. Когда рекурсия дотягивается до неё, MMU генерирует исключение, ядро превращает его в SIGSEGV, и процесс умирает с «segmentation fault». Размер стека потока фиксируется при создании (ulimit -s, обычно 8 МиБ) и не меняется, потому что стек должен быть непрерывным куском адресов, а расти ему некуда: соседние адреса уже могут быть заняты.

Как это в Go

Стек горутины «сегментированный» только исторически; с Go 1.3 он перемещаемый. Компилятор вставляет в пролог почти каждой функции проверку границы стека; при нехватке вызывается morestack: рантайм выделяет вдвое больший кусок, копирует старый стек и корректирует все указатели внутрь него. Возвращать указатель на локальную переменную в Go безопасно по другой причине: escape-анализ это видит и размещает её в куче. А указатели на стек внутри самой горутины при копировании переедут вместе со стеком.

func rec(n int) int { return rec(n + 1) }

func main() {
    defer func() { recover() }()   // не поможет
    rec(0)
}
// runtime: goroutine stack exceeds 1000000000-byte limit
// fatal error: stack overflow

Практические следствия

• Глубокая рекурсия в Go «стоит» кучу мелких morestack и копирований - обход глубокого дерева лучше переписать на явный стек-слайс.
• Крупные локальные массивы (var buf [64 << 10]byte) тоже вызывают рост стека и его копирование (больше 128 КиБ компилятор с Go 1.24 сам уносит в кучу); лучше make в кучу или sync.Pool.
• Предел меняется через debug.SetMaxStack, но если ты об этом задумался, скорее всего, у тебя бесконечная рекурсия.

Механика

На x86-64 программа кладёт номер вызова и аргументы в регистры и выполняет syscall. Процессор переключается из третьего кольца в нулевое, ядро проверяет аргументы, делает работу (возможно, блокируется), возвращает результат в регистре. Стоимость «пустого» вызова вроде getpid() порядка сотни наносекунд (замер на arm64 без KPTI, ядро 7.0: 120–180 нс); с митигацией Meltdown дороже, KPTI меняет таблицу страниц на каждом входе в ядро и выходе, а без PCID ещё и сбрасывает TLB. Плюс после возврата холодные кэши.

Часть вызовов ядро отдаёт бесплатно через vDSO: clock_gettime, gettimeofday. Поэтому time.Now() в Go стоит десятки наносекунд, а не микросекунду.

Как Go с этим живёт

Перед блокирующим вызовом рантайм делает entersyscall; если вызов затянулся (от 20 мкс, когда P ждёт работа, иначе до 10 мс), фоновый поток sysmon отбирает у застрявшего M его P и отдаёт другому потоку - планировщик не останавливается. Для сети всё ещё лучше: сокеты в Go всегда неблокирующие, ожиданием заведует netpoller поверх epoll, так что десять тысяч соединений обслуживаются несколькими потоками.

Инструменты

$ strace -f -p 1312               # -f обязателен: Go многопоточный
$ strace -c -f -p 1312            # сводка: топ вызовов по времени и количеству
$ strace -f -e trace=openat,close ./app   # ловим утечку дескрипторов
$ perf trace -p 1312              # дешевле strace
$ bpftrace -e 'tracepoint:syscalls:sys_enter_write { @[comm]=count(); }'

Что это

Дескриптор это маленькое целое, индекс в таблице процесса. За ним в ядре стоит struct file со смещением, флагами и счётчиком ссылок, а за ней уже inode, сокет, pipe, eventfd или epoll. 0/1/2 заняты под stdin/stdout/stderr. В Unix «всё есть файл», поэтому и TCP-соединение это fd, и epoll-инстанс тоже fd.

Диагностика

$ ulimit -n; ulimit -Hn              # мягкий и жёсткий лимиты
$ cat /proc/1312/limits | grep 'open files'
$ ls /proc/1312/fd | wc -l           # сколько занято сейчас
$ lsof -p 1312 | awk '{print $5}' | sort | uniq -c | sort -rn
$ ss -tanp | grep CLOSE-WAIT | wc -l # верный признак незакрытых тел ответов

Типовые причины в Go

• Не закрыт resp.Body. Даже если тело не нужно, закрывать обязательно, и лучше дочитать (io.Copy(io.Discard, resp.Body)), иначе соединение не вернётся в keep-alive-пул (с Go 1.27 закрытие само дочитывает до 256 КиБ).
• Не закрыт rows из database/sql при раннем return. Соединение не возвращается в пул, пул пустеет, приложение висит.
• Новый http.Transport (или http.Client со своим транспортом) на каждый запрос. У каждого транспорта свой пул, старые сокеты копятся; клиент без своего транспорта берёт общий, по умолчанию, и не течёт.
• defer f.Close() внутри цикла - закроется только в конце функции.
• Отсутствие таймаутов: подвисшие соединения держат fd, пока их не прибьёт TCP.
• Реально высокая нагрузка: 5000 одновременных соединений при жёстком лимите 4096 - лимит и правда надо поднять (мягкий Go поднимает почти до жёсткого сам).

Как поднять лимит

# systemd unit
[Service]
LimitNOFILE=65535

# docker
docker run --ulimit nofile=65535:65535 app

# /etc/security/limits.conf (для интерактивных сессий)
deploy soft nofile 65535
deploy hard nofile 65535

Кто что значит

• SIGTERM (15) значит «заверши работу». Шлют kill, docker stop, kubelet при удалении пода, systemd при systemctl stop. Перехватывается, и именно на нём строится graceful shutdown.
• SIGINT (2), он же Ctrl+C. Семантически то же самое; в Go обрабатывают вместе с SIGTERM.
• SIGKILL (9) убивает мгновенно, обработчик поставить нельзя. Шлют kill -9, OOM killer и kubelet после истечения grace period.
• SIGQUIT (3) приходит по Ctrl+\. В Go по умолчанию печатает стеки всех горутин и завершает процесс с кодом 2: бесплатный способ понять, где всё зависло (GOTRACEBACK=all для этого не нужен).
• SIGHUP (1) исторически означал «терминал закрыт», а по традиции демонов «перечитай конфиг». Стандарта нет, это соглашение.
• SIGSTOP/SIGCONT замораживают и размораживают; SIGSTOP тоже неперехватываемый.
• SIGPIPE (13) прилетает при записи в закрытый сокет. Go его игнорирует для всех дескрипторов, кроме stdout/stderr, и превращает в ошибку EPIPE.

Как правильно реагировать

ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop()
<-ctx.Done()
stop()                       // второй сигнал теперь убьёт немедленно, так и надо

shCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
defer cancel()
_ = srv.Shutdown(shCtx)      // перестать принимать новые, доиграть текущие
consumer.Close()             // потом входящие из брокера
pool.Close()                 // и только потом исходящие ресурсы

Порядок важен: сначала закрываем входящие источники работы, потом ждём активную работу, потом закрываем исходящие ресурсы, последними флашим трейсы и метрики. Общий бюджет должен быть меньше, чем terminationGracePeriodSeconds (в k8s по умолчанию 30 с), иначе получишь SIGKILL посреди работы.

$ pgrep -a myapp                  # найти: PID + командная строка
$ kill $(pgrep myapp)             # классика
$ pkill myapp                     # по имени процесса, но по подстроке: заденет и myapp-worker
$ pkill -f 'myapp --config=prod'  # -f: матчить всю командную строку
$ pkill -u deploy -f worker       # сузить по пользователю
$ killall myapp                   # точное имя; на Solaris killall убивает вообще всё
$ systemctl stop myapp            # правильный способ для systemd-юнита
$ kill -QUIT $(pgrep myapp)       # Go: дамп стеков всех горутин перед смертью
$ kill -9 $(pgrep myapp)          # последнее средство

Чем отличаются

• kill работает по PID и ничего не знает про имена.
• pkill матчит имя регуляркой; -f расширяет матч на всю командную строку. Опасен: pkill -f go убьёт больше, чем ты хотел, поэтому всегда сначала pgrep -af с тем же паттерном.
• killall требует точного совпадения имени процесса, без регулярок.
• systemctl stop убивает не процесс, а всю cgroup юнита - вместе с детьми, что важно, если приложение форкает воркеров.

jobs / fg / bg

Это управление задачами внутри одного шелла. ./app & запускает в фоне, jobs -l показывает список с номерами и PID, fg %1 возвращает задачу на передний план, bg %1 продолжает её в фоне. Ctrl+Z шлёт SIGTSTP (пауза), Ctrl+C - SIGINT, Ctrl+\ - SIGQUIT. Но фоновая задача остаётся ребёнком шелла, и при закрытии терминала получит SIGHUP. Чтобы выжила, есть nohup ./app &, disown -h %1 или setsid; а по-хорошему долгоживущее отправляют в systemd-юнит или в tmux/screen.

Логи

$ journalctl -u myapp -f                          # хвост
$ journalctl -u myapp --since '10 min ago' -p err # только ошибки (голый stderr журнал пишет как info)
$ journalctl -u myapp -b -1                       # прошлая загрузка
$ journalctl -k | grep -i oom                     # сообщения ядра
$ dmesg -T | grep -i -E 'oom|killed process'      # кто был убит OOM killer
$ tail -f /var/log/syslog                         # Ubuntu и Debian до 12; RHEL: /var/log/messages
$ docker logs -f --tail 100 --since 10m app
$ kubectl logs -f deploy/app --tail=100
$ kubectl logs pod/app-xyz --previous             # логи предыдущего, упавшего контейнера

Про контейнеры: у контейнера нет «файла лога». Приложение обязано писать в stdout/stderr, а runtime сам складывает это в файл на ноде (у Docker по умолчанию json-file, у kubelet свой текстовый формат CRI) и отдаёт по docker logs/kubectl logs. Писать логи в файл внутри контейнера - антипаттерн: их никто не соберёт, а диск ноды они забьют.

Кто слушает порт

$ ss -ltnp                       # l listening, t tcp, n numeric, p process
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      4096               *:8080            *:*    users:(("myapp",pid=1312,fd=4))
$ ss -ltnp 'sport = :8080'
$ ss -Htanp state established | wc -l  # сколько активных соединений (-H: без заголовка)
$ ss -s                          # сводка, в т.ч. сколько в TIME-WAIT
$ lsof -i :8080                  # альтернатива; медленнее, есть не везде
$ fuser -k 8080/tcp              # убить того, кто держит порт (шлёт SIGKILL, не SIGTERM)
$ netstat -tulpn                 # legacy, в slim-образах отсутствует

Что читать в top

• строка %Cpu(s): us (user), sy (kernel), wa (iowait), st (steal - время отбирает гипервизор, верный признак «шумного соседа» на облачной VM);
• RES это резидентная память (реальная), VIRT виртуальная (у Go всегда огромна, это норма), SHR разделяемая;
• состояние S: R выполняется, S спит, D ждёт ввода-вывода непрерываемо (диск!), Z зомби;
• top -H -p PID покажет потоки: видно, сколько их наплодил рантайм Go.

Load average

Три числа - экспоненциально сглаженные средние за 1, 5 и 15 минут. В Linux (в отличие от классического Unix) в счёт идут и runnable-задачи, и задачи в состоянии D. Поэтому LA растёт и от нехватки CPU, и от тормозящего диска или NFS.

• Нормировать на ядра: nproc = 8, LA 8.0 означает загрузку ровно на 100 %.
• LA 24 при 8 ядрах даёт очередь втрое длиннее, чем можно обслужить, и задержки растут.
• LA 40 при %us около нуля и высоком %wa упирается в диск или NFS, а не в CPU: все висят в D.
• Динамика: 1.2 8.4 15.9 значит, пик прошёл; 15.9 8.4 1.2 - растёт прямо сейчас.

Память и кэши

$ free -h
              total   used    free   shared  buff/cache  available
Mem:           31Gi   9.1Gi   412Mi    120Mi       21Gi        21Gi
#                             ^^^^^ пугает                    ^^^^ вот что важно

Незанятая память - потраченные впустую деньги, поэтому Linux заполняет её page cache. Кэш отдаётся мгновенно по первому требованию, и колонка free почти всегда маленькая, это нормально. Реальный показатель тут available: сколько можно занять, не уходя в swap. Тревожно, когда available близок к нулю или когда в vmstat 1 ненулевые si/so: начался свопинг, и задержки вырастут на порядки.

iowait

Формально %wa - idle-время процессора, в течение которого была хотя бы одна задача, заблокированная на вводе-выводе. Высокий iowait означает: «CPU свободен, упираемся в диск или сетевое хранилище вроде NFS». Метрика лукавая по двум причинам. Во-первых, если параллельно крутится счётная задача, iowait упадёт до нуля, хотя диск тормозит так же. Во-вторых, она усреднена по ядрам. Поэтому подтверждать надо через iostat -x 1 (r_await/w_await показывают задержку запроса, %util занятость устройства) и через число процессов в состоянии D в ps aux. В Go-сервисе высокий iowait обычно означает не «мой код медленный», а «диск под нами тормозит»; медленная удалённая БД iowait не даёт, горутины ждут её в netpoller.

Зомби

Когда процесс завершается, ядро освобождает его память и дескрипторы, но оставляет запись в таблице процессов с кодом возврата, вдруг родителю интересно. Родитель обязан вызвать wait()/waitpid() и «пожать» ребёнка. Пока он этого не сделал, ребёнок висит в состоянии Z (defunct). Зомби не занимает ни памяти, ни CPU, зато занимает PID, а PID конечны (/proc/sys/kernel/pid_max).

• kill -9 на зомби бесполезен: он уже мёртв.
• Чинить надо родителя: заставить его сделать wait() (например, прислав SIGCHLD) или убить, тогда зомби усыновит PID 1 и немедленно пожнёт.
• В Go: если ты запустил exec.Command и не вызвал cmd.Wait() (или использовал Start без Wait), получишь зомби. cmd.Run() делает Start+Wait сам.
• В контейнере твоё приложение работает как PID 1 и обязано жать осиротевшие процессы. Обычные приложения этого не умеют, поэтому есть docker run --init (tini) и shareProcessNamespace в k8s.

$ ps aux | awk '$8 ~ /^Z/ {print}'      # найти зомби
$ ps -o ppid= -p 4711                    # кто родитель, его и чинить
$ ps -eo state | grep -c D               # сколько застряло в непрерываемом ожидании

Namespaces - изоляция видимости

• pid даёт свою нумерацию: приложение становится PID 1 и не видит чужих процессов;
• у net свои интерфейсы, свои порты, свои правила iptables (поэтому два контейнера могут оба слушать 8080);
• mnt держит своё дерево монтирования (сюда подставляется ФС образа);
• uts отвечает за hostname, ipc за разделяемую память;
• user маппит uid: root внутри может быть непривилегированным снаружи;
• cgroup и time задают вид на иерархию cgroups и на часы.

Cgroups (v2) - ограничение ресурсов

• cpu.max задаёт квоту и период, например 200000 100000 = 2 ядра; превышение даёт троттлинг (задачу останавливают до конца периода);
• memory.max ставит жёсткий потолок, за которым OOM внутри группы; memory.high мягкий, включает агрессивный reclaim;
• pids.max, io.max, io.weight.

Контейнер собирается из этого плюс pivot_root на OverlayFS, урезанные capabilities (нет CAP_SYS_ADMIN и т. д.) и seccomp-профиль, запрещающий опасные системные вызовы. Именно поэтому контейнер стартует за доли секунды: это просто clone() с флагами, а не загрузка ОС.

systemd vs docker

systemd тоже управляет cgroups: каждый юнит живёт в своей группе, и через [Service] задаются MemoryMax=, CPUQuota=, LimitNOFILE=, политика перезапуска Restart=on-failure, а stdout уходит в journald. Он умеет и часть namespaces (PrivateTmp=, ProtectSystem=). Разница в другом: systemd обычно запускает бинарь в файловой системе этой машины, и зависимости ставишь на неё сам (запускать сервис из образа он тоже умеет, но так делают редко), а docker приносит с собой неизменяемый образ со всей ФС и полную сетевую изоляцию. Для одиночного Go-сервиса на выделенной VM systemd-юнит - вполне взрослый и более простой выбор; контейнеры выигрывают, когда нужны одинаковые артефакты между окружениями и оркестрация.

$ ssh-keygen -t ed25519 -C 'german@laptop'        # приватный с парольной фразой
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@1.2.3.4
$ chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys   # на сервере
$ ssh -i ~/.ssh/id_ed25519 deploy@1.2.3.4 'echo ok'
# /etc/ssh/sshd_config.d/00-hardening.conf: PasswordAuthentication no, PermitRootLogin no
$ sudo sshd -t && sudo systemctl reload ssh      # в RHEL юнит sshd

Что здесь важно проговорить

• ed25519, а не RSA: короче, быстрее, современная кривая. RSA берут, только если сервер древний, и тогда минимум 4096 бит.
• Права. При StrictModes yes sshd молча откажет, если домашний каталог, ~/.ssh или authorized_keys доступны на запись группе или всем (Debian и Ubuntu прощают запись группе, если в ней нет никого, кроме владельца). Поэтому и ставят 700 и 600 - с запасом. Это самая частая причина «ключ не работает». Смотри ssh -vvv на клиенте и journalctl -u ssh на сервере.
• Не закрывай текущую сессию, пока новым терминалом не проверил вход по ключу.
• sshd -t перед reload. Синтаксическая ошибка в конфиге при restart оставит тебя снаружи.
• Отдельный пользователь под деплой, root-логин выключен, sudo выдан по правилам.
• Ключ для CI держи отдельно, без парольной фразы, с ограничениями прямо в authorized_keys: command="/usr/local/bin/deploy",no-pty,no-port-forwarding.
• ~/.ssh/config с алиасами и ProxyJump bastion пригождается каждый день; ssh-agent избавляет от постоянного ввода фразы.