Как быстро найти, кто грузит CPU: команды mpstat и pidstat

1️⃣Посмотреть загрузку всех ядер

mpstat -P ALL 1 5

• -P ALL — все ядра
• 1 5 — обновлять каждые 1 секунду, всего 5 раз

Что смотрим?
%usr — % загрузка CPU пользовательскими процессами
%sys — % загрузка системными процессами (ядро)
%idle — % простоя (чем больше, тем лучше!)

Если %idle близок к 0 — CPU сильно загружен.

2️⃣ Найти самые «жирные» процессы по CPU

pidstat 1 5

Вывод покажет процессы и их %CPU каждую секунду.

3️⃣Быстрая сортировка процессов по загрузке CPU

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -10

Показывает 10 самых «тяжелых» по CPU процессов.

4️⃣Если нужно — снизить приоритет процесса

renice +10 <PID>

Чем выше число, тем ниже приоритет.

И мониторинг в реальном времени

top -o %CPU

top отсортирует процессы по CPU. Чтобы выйти — нажмите q.

Вышел Podman 5.5.0

Это инструмент для управления контейнерами, образами и томами на Linux, macOS и Windows (через Podman VM). Код написан на Go и Shell, лицензия Apache 2.0.

Релизы выходят четыре раза в год. В версии 5.5.0 исправлены баги и добавлены новые команды:
⏺podman machine cp — копирование файлов в Podman VM
⏺podman artifact extract — копирование содержимого OCI-артефактов на диск
⏺опция ‑mount=artifact для монтирования OCI-артефактов в контейнеры

Требуется минимум Go 1.23 для сборки. Обновлены ключевые модули: Buildah 1.40.0, containers/common 0.63.0 и другие.

Быстрая диагностика и устранение проблем с BIND (named)

BIND — один из самых распространённых DNS-серверов в Linux-средах. Он отвечает за трансляцию имён в IP и обратно, поддерживает зону прямого и обратного разрешения, DNSSEC и многое другое.

1️⃣Проверяем статус сервиса

systemctl status named

Если сервис не запущен — запустите его:

systemctl start named

Если он падает — смотрим логи.

2️⃣Логи BIND — первое место для поиска проблем

В зависимости от дистрибутива логи могут быть в /var/log/messages, /var/log/syslog или /var/log/named/named.log.

Чтобы быстро смотреть последние ошибки:

journalctl -u named -f

или

tail -f /var/log/named/named.log

Обращайте внимание на ошибки синтаксиса, проблемы с зонами, отказ в доступе.

3️⃣Проверка конфигурации BIND

Перед перезапуском всегда проверяйте конфигурацию:

named-checkconf

Если команда не выводит ошибок — конфиг валидный.

4️⃣Проверка файлов зон

Ошибки в зонах — частая причина проблем.

Проверяем файл зоны (например, zonefile.db):

named-checkzone example.com /etc/bind/zones/example.com.db

Если есть ошибки — будут показаны с подробностями.

5️⃣Тестируем DNS-запросы локально

dig @localhost example.com

Если ответ корректный — BIND работает локально.

6️⃣Проверяем права и доступ к файлам

BIND должен иметь права читать зоны и конфиги:

ls -l /etc/bind/zones/

Если проблемы с правами — исправьте:

chown -R bind:bind /etc/bind/zones/
chmod 640 /etc/bind/zones/*.db

7️⃣Перезапуск BIND с выводом ошибок

systemctl restart named
journalctl -xe -u named

Если сервис упал — посмотрите последние ошибки в журнале.

8️⃣Обновление записей зоны без перезапуска — динамическое обновление

Если настроено, используйте:

rndc reload example.com

Команда перезагрузит конкретную зону без остановки сервиса.

9️⃣Диагностика проблем с сетевым доступом к BIND

Проверяем, слушает ли BIND на нужных интерфейсах:

ss -tulnp | grep named

Проверяем firewall:

iptables -L -n | grep 53

Убедитесь, что порт 53 открыт для TCP и UDP.

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое NUMA (Non-Uniform Memory Access) и как это влияет на производительность серверов?

✅Ответ: NUMA — это архитектура компьютерных систем, где процессоры имеют собственный локальный доступ к памяти, а доступ к удалённой памяти других процессоров происходит с задержками.

В системах с NUMA важно оптимизировать размещение процессов и потоков, чтобы они максимально использовали локальную память, снижая задержки и увеличивая производительность. Для этого применяются настройки CPU и памяти, а также специальные инструменты, например numactl, позволяющие управлять привязкой процессов к узлам NUMA.

Когда dig не помогает: отладка DNS на уровне сети

Пользователь жалуется, что “ничего не открывается”, а dig возвращает нормальные ответы. BIND работает, зона валидна. Что тогда?

1️⃣Проверяем, действительно ли DNS отрабатывает

dig @127.0.0.1 example.com

Проверяем, вернулся ли полный ответ с нужным A или CNAME. Обратите внимание на поля:
• ANSWER SECTION: есть ли IP?
• AUTHORITY SECTION: может быть ответом, если рекурсивный запрос не разрешился.

2️⃣Проверяем клиентский резолвинг

cat /etc/resolv.conf

Возможно, система вообще не использует ваш DNS.

3️⃣Используем strace для захвата DNS-запросов

strace -e trace=network curl https://example.com

Это покажет, делает ли вообще клиент DNS-запрос и куда.

4️⃣Тестируем с tcpdump

tcpdump -i any port 53 -n

• Видно ли, что запрос приходит к BIND?
• Есть ли ответ?
• Уходит ли запрос наружу, если ваш сервер — рекурсор?

5️⃣Проверяем рекурсивность

Если вы администрируете DNS-сервер, но запросы снаружи не работают — возможно, вы не разрешили рекурсию:

options {
  recursion yes;
  allow-recursion { trusted-nets; };
};

Проверьте named.conf и ACL.

6️⃣Проверяем MTU и DNS over UDP

Если ответы DNS большие (например, с DNSSEC), они могут не помещаться в UDP. В таком случае клиент должен повторно делать запрос по TCP.

Проверяем:

dig +tcp example.com

Если работает только с +tcp, а без него — нет, возможны проблемы с фаерволом или MTU.

7️⃣Проверяем, что система действительно использует DNS

Некоторые системы с systemd используют systemd-resolved. Проверяем:

resolvectl status

Или:

systemd-resolve --status

Если ответы кэшируются или не доходят — лучше отключить systemd-resolved и использовать классический resolv.conf.

Почему systemd-таймер срабатывает не тогда, когда вы ждёте?

Настроили systemd-таймер, всё вроде по документации. Но скрипт не запускается, или запускается не в то время? Это не баг — это AccuracySec.

1️⃣Что такое AccuracySec и зачем он нужен?

По умолчанию systemd не гарантирует миллисекундную точность.

Чтобы сэкономить ресурсы, он может откладывать таймер до ближайшего «удобного» момента. Именно это делает AccuracySec.

Пример:

[Timer]
OnCalendar=*-*-* 03:00:00
AccuracySec=1s

Если не задать AccuracySec, systemd может спокойно сдвинуть запуск на несколько минут вперёд — и вы будете гадать, почему бэкап не стартует ровно в 03:00.

2️⃣ Как проверить, что ваш таймер вообще живой?

systemctl list-timers

Покажет ближайшее время запуска и прошедшие срабатывания. Если не видите свой таймер — возможно, вы забыли Enable=true.

3️⃣Почему OnBootSec не сработал после перезагрузки?

Это типовая ошибка: вы включили таймер, но не активировали сам юнит.
Проверьте:

systemctl status your-timer.timer

А ещё — не забывайте, что OnBootSec=5min означает запуск спустя 5 минут после загрузки, а не сразу.

4️⃣ Хотите запуск точно по расписанию?

Сделайте AccuracySec=1s, и systemd не будет «оптимизировать» время:

[Timer]
OnCalendar=*-*-* 05:00:00
AccuracySec=1s
Persistent=true

Persistent=true важен, если хотите, чтобы задача выполнилась после выключения — она «догонит» при следующем старте

Вышел AlmaLinux 9.6 — синхронизирован с RHEL 9.6

20 мая 2025 года вышел стабильный релиз AlmaLinux 9.6. Дистрибутив основан на ядре Linux 5.14 и полностью бинарно совместим с Red Hat Enterprise Linux 9.6.

Доступны сборки для x86_64, ARM64, ppc64le и s390x.

Проект поддерживается некоммерческой AlmaLinux OS Foundation, распространяется бесплатно и развивается открытым сообществом.

Обновления и особенности:
⏺Улучшенная производительность и безопасность
⏺Удалены RHEL-специфичные пакеты (insights-client, subscription-manager и др.)
⏺Расширена поддержка оборудования (LSI, Adaptec, Dell, QLogic и др.)
⏺Репозиторий Synergy — дополнительное ПО (Pantheon, Warpinator и др.)

zombie процессы

Иногда вы запускаете top или ps aux, и вдруг замечаете статус Z. Это зомби-процесс. Он уже умер, но остался в таблице процессов, потому что его родитель не вызвал wait().

Такое бывает из-за багов, утечек, криво написанных демонов или скриптов.

Диагностика

Показать все зомби в системе:

ps -eo pid,ppid,state,cmd | grep ' Z '

Пример вывода:

1234  567   Z    [my-dead-child]

1234 — это PID зомби.
567 — это PPID — родитель, который должен был вызвать wait().

Посмотреть, кто этот родитель:

ps -p 567 -o pid,comm

Если родитель всё ещё жив, но “не собирает” зомби — это потенциальная проблема.

Что делать?

⏺Если это ваш сервис/скрипт — проверьте, обрабатываете ли вы SIGCHLD и вызываете ли wait() в родителе. В bash это можно сделать так:

while true; do
  ./child &
  wait $!
done

⏺Перезапустите родительский процесс, чтобы он корректно завершил своих детей:

systemctl restart <service>

⏺Если родитель — PID 1 (init/systemd) — зомби обычно исчезают автоматически, как только systemd обрабатывает SIGCHLD.

Создаём зомби для отладки

Если хотите поэкспериментировать:

// zombie.c
#include <stdlib.h>
#include <unistd.h>

int main() {
    if (fork() > 0) {
        sleep(60); // родитель спит, не вызывает wait
    } else {
        exit(0); // ребёнок умирает
    }
}

Компилируем и запускаем:

gcc zombie.c -o zombie
./zombie
ps aux | grep Z

Чем больше у вас данных, тем страшнее их потерять 👀

29 мая в 11:00 облачный провайдер Cloud․ru расскажет, как защитить бизнес от потери данных с помощью облачных технологий.

Что будет на вебинаре:
🤖 Непрерывность данных — почему без бэкапов бизнес в зоне риска.
🤖 Резервное копирование и аварийное восстановление — когда и зачем нужно.
🤖 Облако для защиты данных — как и зачем использовать.
🤖 Дополнительные методы защиты — что еще важно учитывать.

Будет live-демо — эксперт покажет настройку резервного копирования и восстановления в прямом эфире.

Зарегистрироваться на вебинар🖱

Правильное отношение к сервакам🥰

“Too many open files”: куда утекают дескрипторы

Сервисы начинают сыпать ошибками:

EMFILE: Too many open files

Но ulimit -n вроде нормальный. Что происходит?

⏺Причина:

Открытые файлы — это не только обычные файлы, но и сокеты, пайпы, устройства.

У каждого процесса есть лимит на количество открытых дескрипторов (nofile). При его превышении начинаются ошибки.

Проверка лимитов

ulimit -n                # лимит текущей сессии
cat /proc/$$/limits      # все лимиты текущего процесса

⏺Поиск виновника
Показываем процессы с наибольшим числом открытых файлов:

for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  count=$(ls /proc/$pid/fd 2>/dev/null | wc -l)
  echo "$count $pid"
done | sort -nr | head

Смотрим, что именно открыто у подозреваемого:

ls -l /proc/<PID>/fd

⏺Что делать?

Если утекают дескрипторы — проверьте код, особенно вызовы open() и close().

Если активно растёт число сетевых соединений — проверьте, не остаются ли открытые сокеты:

netstat -anp | grep <PID>

Как увеличить лимит

# Временно
ulimit -n 65535

# Постоянно — /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

Для systemd-сервисов:

[Service]
LimitNOFILE=65535

Когда sshd пускает всех: настройка ограничения доступа по IP и ключам

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

Как быстро проверить и настроить безопасный доступ?

1️⃣Проверяем текущие подключения и логи SSH

ss -tnpa | grep sshd
journalctl -u sshd -e

Смотрим, кто подключается и есть ли ошибки аутентификации.

2️⃣Ограничиваем доступ по IP в sshd_config

Добавьте в /etc/ssh/sshd_config:

AllowUsers [email protected].*
DenyUsers user2@*

Или используйте AllowGroups с похожим синтаксисом.

3️⃣ Разрешаем доступ только по ключам, отключаем пароль

PasswordAuthentication no
PubkeyAuthentication yes

4️⃣ Проверяем разрешённые ключи в ~/.ssh/authorized_keys

Убедитесь, что ключи корректные и права на папку и файл строго выставлены:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

5️⃣ Перезапускаем sshd

systemctl restart sshd

6️⃣ Тестируем подключение с нужных IP и с ключами

Если не работает — запускайте ssh с повышенной детализацией:

ssh -vvv user@server

7️⃣ При подозрениях — включаем дополнительный лог в sshd_config:

LogLevel VERBOSE

Это поможет понять, почему соединение не проходит.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает oom-killer в Linux и как с ним работать, чтобы минимизировать негативные последствия?

✅Ответ: oom-killer (Out-Of-Memory Killer) — это механизм ядра Linux, который срабатывает, когда системе не хватает оперативной памяти, и она не может выделить память ни одному из процессов. В такой ситуации oom-killer выбирает и завершает “наименее ценную” с точки зрения ядра задачу, чтобы освободить ресурсы.

Как с ним работать:

— Поведение можно контролировать с помощью параметра oom_score_adj. Чем выше значение (макс. 1000), тем выше вероятность, что процесс будет убит.
— Можно настроить cgroups и ограничить память для отдельных групп процессов, чтобы сбои не затрагивали всю систему.
— Желательно использовать swap-файл/раздел, чтобы отложить момент срабатывания OOM, но не полагаться на это как на основную защиту.

Релиз Rust Coreutils 0.1.0

24 мая 2025 вышла версия 0.1.0 проекта Rust Coreutils (uutils) — кроссплатформенной альтернативы GNU Coreutils, написанной на Rust.

В набор входят популярные утилиты: ls, cp, cat, chmod, date и другие.

Цель — создать производительную и безопасную замену Coreutils, которая будет работать на Linux, Windows, Redox и Fuchsia. 

Rust Coreutils уже будет использоваться по умолчанию в Ubuntu 25.10.

Основные улучшения версии 0.1.0:
⏺Поддержка SELinux в ключевых утилитах (cp, ls, mkdir, stat и др.).
⏺Оптимизации производительности: uutils в ряде случаев быстрее GNU.
⏺Улучшена совместимость с тестами GNU Coreutils (522 успешных теста).
⏺Расширены функции и добавлены опции во многие утилиты.

Проект распространяется под MIT-лицензией — более либеральной, чем GPL у GNU Coreutils.

Bonding интерфейсов в Linux: простая настройка для отказоустойчивости и скорости

Bonding - это объединение нескольких физических сетевых интерфейсов в один логический, чтобы увеличить пропускную способность или обеспечить резервирование.

Зачем нужно?

• Если один кабель или интерфейс упадёт, сеть не потеряется.
• Можно повысить скорость, суммируя каналы.

Как проверить, поддерживается ли bonding?

modprobe bonding
lsmod | grep bonding

Простой пример конфигурации (mode=1 — active-backup):

⏺Создаём файл /etc/sysconfig/network-scripts/ifcfg-bond0 (для RHEL/CentOS):

DEVICE=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"

⏺Настраиваем интерфейсы, которые в bonding, например /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes

Аналогично для eth1.

⏺Перезапускаем сеть:

ifdown eth0 eth1
ifup bond0

Что важно знать:

1️⃣Режим bonding влияет на логику работы: active-backup — резервирование, balance-rr — агрегация с балансировкой нагрузки, другие — для продвинутых сценариев.

2️⃣На коммутаторе тоже нужно настроить LACP или соответствующий режим.