Admin Guides | Сисадмин
11.5K subscribers
1.27K photos
20 videos
34 files
563 links
Обучающий канал по ОС Linux & Windows для начинающих и действующих администраторов.

Админ, реклама: @Ak_Mihail
Биржа: https://telega.in/c/admguides

РКН: https://kurl.ru/nQejS
Download Telegram
TCP Tuning для высокой нагрузки

В больших сервисах стандартные сетевые настройки ядра Linux иногда становятся узким местом.

Например, при сотнях тысяч одновременных соединений сервер может «терять» пакеты SYN, а TCP-сессии застревать в TIME_WAIT. Чтобы этого избежать, настраивают несколько параметров через sysctl.

Основные параметры

1️⃣net.core.somaxconn
Определяет максимальное количество ожидающих соединений в очереди listen().

# посмотреть текущее значение
sysctl net.core.somaxconn
# увеличить до 65535
sudo sysctl -w net.core.somaxconn=65535


2️⃣ tcp_max_syn_backlog
Размер очереди незавершённых TCP-соединений (SYN). Важно при пиковых нагрузках.

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096


3️⃣ tcp_fin_timeout
Время удержания соединений в FIN_WAIT2, которое может «засорять» сервер.

sudo sysctl -w net.ipv4.tcp_fin_timeout=15


4️⃣ tcp_tw_reuse и tcp_tw_recycle (внимание: tcp_tw_recycle устарел и опасен для NAT)
Позволяет повторно использовать TIME_WAIT-сессии для новых соединений.

sudo sysctl -w net.ipv4.tcp_tw_reuse=1


Проверка эффекта

Посмотреть количество TIME_WAIT-соединений:

ss -s | grep timewait


Нагрузить сервер с помощью ab или wrk и сравнить, сколько соединений сервер держит без потерь.

Автоматизация

Чтобы настройки сохранялись после перезагрузки, добавьте их в /etc/sysctl.conf:

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1


и примените:

sudo sysctl -p
Please open Telegram to view this post
VIEW IN TELEGRAM
8👍8
💬 Вопрос на собеседовании для сисадмина

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


Вопрос: Что такое CPU isolcpus и как это влияет на производительность Linux-систем?

Ответ: Параметр isolcpus ядра Linux позволяет изолировать один или несколько процессоров от планировщика задач общего назначения. Это значит, что ядро не будет автоматически распределять на них обычные процессы, оставляя их “чистыми” для определённых критичных задач, например, для real-time приложений или высокопроизводительных сервисов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍84🔥3👎1
Secure Copy больших файлов: rsync vs scp

При работе с десятками гигабайт через SSH обычный scp начинает тормозить.

Почему?

Потому что он копирует файл целиком, без возможности возобновления, и каждый раз создаёт новое TCP-соединение.

Rsync через SSH решает это:
Передача только изменений (--partial и --inplace)
Можно включить сжатие (-z)
Поддерживает батчевую передачу и возобновление

Примеры:

Копирование одного большого файла с rsync:

rsync -avz --progress /local/largefile user@remote:/backup/


Если соединение обрывается, можно повторно выполнить команду — rsync продолжит с места прерывания.

Копирование каталога с контрольным мультиплексированием SSH:

Host remote
HostName 203.0.113.10
User admin
ControlMaster auto
ControlPath ~/.ssh/cm-%r@%h:%p
ControlPersist 10m


А затем:

rsync -avz /local/dir remote:/backup/dir


Все повторные подключения будут идти через уже открытое TCP-соединение, экономя время.

scp с мультиплексом и сжатием:

scp -o ControlMaster=auto -o ControlPath=~/.ssh/cm-%r@%h:%p -C /local/largefile remote:/backup/


Но для больших директорий rsync остаётся более гибким и надёжным, особенно если нужно резервное копирование или синхронизация.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍93
🥴23👍16😐7😁43
Sysctl для серверов с большим числом подключений

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

TIME_WAIT, переполнение очередей сокетов и медленный отклик — типичные признаки. Тут на помощь приходят параметры sysctl.

Основные настройки

net.ipv4.ip_local_port_range — диапазон локальных портов для исходящих соединений. Увеличение диапазона помогает избежать исчерпания портов при массовых подключениях.
net.ipv4.tcp_tw_reuse — разрешает повторное использование сокетов в состоянии TIME_WAIT для новых исходящих соединений.
net.ipv4.tcp_tw_recycle — ускоряет очистку TIME_WAIT (не рекомендуется для NAT).
net.core.netdev_max_backlog — размер очереди пакетов в драйвере сети. Увеличение помогает при пиках входящего трафика.

Измеряем эффект

До изменений:

ss -s | grep TIME-WAIT
cat /proc/sys/net/core/netdev_max_backlog


Применяем sysctl:

sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.core.netdev_max_backlog=5000


После изменений: повторяем измерения TPS (запросов в секунду) и TIME_WAIT.

Вывод: больше соединений проходит без ошибок, очередь пакетов меньше переполняется, нагрузка на сервер равномернее.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍73
Bcachefs теперь «внешне поддерживаемая»

28 августа 2025 года Линус Торвальдс перевёл файловую систему Bcachefs в режим Externally maintained. 


Это значит, что ядро больше не принимает её изменения, а дальнейшая разработка ведётся вне основной кодовой базы.

Причина — конфликты с автором проекта Кентом Оверстритом: он присылает крупные изменения в неподходящее время, нарушая процесс ядра.

Торвальдс считает, что поздние релизы должны лишь исправлять ошибки, а Оверстрит настаивает на срочном исправлении багов для сохранности данных. Bcachefs остаётся экспериментальной ФС.
Please open Telegram to view this post
VIEW IN TELEGRAM
6👍2🤔1
Logrotate для нестандартных приложений

Стандартные сервисы вроде Nginx или syslog ротируются автоматически, а вот для нестандартных daemon или собственных приложений нужно использовать postrotate, sharedscripts и правильно обрабатывать сигнал HUP.

postrotate — команды после ротации (например, сигнал процессу перечитать лог).
sharedscripts — если несколько файлов ротируются, скрипт выполняется один раз.
HUP — заставляет daemon перечитать файл без перезапуска.

Пример для PostgreSQL:

/var/log/postgresql/*.log {
daily
rotate 7
compress
delaycompress
notifempty
missingok
sharedscripts
postrotate
systemctl reload postgresql > /dev/null 2>/dev/null || true
endscript
}


Здесь логи сжимаются и хранятся неделю, пустые файлы не ротируются, а PostgreSQL после ротации продолжает писать в новый файл.

Пример для Nginx:

/var/log/nginx/*.log {
daily
rotate 14
missingok
notifempty
sharedscripts
postrotate
[ -f /run/nginx.pid ] && kill -HUP `cat /run/nginx.pid`
endscript
}


Можно добавить уведомление админа через mail или Slack.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍93
Контейнер в Kubernetes постоянно перезапускается. Команда kubectl describe pod показывает:

Back-off restarting failed container Что это означает?
Anonymous Quiz
18%
kubelet не видит контейнер
59%
Pod зациклился в CrashLoopBackOff
7%
Подов слишком много в namespace
16%
Kubernetes перезапустил узел
6🔥3
Мониторинг открытых файлов: lsof

В Linux всё — это файл. Сюда попадают не только документы на диске, но и сокеты, устройства, пайпы.

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


В таких случаях незаменим инструмент lsof (list open files).

Несколько базовых приёмов:
lsof /path/to/file — покажет, какой процесс держит файл открытым. Полезно, если удалённый лог «не освобождает» место.
lsof -i :8080 — кто слушает порт 8080 или держит соединение. Отлично работает при отладке сервисов.
lsof -u www-data — все открытые файлы конкретного пользователя, например, у веб-сервера.

Кроме поиска по файлам и портам, lsof помогает находить процессы с утечками дескрипторов. Иногда сервисы постепенно «съедают» лимит открытых файлов, и тогда lsof -p <PID> покажет, чем именно завален процесс.

🔥 В связке с df и du утилита позволяет быстро вычислить «невидимых пожирателей места», а при отладке сетей — вычленить подозрительные соединения.

Инструмент старый, но до сих пор один из самых надёжных для диагностики.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍144
💬 Вопрос на собеседовании для DevOps-инженера

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


Вопрос: Что такое Transparent Hugepage defrag и как это влияет на производительность системы?

Ответ: Transparent Hugepage (THP) defrag — это механизм в Linux, который пытается объединять мелкие страницы памяти в большие (HugePages) для оптимизации TLB и уменьшения накладных расходов на управление памятью.

Однако агрессивная дефрагментация может вызвать паузы в работе приложений из-за копирования страниц, поэтому в высоконагруженных системах её часто отключают или настраивают в режиме “madvise”, чтобы влияние на производительность было минимальным.
Please open Telegram to view this post
VIEW IN TELEGRAM
6👍3
Поиск «тяжёлых» файлов: ncdu

Когда на сервере заканчивается место, команды вроде du и ls -lh не всегда помогают быстро понять, что именно съедает дисковое пространство. 


На помощь приходит ncdu — интерактивный аналог du, который показывает размер каталогов и файлов в удобной древовидной структуре и позволяет управлять ими прямо из интерфейса.

Например, чтобы проверить логи:

ncdu /var/log


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

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

Плюсы ncdu:
Видно, сколько реально занимает каждая папка.
Можно удалять или перемещать файлы прямо в интерфейсе.
Быстро ориентируетесь на серверах с ограниченным SSD.
Подходит для диагностики как пользовательских, так и системных директорий.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍86🔥1
Первый альфа-выпуск дистрибутива KDE Linux

Команда KDE представила первый альфа-выпуск дистрибутива KDE Linux. 


Системные образы (~5 ГБ) работают в Live-режиме, основаны на Arch Linux, обновляются атомарно и поддерживают зашифрованные разделы для пользовательских данных.

Обновления идут на пассивный Btrfs-раздел с возможностью отката, а дополнительные приложения можно устанавливать через Flatpak, AppImage, Snap, Distrobox или Toolbox.

Альфа рассчитана на тестирование и контроль качества, поддерживает только UEFI, Wayland и новые GPU NVIDIA (Turing+).

В будущем появятся Stable и Enthusiast Edition с финальными и свежими релизами KDE Plasma.
9👍5🔥2👎1
Inotify и fsnotify для событий на файловой системе

Linux умеет уведомлять процессы о событиях на файловой системе.

С помощью inotify (и абстракции fsnotify в ядре) можно отслеживать создание, удаление, модификацию файлов и каталогов, что удобно для автоматизации.

Пример применения: нужно запускать скрипт каждый раз, когда появляются новые логи или выгружается дамп БД. 


Вместо регулярного опроса ls или find достаточно «подписаться» на события файловой системы — это экономит ресурсы и ускоряет реакцию.

Базовый пример с inotifywait (из пакета inotify-tools):

# следим за появлением новых файлов в каталоге /var/log/myapp
inotifywait -m /var/log/myapp -e create -e moved_to |
while read path action file; do
echo "Новый файл $file обнаружен в $path, запускаем скрипт..."
/usr/local/bin/process_new_log.sh "$path/$file"
done


Что можно отслеживать:
• create — создание файла
• delete — удаление
• modify — изменение содержимого
• moved_to / moved_from — перемещение файлов в/из каталога
12👍7
Почему так?
😁223🥴3
Быстрый поиск строк в логах: ripgrep

Когда на сервере гигабайты логов, а надо срочно найти конкретную ошибку, стандартный grep начинает тормозить.

Здесь помогает ripgrep (rg) — современный инструмент поиска по тексту. 


Он оптимизирован под большие объёмы данных и работает в разы быстрее.

Пример для поиска ошибок во всех логах:

rg "ERROR" /var/log


По умолчанию он рекурсивно обходит каталоги и выводит совпадения с путём к файлу и номером строки.

Если нужен контекст вокруг найденной строки:

rg -C 3 "FATAL" /var/log/postgresql


Так выводятся три строки до и после совпадения — удобно при анализе логов PostgreSQL, Nginx или системных журналов.

ripgrep поддерживает регулярные выражения, можно искать сразу несколько шаблонов и фильтровать файлы по расширениям. Например:

rg -t sql "SELECT.*FROM" /var/log


Вывод ограничится только SQL-логами.
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥7👍2
💬 Вопрос на собеседовании для сисадмина

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


Вопрос: Как работает механизм Copy-on-Write (CoW) в Linux и зачем он нужен?

Ответ: Copy-on-Write (CoW) — это оптимизационный механизм, который позволяет нескольким процессам совместно использовать одну и ту же область памяти до тех пор, пока один из них не попытается ее изменить.

При fork дочерний процесс получает копию страниц памяти родительского, но фактически обе копии указывают на одни и те же физические адреса. Только если один из процессов пытается записать в память, ядро создает новую копию изменяемой страницы.
Please open Telegram to view this post
VIEW IN TELEGRAM
6👍4
BGP PIC (Prefix Independent Convergence)

BGP PIC ускоряет failover, предустанавливая резервный next-hop. 


При падении primary hop трафик мгновенно переключается без полной перерасчётки маршрутов. Обычно обычный BGP failover занимает секунды, с PIC — миллисекунды.

Применяется в WAN и датацентрах с критическим SLA, ECMP-сценариях, L3VPN/EVPN.

Виды:

Core (по префиксу) — precomputed backup next-hop в FIB, переключение мгновенное.
Edge (по соседу) — резерв на уровне BGP-соседа, удобно для PE/CE.

Настройка на Cisco IOS-XR:

router bgp 65001
address-family ipv4 unicast
bgp bestpath pic
network 10.0.0.0 mask 255.255.255.0


Juniper JunOS:

protocols {
bgp {
group IBGP {
type internal;
local-address 192.168.0.1;
family inet { unicast; }
pic;
}
}
}


Для проверки failover включают BFD, пингуют primary hop и отключают линк. С BGP PIC потеря пакетов минимальна, трафик идёт на backup сразу.

⚡️Особенности: резервный next-hop должен быть в FIB, потребляет RAM/CPU для precompute, на больших таблицах BGP может потребоваться tuning.
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥3💯2
Cron не запускает скрипт. Вручную работает. Причина?
Anonymous Quiz
30%
Скрипт без shebang
26%
Неправильный cron
42%
Нет прав root
2%
Плохой swap
🤡19🤣74
Инкрементальные бэкапы с tar

Помимо привычных архивов, tar умеет делать инкрементальные бэкапы через ключ --listed-incremental.

Он хранит «снимок» метаданных файлов и при следующем запуске берёт только изменения.

Пример:

# первый полный бэкап
tar --listed-incremental=/var/backups/snapshot.file \
-czf full-backup.tar.gz /home

# инкрементальный
tar --listed-incremental=/var/backups/snapshot.file \
-czf incr-backup.tar.gz /home


👉 snapshot.file — база, где хранится информация о прошлых бэкапах. Если её удалить, то следующий архив будет снова полным.

Плюсы:
экономия места (в архив попадают только изменившиеся файлы);
встроено в стандартный tar, не нужны отдельные утилиты;
можно комбинировать с cron и хранением на удалённом сервере.

Подходит для небольших серверов, dev-сред и домашних каталогов, где не нужна тяжёлая система бэкапов, но важна скорость и простота.
Please open Telegram to view this post
VIEW IN TELEGRAM
10🔥9👍4
Рейтинг языков программирования TIOBE за сентябрь 2025: Python растёт, Perl возвращается

Авторы TIOBE опубликовали свежий рейтинг. Топ-8 остался без изменений (1. Python, 2. C++, 3. C, 4. Java, 5. C#, 6. JavaScript, 7. Visual Basic, 8. Go).

Perl уступил 9-е место Delphi/Object Pascal, но при этом удержался в десятке — год назад он был на 27-м месте.


Рост Perl связывают с огромным количеством книг на Amazon и его уникальными возможностями работы с текстом: регулярные выражения, богатая библиотека CPAN, поддержка Unicode.

Хотя Perl 6 (ныне Raku) так и не взлетел, Perl 5 продолжает обновляться и привлекает внимание.

Эксперты отмечают, что текстовые форматы (XML, JSON, YAML, Markdown, логи) остаются ключевыми даже в эпоху ИИ, и Perl здесь по-прежнему один из лучших инструментов.
5🔥2
etckeeper: контроль версий для /etc

Каталог /etc — сердце системы: здесь лежат конфиги сервисов, сетевые настройки, права доступа. 


Проблема в том, что правки накапливаются хаотично - руками, апдейтами пакетов, скриптами. В итоге, когда «вдруг перестало работать», непонятно кто и когда изменил конфиг.

etckeeper решает задачу просто: сохраняет /etc в Git (или другом VCS). Получаем историю изменений, удобный diff и возможность быстро откатить.

Установка (Debian/Ubuntu):

sudo apt install etckeeper git
sudo etckeeper init
sudo etckeeper commit "init"


После этого можно работать как с обычным репозиторием:

sudo git status /etc
sudo git diff /etc/ssh/sshd_config
sudo git log /etc


Фишка — etckeeper интегрируется с apt и yum: перед обновлением пакетов он автоматически делает commit.

Можно добавить git remote и пушить историю в отдельный репозиторий (например, на приватный GitLab или в backup).

Это удобно для серверов, где нужно отслеживать конфиги централизованно.
Please open Telegram to view this post
VIEW IN TELEGRAM
8👍8