Команды для работы с ядром Linux: справочник с оговорками

Списки «N команд для работы с ядром» полезны как шпаргалка, но у них общая беда: команда есть, а контекста нет. Не сказано, что настройка исчезнет после перезагрузки, что утилита давно заброшена, а популярный совет «сбросить кэши для ускорения» вообще-то замедляет систему.

Ниже — команды, сгруппированные по задачам, и отдельным блоком то, на чём спотыкаются.

Поводом послужила подборка «50 команд управления ядром 7.0» с roadit.ru. Набор команд пересекается, разбор и оговорки — мои; пара утверждений оригинала по ходу поправлена.

Что за версия

Актуальное ядро — 7.0, вышло 12 апреля 2026. Смена мажорной версии здесь без глубокого смысла: Линус меняет первую цифру, когда вторая доходит примерно до двадцати, чтобы не считать до 6.30. Революции в номере искать не нужно.

Что за ядро запущено

uname -r                 # версия ядра
uname -m                 # архитектура: x86_64, aarch64
uname -a                 # всё сразу
cat /proc/version        # версия + компилятор и дата сборки
cat /proc/cmdline        # параметры, с которыми ядро загрузилось

/proc/cmdline недооценён. Когда система ведёт себя странно после чужой настройки, там обнаруживаются вещи вроде mitigations=off, intel_iommu=on или урезанной памяти — то, что не видно ни в одном конфиге.

Модули

lsmod                          # что загружено
lsmod | grep -i nvme           # отфильтровать
modinfo nvme                   # автор, параметры, зависимости
sudo modprobe nvme             # загрузить (с зависимостями)
sudo modprobe -r nvme          # выгрузить
sudo depmod -a                 # пересобрать карту зависимостей

modprobe против insmod — не вопрос вкуса. insmod принимает полный путь к .ko и грузит ровно один файл, не разбираясь в зависимостях: если модулю нужен другой модуль, вы получите отказ и невнятную ошибку. modprobe работает по имени и подтягивает зависимости сам. insmod/rmmod осмысленны при отладке свежесобранного модуля, во всех остальных случаях берите modprobe.

Чтобы модуль грузился при старте — файл в /etc/modules-load.d/, а параметры к нему — в /etc/modprobe.d/. Чтобы, наоборот, не грузился:

echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u     # для Debian/Ubuntu, иначе модуль подтянется из initramfs

Последняя строка — частая забытая деталь: без обновления initramfs чёрный список не сработает для модулей, которые грузятся на раннем этапе.

sysctl: параметры ядра

sysctl -a | less                          # все параметры
sysctl -a | grep -i swappiness            # найти нужный
sysctl vm.swappiness                      # прочитать
sudo sysctl -w vm.swappiness=10           # изменить до перезагрузки
sudo sysctl --system                      # применить всё из /etc/sysctl.d/

Главная оговорка: sysctl -w не переживает перезагрузку. Для постоянной настройки — отдельный файл в /etc/sysctl.d/:

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-tuning.conf
sudo sysctl --system

Именно /etc/sysctl.d/99-*.conf, а не правка /etc/sysctl.conf: свой файл не конфликтует с пакетным менеджером при обновлениях, а числовой префикс задаёт порядок применения.

Параметры, которые трогают чаще всего:

vm.swappiness=10 не универсальный рецепт. Для PostgreSQL и подобных — да, полезно: вытеснение страниц СУБД в swap бьёт по латентности. Но на узле с переподпиской памяти уменьшение swappiness приближает встречу с OOM killer. Ставьте осознанно, а не потому что «так пишут».

Производительность

perf top                              # что ест CPU прямо сейчас
perf record -a -g -- sleep 10         # снять профиль на 10 секунд
perf report                           # посмотреть снятое
perf sched stats                      # статистика планировщика

perf sched stats — действительно новое в 7.0: появились сценарии record/report/diff поверх счётчиков schedstat. Полезно, когда подозреваете, что проблема не в самом коде, а в том, как планировщик раскладывает задачи по ядрам.

Управление частотой и привязкой:

sudo cpupower frequency-info                        # текущий governor и частоты
sudo cpupower frequency-set -g performance          # зафиксировать производительность
taskset -c 0-3 ./myapp                              # запустить на ядрах 0-3
taskset -p 1234                                     # маска привязки процесса
nice -n 10 ./myapp                                  # запустить с низким приоритетом
renice -n 5 -p 1234                                 # поменять приоритет на лету

governor performance заметно поднимает энергопотребление и нагрев. На ноутбуке это ощутимо, на сервере под постоянной нагрузкой — обычно оправдано, потому что убирает разброс латентности при переходах частоты.

Диск:

ioping -c 10 /dev/sda                                    # латентность операций
fio --name=test --rw=randread --bs=4k --size=1G          # нагрузочный тест

С fio осторожнее: тест с --rw=randwrite на смонтированном устройстве уничтожит данные. Тестируйте на файле в файловой системе или на заведомо пустом устройстве.

Логи и отладка

dmesg | tail -20              # последние сообщения ядра
dmesg -T | grep -i error      # с человеческими временными метками
dmesg -w                      # следить в реальном времени
journalctl -k -f              # то же через systemd
journalctl -k -b -1           # сообщения ядра с прошлой загрузки

Два флага, которых обычно нет в подборках, но которые экономят время: dmesg -T переводит секунды с момента загрузки в нормальные даты, а journalctl -k -b -1 показывает лог предыдущей загрузки — единственный способ понять причину внезапной перезагрузки.

Системные вызовы:

strace -p 1234                      # трассировать работающий процесс
strace -e trace=file ./app          # только файловые вызовы
strace -c ./app                     # сводка: сколько времени в каких вызовах

strace замедляет процесс в разы, иногда на порядок. На продовом сервисе под нагрузкой это само по себе инцидент. Если нужно наблюдение с малыми накладными расходами — смотрите в сторону perf trace или eBPF-инструментов (bpftrace, набор bcc).

Трассировка функций ядра:

sudo mount -t debugfs none /sys/kernel/debug     # если ещё не смонтирована
echo function | sudo tee /sys/kernel/debug/tracing/current_tracer
sudo cat /sys/kernel/debug/tracing/trace
echo nop | sudo tee /sys/kernel/debug/tracing/current_tracer   # выключить

Последнюю строку не забывайте: включённый трассировщик функций постоянно жрёт CPU.

Быстрый осмотр состояния:

cat /proc/meminfo        # память в подробностях
cat /proc/interrupts     # распределение прерываний по ядрам
cat /proc/loadavg        # средняя нагрузка
ss -tuln                 # слушающие порты
ss -tp                   # сокеты с процессами

/proc/interrupts полезен неочевидным образом: если все прерывания сетевой карты сидят на одном ядре, вы упрётесь в это ядро задолго до исчерпания CPU в целом.

Память

free -h                  # сколько занято
vmstat 2 10              # динамика: 10 замеров по 2 секунды

В vmstat смотрите на колонки si/so — активный обмен со swap объясняет тормоза лучше любых графиков средней нагрузки. Про то, почему сама по себе высокая load average ещё ничего не значит, есть отдельный разбор.

Про сброс кэшей:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Это не оптимизация. Страничный кэш — не «утечка», а полезная работа: ядро держит в памяти то, что уже читали с диска. Сбросив его, вы гарантированно замедлите систему, пока кэш не наполнится заново. Команда имеет смысл ровно в одном сценарии — получить холодный старт перед замером производительности.

Безопасность

sysctl kernel.randomize_va_space       # ASLR: 2 — полный, 0 — выключен
sysctl net.ipv4.conf.all.rp_filter     # проверка обратного пути
sysctl kernel.dmesg_restrict           # 1 — dmesg только для root
capsh --print                          # capabilities текущего процесса
sudo auditctl -l                       # правила аудита

Уточнение по ASLR: у kernel.randomize_va_space три значения, и рабочее по умолчанию — 2 (рандомизация стека, кучи и mmap), а не 1. Единица означает частичную рандомизацию, ноль — выключено.

capsh --print стоит знать всем, кто работает с контейнерами: он показывает, какие привилегии реально есть у процесса. Разница между «root в контейнере» и «root на хосте» — это как раз набор capabilities.

Файловые системы

lsblk                            # дерево блочных устройств
blkid                            # UUID и типы ФС
df -h                            # занятое место
sudo xfs_scrub -v /mnt           # онлайн-проверка целостности XFS

Здесь поправка к первоисточнику: xfs_scrub не новинка 7.0 — онлайн-проверка XFS появилась много лет назад и с тех пор постепенно доводилась до ума. Инструмент хороший, но подавать его как фичу свежего ядра неверно.

Сборка и установка ядра

make menuconfig                  # конфигуратор
make -j$(nproc)                  # сборка на всех ядрах
sudo make modules_install
sudo make install

Параметры загрузки на RHEL-подобных:

sudo grubby --update-kernel=ALL --args="parameter=value"

Отдельно про hugeadm из подборок: утилита входит в libhugetlbfs, проект архивирован. Для huge pages сегодня используют sysctl (vm.nr_hugepages) и прозрачные huge pages через /sys/kernel/mm/transparent_hugepage/. Для баз данных, кстати, THP обычно рекомендуют отключать — PostgreSQL и Redis от него страдают.

Пять ловушек

Собранное вместе — то, из-за чего команды «не работают»:

1. sudo echo 3 > /proc/sys/vm/drop_caches не сработает. Перенаправление выполняет ваш шелл, а не sudo, и делает это без прав root. Нужен echo 3 | sudo tee ... или sudo sysctl -w.
2. sysctl -w живёт до перезагрузки. Постоянные настройки — только через /etc/sysctl.d/.
3. Чёрный список модулей без update-initramfs не действует для того, что грузится из initramfs.
4. strace — не инструмент для прода. Замедление в разы; для наблюдения под нагрузкой берите eBPF.
5. Сброс кэшей не ускоряет систему. Он её замедляет; применяется только перед бенчмарками.

Общее правило простое: прежде чем менять параметр ядра по совету из интернета, выясните, что он делает и что случится с вашей нагрузкой. Половина «оптимизаций» из подборок либо не нужна на современных дистрибутивах, либо вредна вне узкого сценария, для которого её когда-то придумали.