✍️ perf-tools — набор инструментов для анализа производительности!

Репозиторий от Brendan Gregg — одного из главных экспертов по performance и Linux-трейсингу. Здесь собраны готовые скрипты и утилиты для поиска узких мест по CPU, памяти, дискам и сети с использованием perf, ftrace, bcc и eBPF.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Параллелизм в shell

xargs -P позволяет выполнять команды параллельно, но есть нюансы, которые отличают рабочее решение от опасного.

Если в именах файлов есть пробелы или переводы строк — используйте нулевой разделитель:

find . -name "*.log" -print0 | xargs -0 -n1 -P4 gzip

-print0 и -0 гарантируют корректную обработку любых имён файлов.

Для команд вроде rm всегда добавляй защиту от пустого ввода:

find /tmp -type f -print0 | xargs -0 -r -n1 -P8 rm

Флаг -r не запустит команду, если вход пуст — это важный предохранитель.

Параллельные сетевые проверки можно делать так:

xargs -n1 -P5 ping -c1 -n < hosts.txt

-n отключает DNS-резолвинг и делает проверки стабильнее и быстрее.

🔥 xargs -P — это параллелизм по задачам, а не по потокам. Каждый файл или хост обрабатывается отдельным процессом.

🚪 Linux Ready | #совет

👍 Linux Kernel Documentation — официальная документация по ядру!

Здесь собраны материалы о том, как работает ядро Linux: управление памятью, планировщик задач, драйверы устройств, файловые системы и взаимодействие с железом. Документация показывает внутренние механизмы системы, а не только внешнее поведение.

📌 Оставляю ссылочку: docs.kernel.org

🚪 Linux Ready | #сайт

Как диагностировать рассинхронизацию времени!

Некорректное системное время приводит к сбоям TLS, аутентификации, логирования и распределённых систем. Ниже — компактный чек-лист диагностики.

Общее состояние времени:

timedatectl

Показывает текущее время, статус синхронизации и RTC.
RTC in local TZ = yes на серверах — плохая практика; рекомендуется UTC.

Кто управляет временем:

systemctl is-active systemd-timesyncd chronyd chrony ntp ntpd 2>/dev/null || true
systemctl status    systemd-timesyncd chronyd chrony ntp ntpd 2>/dev/null || true

Важно, чтобы реально корректировал время только один механизм.

Качество синхронизации:

timedatectl timesync-status
timedatectl show -p NTPSynchronized -p NTP
chronyc sources -v

timesync-status актуален только для systemd-timesyncd; для chrony используйте chronyc.

Резкие коррекции времени:

journalctl -u systemd-timesyncd -u chronyd -u ntp -u ntpd | \
grep -iE "step|jump|offset|slew|clock"

Помогает выявить скачки и принудительные корректировки.

RTC и перезагрузки:

hwclock --show

Большое расхождение между RTC и system clock проявляется после ребута, особенно если NTP не стартует сразу.

Виртуализация:

systemd-detect-virt
dmesg | grep -iE "kvm|hyper-v|vmware|xen|clock|timesync|ptp"

Guest-tools и гипервизор могут конфликтовать с NTP внутри гостя.

Базовая настройка:

timedatectl set-ntp true        # systemd-timesyncd
systemctl enable --now chronyd # chrony
timedatectl set-local-rtc 0    # RTC в UTC

🔥 Суть: проблемы времени почти всегда вызваны конфликтом источников синхронизации, неверной настройкой RTC или влиянием виртуализации.

🚪 Linux Ready | #практика

Нагружаем приложение и смотрим, как оно себя ведёт!

Сегодня прогоняем тестовое веб‑приложение через обычную нагрузку и простейшую «атаку», чтобы увидеть разницу по метрикам и логам. Всё через терминал и пару утилит: hey/ab для нагрузки и curl для имитации агрессивного клиента.

Сначала замерим «здоровое» состояние с равномерной нагрузкой:

hey -z 30s -c 20 http://localhost:8080/

За 30 секунд получим средний RPS, latency и процент ошибок. Это будет базовый уровень, с которым будем сравнивать.

Теперь устроим «атаку» с одного IP — резкий всплеск запросов:

hey -z 30s -c 200 http://localhost:8080/login

Следим в это время за приложением:

tail -f app.log
htop

В логах увидишь частые обращения к одному эндпоинту и рост 5xx/4xx, а по ресурсам — скачок CPU/памяти.

Можно вынести это в простой скрипт:

load_test() {
  hey -z 20s -c 30 "$1"
  hey -z 20s -c 200 "$1"
}
load_test "http://localhost:8080/login"

🔥 Так удобно быстро смотреть, где приложение начинает «сыпаться» под нагрузкой: код, база или сеть.

🚪 Linux Ready | #практика

FIFO в Linux: именованные пайпы для связи процессов без файлов!

Если нужно связать разные процессы, скрипты или shell’ы — используй FIFO (именованный канал).

Создаём канал:

mkfifo /tmp/myfifo

Чтение из канала (блокируется, пока нет данных):

cat /tmp/myfifo

Запись в канал — из другого процесса или терминала (может блокироваться, если нет читателя):

echo "hello world" > /tmp/myfifo

🔥 Данные передаются напрямую через ядро, без сохранения в файл на диске (буферизация — в памяти ядра).

🚪 Linux Ready | #совет

☕️ Kernel Newbies — сообщество и база знаний по Linux!

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

📌 Оставляю ссылочку: kernelnewbies.org

🚪 Linux Ready | #сайт

Низкоуровневый аудит процесса в Linux!

Когда top и htop уже не дают ответов, вся реальная картина состояния процесса находится в /proc.

Аргументы запуска процесса (argv):

cat /proc/PID/cmdline | tr '\0' ' '

Показывает текущие аргументы процесса. Полезно для диагностики, но argv может быть изменён самим процессом и не всегда отражает исходную команду запуска.

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

/usr/bin/python3 worker.py --queue=emails --env=prod

Память процесса:

cat /proc/PID/status | grep -E 'VmRSS|VmSize|VmSwap'

VmRSS — реально занятая RAM

VmSize — виртуальное адресное пространство процесса

VmSwap — объём, вытесненный в swap

Пример:

VmRSS:   412384 kB
VmSwap:   65536 kB

Детальная карта памяти процесса:

cat /proc/PID/smaps

Позволяет понять, где именно расходуется память: private, shared, file-backed. На больших процессах может быть тяжёлым.

Открытые файлы и сокеты процесса:

ls -l /proc/PID/fd

Здесь видны логи, сокеты, pipes и удалённые файлы, которые всё ещё удерживаются процессом (доступ зависит от прав).

Количество потоков внутри процесса:

ls /proc/PID/task | wc -l

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

Реальный исполняемый файл процесса:

readlink /proc/PID/exe

Права и capabilities процесса:

cat /proc/PID/status | grep Cap

🔥 Короткая практическая выжимка для анализа процессов на уровне procfs/ядра.

🚪 Linux Ready | #практика

Как гарантировать, что скрипт или команда не запустится дважды?

Часто cron запускается повторно, деплой стартует дважды, скрипт пересекается сам с собой.

PID-файлы — ненадёжны.
Проверки через ps — гонки.

В Linux есть решение — flock.
Запустить команду, только если она ещё не выполняется:

flock -n /tmp/deploy.lock deploy.sh

Если блокировка занят, flock завершится с ошибкой, команда не стартует.

Для скриптов ещё надёжнее:

exec 9>>/tmp/job.lock
flock -n 9 || exit 1

С этого момента гарантированно: только один экземпляр, блокировка снимается автоматически при exit.

🔥 flock — это advisory-блокировка ядра с атомарной установкой, а не договорённость скриптов. Используйте её для cron, деплоя, миграций, бэкапов и CI-шагов.

🚪 Linux Ready | #совет

Как быстро и безопасно работать с большими файлами в Linux!

Большие логи, дампы, CSV, JSON, бэкапы — с ними сталкиваются почти все. Неправильная работа с такими файлами часто приводит к зависаниям терминала, высокой нагрузке и потере времени.

Быстрый просмотр начала файла:

head -n 50 huge.log

Просмотр конца файла (самый частый кейс для логов):

tail -n 50 huge.log

Постраничный просмотр без загрузки файла в память:

less huge.log

Полезные режимы:

-F — выход, если файл помещается на экран
-S — без переноса строк
+F — режим tail -f (follow)

Поиск по огромному файлу с ограничением результатов:

grep -n -m 10 "ERROR" huge.log

Подсчёт количества строк:

wc -l huge.log

Читает файл последовательно и обычно быстрее любых текстовых редакторов.

Быстрое извлечение диапазона строк:

sed -n '100000,100200p' huge.log

Разделение большого файла на части:

split -l 500000 huge.log part_

Полезно для передачи, обработки или параллельного анализа.

Обработка с индикатором прогресса:

pv huge.log | grep "ERROR" > errors.log

pv показывает скорость и объём обработки (утилита может быть не установлена по умолчанию).

Безопасное массовое изменение содержимого:

sed 's/old_value/new_value/g' huge.log > huge.log.new && mv huge.log.new huge.log

Изменение через временный файл — надёжнее, чем sed -i, особенно для больших файлов.

🔥 Эти приёмы позволяют уверенно работать с файлами любого размера даже на слабых серверах и ноутбуках.

🚪 Linux Ready | #практика

🧐 На Хабре вышла интересная статья про автоматизацию tmux-окружения с помощью скриптов.

В этой статье:
• Научитесь запускать tmux-сессии в фоне и управлять ими из bash-скрипта;
• Автоматически поднимете несколько окон и панелей с нужными командами;
• Разберётесь с new-session, new-window, split-window и send-keys для сценариев «всё готово за один запуск»;
• Соберёте удобный шаблон, который можно адаптировать под разработку, мониторинг или отладку.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

Проверка активных DNS-серверов!

Определим, какие DNS-резолверы использует система, проверим их доступность и сравним задержку ответов при разрешении домена.

Показать текущие DNS-серверы в systemd-resolved (основной современный способ):

resolvectl status

Вывод показывает DNS-серверы по интерфейсам, текущий активный резолвер (Current DNS Server) и список upstream DNS (DNS Servers).

Посмотреть, что указано в resolv.conf:

grep -E "^nameserver" /etc/resolv.conf

Важно: в системах с systemd-resolved файл часто содержит локальный stub-адрес 127.0.0.53, поэтому не отражает настоящие upstream DNS.

Замерить задержку ответа конкретного DNS-сервера при резолве домена:

dig @1.1.1.1 example.com +stats | grep "Query time"
dig @8.8.8.8 example.com +stats | grep "Query time"

Формат результата:

;; Query time: XX msec

Задержка зависит от сети, маршрута и кэша. Для объективной оценки рекомендуется выполнять серию запросов и учитывать влияние кэширования, DNSSEC, VPN/Split-DNS и search-доменов.

Проверка базовой работоспособности резолвинга:

nslookup example.com

Если возвращается IP-адрес — в целом разрешение имён работает.

🔥 Понимание активных DNS-серверов — базовый шаг диагностики сети, особенно когда доступ по IP есть, но доменные имена не разрешаются.

🚪 Linux Ready | #практика