Admin Guides | Сисадмин

Public

Не можете присоединиться? @admguides

11.6k Участники

Обновлено: May 13, 2026 at 11:59 AM

Admin Guides | Сисадмин

Обучающий канал по ОС Linux & Windows для начинающих и действующих администраторов. Админ, реклама: @Ak_Mihail Биржа: https://telega.in/c/admguides РКН: https://kurl.ru/nQejS

@admguides is a growing community focused on httpskurlrunqejs and ak_mihail and related topics

Рейтинг

Глобальный рейтинг

#456

Рейтинг по языку

#45

Рейтинг по категории

#23

-1

Рост участников (Последние 9 дней)

Всего: 11.6K

Рост за 24ч: +0 0%

Последние посты

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

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

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

❓Вопрос: Что такое ASLR (Address Space Layout Randomization) и зачем он нужен в Linux?

✅Ответ: ASLR - это механизм рандомизации адресного пространства процессов, который случайным образом изменяет расположение областей памяти: стека, heap, shared libraries и mmap-сегментов при каждом запуске программы.

Главная цель ASLR - усложнить эксплуатацию уязвимостей типа buffer overflow и ROP-атак, где атакующему нужно точно знать адреса в памяти.

Как это работает:
• При каждом запуске процесса адреса памяти выбираются случайно.
• Даже одна и та же программа получает разные layout’ы памяти.
• Вместе с NX-bit и stack canaries ASLR сильно повышает стоимость эксплуатации memory corruption-багов.

1,270

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

Что происходит внутри ядра когда ты делаешь write() в файл

На поверхности write() выглядит просто: передал данные, они оказались на диске.

На деле между вызовом и физической записью происходит несколько слоёв абстракции.

Системный вызов и переход в kernel space

Когда процесс вызывает write(), происходит syscall: процессор переключается из user space в kernel space. Ядро проверяет дескриптор файла, права и валидность буфера. Это единственный момент где приложение реально взаимодействует с ядром.

Page cache

Данные не идут сразу на диск. Ядро записывает их в page cache, область оперативной памяти где хранятся страницы файлов.

write() возвращает управление приложению практически мгновенно, данные при этом ещё в RAM. Страницы помечаются как dirty.

Writeback

Dirty-страницы периодически сбрасываются на диск процессом pdflush/kworker. Момент сброса определяется параметрами:

sysctl vm.dirty_ratio
sysctl vm.dirty_background_ratio
sysctl vm.dirty_writeback_centisecs

dirty_background_ratio: при каком проценте dirty-страниц начинается фоновый writeback. dirty_ratio: при каком проценте ядро начинает блокировать write() пока данные не сбросятся.

Если нужна гарантия записи

По умолчанию write() не гарантирует что данные на диске. Для этого нужен явный fsync():

write(fd, buf, len);
fsync(fd);

fsync блокирует процесс до тех пор пока ядро не подтвердит физическую запись. Базы данных делают fsync после каждой транзакции именно по этой причине.

Путь до железа

После writeback данные проходят через VFS (Virtual File System), конкретную файловую систему (ext4, xfs), блочный слой с планировщиком IO, и наконец драйвер устройства.

На каждом слое возможна своя очередь и буферизация, включая кеш самого диска.

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

1,540

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

Почему localhost быстрее чем 127.0.0.1 и когда это не так

На первый взгляд звучит как магия: оба адреса указывают на одну машину, но localhost иногда заметно быстрее. Разница не в сети, а в том как система резолвит имя.

Откуда берётся разница

Когда приложение коннектится к localhost, система смотрит в /etc/nsswitch.conf чтобы понять порядок резолвинга. Обычно там стоит:

hosts: files dns

files означает /etc/hosts. Если там есть запись:

127.0.0.1 localhost
::1 localhost

то резолвинг происходит мгновенно, без DNS-запроса. Но если /etc/hosts настроен нестандартно или nsswitch идёт сначала через dns, появляется задержка на DNS-запрос.

Когда 127.0.0.1 быстрее

Если приложение коннектится напрямую по IP, резолвинга нет вообще. Никакого обращения к /etc/hosts или DNS. В теории это должно быть быстрее.

На практике разница в микросекундах и незаметна. Но есть случай когда localhost реально медленнее: если DNS в системе настроен через systemd-resolved или другой локальный резолвер, и /etc/hosts не проверяется первым.

Проверяем порядок резолвинга:

cat /etc/nsswitch.conf | grep hosts

Смотрим куда резолвится localhost:

getent hosts localhost
strace -e trace=network curl http://localhost 2>&1 | grep connect

IPv4 vs IPv6

Вторая причина расхождения: localhost может резолвиться в ::1 (IPv6) вместо 127.0.0.1. Если приложение не поддерживает IPv6 или сокет слушает только на IPv4, соединение упадёт и система попробует IPv4. Лишняя попытка даёт задержку.

Проверяем на что резолвится:

python3 -c "import socket; print(socket.getaddrinfo('localhost', 80))"

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

Почему chmod 777 не всегда решает проблему с правами

chmod 777 это первое что делают когда что-то не читается или не запускается. Иногда помогает, иногда нет, и тогда начинается настоящая диагностика.

Причин почему 777 не помогает несколько, и большинство из них не про права на файл.

1️⃣ACL перекрывает стандартные права

Linux поддерживает расширенные списки доступа поверх стандартных unix-прав. Если на файле есть ACL, он имеет приоритет над chmod.

getfacl /path/to/file

Если в выводе есть строки вида user:someuser:— или mask::r–, ACL блокирует доступ. Убираем:

setfacl -b /path/to/file

2️⃣ SELinux или AppArmor блокирует доступ

Даже с правами 777 SELinux может запретить доступ по контексту безопасности. Проверяем отказы и контекст файла:

ausearch -m avc -ts recent
dmesg | grep denied
ls -Z /path/to/file

Быстрая проверка: временно переводим SELinux в permissive и смотрим исчезла ли проблема:

setenforce 0

3️⃣ Проблема в директории, не в файле

Для доступа к файлу нужны права на все директории в пути. Если где-то выше стоит 700, до файла не доберёшься:

namei -l /full/path/to/file

Покажет права на каждый элемент пути от корня до файла.

4️⃣Процесс запускается под другим пользователем

Права выглядят правильно, но процесс работает не от того юзера которого ты ожидаешь:

ps aux | grep processname

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

[poll]

1,460

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

Debian 13.5: крупное обновление стабильной ветки с 145 патчами безопасности

16 мая 2026 года вышел Debian 13.5 на базе Linux 6.12 LTS с обновлёнными окружениями GNOME 48, KDE Plasma 6.3.6, Xfce 4.20, Cinnamon 6.4.10, LXQt 2.1, MATE 1.26.1 и LXDE 13. Поддерживаются основные архитектуры, включая x86-64, ARM, RISC-V, PowerPC и s390x.

В релизе исправлено 99 ошибок в пакетах и добавлено 145 патчей безопасности, закрывающих уязвимости в системных компонентах и библиотеках. Обновление доступно через стандартный apt-апгрейд, также опубликованы установочные образы.

Параллельно обновлена стабильная ветка Debian 12.14 с аналогичным набором фиксов безопасности и обновлений пакетов, включая OpenSSL, PostgreSQL и Apache.

1,680

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

Как связать Process Mining с BPM и перейти от аналитики к системному управлению процессами?

Process Mining — технология, которая восстанавливает реальную картину исполнения бизнес-процессов по данным из информационных систем. Компании используют её, чтобы увидеть, как процессы работают на самом деле, найти узкие места и отклонения от целевых моделей.

Но найти проблему — только первый шаг. Дальше важно улучшить сами процессы. Для этого Process Mining связывают с BPM-системой и подключают AI, который помогает автоматически находить отклонения и прогнозировать риски.

На бесплатном вебинаре 26 мая команды VK Process Mining и OpenBPM покажут, как выстроить такую связку.

Вы узнаете:
— Чем отличаются BPMN-схемы для бизнеса и для исполнения
— Откуда берутся данные для Process Mining и Task Mining
— Что помогает автоматически находить узкие места и риски
— Как разложить историю исполнения процесса по уровням
— Зачем связывать Process Mining с BPM и какую роль играет AI

📅 26 мая, 11:00 МСК
📍 Онлайн, бесплатно

→ https://vk.cc/cXMwm5?erid=2VtzqxUiW2U

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

Совет на 2027 год — переходите в ML.

Пока обычные разрабы конкурируют с ИИ-копилотами, ML-инженеры эти самые нейронки создают.

В эпоху нейростей это самые востребованые люди в мире программирования. Зарплаты мидлов начинаются от 250 000 ₽, а у сеньоров в BigTech доходят до 700 000 ₽.

А чтобы освоить его всего за 4 месяца без лишней суеты — изучите канал https://t.me/mm_rsai.

Он помог 20+ ученикам найти работу от 250к в ML/NLP/AI-агентах

На канале вы найдёте:

— Всё про самые востребованные стеки(Python, ИИ-агенты, NLP) и почему математика — это не страшно, если учить только нужное.

— Как оформить резюме, чтобы оно пролетало через любые LLM-фильтры и ATS-системы прямо к тимлидам.

— Скрипты переговоров, которые помогли его ученикам прыгнуть с 0 до 360к всего за 8 месяцев.

Во времена острой нехватки ML-разработчиков, это лучшее время, чтобы перекатиться. Переходи и изучай: https://t.me/mm_rsai

1,750

Admin Guides | Сисадмин

26 мая 2026 г., 03:18

📷 Photo

OOM Killer: как Linux убивает процессы и что с этим делать

Сервер работает, потом процесс внезапно исчезает без каких-либо ошибок в его логах. Приложение не крашилось, сигнала не было, просто пропал. Почти всегда это OOM Killer.

Когда физическая память и swap заканчиваются, ядро не падает, а выбирает процесс и убивает его. Выбор основан на oom_score: чем выше балл, тем выше шанс попасть под удар. Учитывается размер процесса, время жизни, приоритет.

Диагностика

Смотрим был ли OOM Killer активен:

dmesg | grep -i "oom\|killed process"
journalctl -k | grep -i oom

Текущий oom_score всех процессов, сортируем по убыванию:

for pid in /proc/[0-9]*; do printf "%d %d %s\n" $pid $(cat $pid/oom_score 2>/dev/null) $(cat $pid/comm 2>/dev/null); done | sort -k2 -rn | head -20

Управление приоритетами

Снижаем вероятность убийства критического процесса (например базы данных):

echo -500 > /proc/$(pgrep postgres)/oom_score_adj

Полностью защищаем процесс от OOM Killer:

echo -1000 > /proc/$(pgrep postgres)/oom_score_adj

Через systemd для постоянного эффекта:

[Service]
OOMScoreAdjust=-500

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

split-horizon DNS и разные ответы внутри/снаружи сети

Split-horizon DNS ломает не сам DNS, а ожидание, что домен всегда = один и тот же IP. Внутри сети и снаружи он может вести на разные системы, и пока это контролируется - всё нормально.

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

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

Сначала важно понять, что реально видит система, а не просто «какой DNS ответил»:

getent ahosts example.com

Это показывает не только IP, но и порядок выбора адресов (IPv4/IPv6, источники NSS), то есть реальное поведение системы, а не абстрактный DNS-ответ.

Дальше часто всплывает systemd-resolved или локальный кеш, который делает ситуацию ещё менее очевидной: два одинаковых запроса могут давать разные ответы в зависимости от пути.

resolvectl query example.com

Здесь видно, откуда пришёл ответ, есть ли кеш и какой TTL реально используется.
Если есть подозрение, что разные зоны или политики DNS отдают разный результат, проверяют конкретный резолвер напрямую, чтобы исключить локальные слои:

dig @10.0.0.53 example.com

Иногда ответ меняется просто из-за того, что запрос идёт с другой сети или через другой DNS-view (ACL, geo, subnet matching).

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

backpressure и деградация без падений

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

Это backpressure - когда входящий поток уже больше, чем система успевает обработать, и она начинает тормозить сама себя вместо отказа.

Снаружи это выглядит как «чуть выросла задержка API», но внутри уже начинают копиться очереди и ожидания. Первое, что обычно видно - TCP начинает хуже справляться с потоком соединений.

ss -s

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

vmstat 1

Параллельно может начинать проседать диск или любые синхронные операции - даже если кажется, что сервис почти не пишет. Очереди начинают расти, и задержки копятся незаметно.

iostat -x 1

1,870

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

1,790

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

Разница между ping, curl и реальным трафиком

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

Ping, curl и продакшн-трафик проверяют разные уровни, поэтому дают разную картину.

⏺ping - это ICMP, он показывает только базовую связность и RTT. Он не использует TCP, не проходит TLS и не нагружает соединения.

ping -c 5 example.com

⏺curl уже ближе к реальности: это TCP + HTTP (+ TLS). Он показывает время установления соединения и ответа, но это всё ещё одиночный запрос без конкуренции.

curl -w "%{time_connect} %{time_starttransfer} %{time_total}\n" -o /dev/null -s https://example.com

⏺Реальный трафик - это параллельные соединения, очереди, ретраи и работа балансировщиков. Тут начинают играть роль backlog, conntrack, лимиты соединений и поведение приложения под нагрузкой.

wrk -t2 -c50 -d10s https://example.com
ab -n 200 -c 20 https://example.com/

Часто сеть «нормальная» по ping, curl тоже проходит без проблем, но под нагрузкой начинают всплывать очереди, лимиты соединений или перегрузка обработки на уровне ядра и приложения.

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

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

[poll]

1,730

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

Решайте DevOps-, SRE- и FinOps-задачи с помощью облачного ИИ-помощника 💬

Большое обновление от Cloud.ru. Что нового:

1️⃣ Сразу несколько ВМ в разных конфигурациях
Теперь ИИ-помощник в облаке может создавать несколько виртуальных машин, а после управлять ими по команде. Например, добавлять или удалять диски, менять конфигурации и выполнять другие повседневные операции.

2️⃣ Три новых сценария
▶️DevOps-агент — может разворачивать и обслуживать PostgreSQL, Kafka, WordPress, GitLab и другие популярные сервисы по текстовому промпту.

▶️SRE-агент — настраивает мониторинг, алертинг и помогает разбирать инциденты.

▶️FinOps-агент — находит забытые или неиспользуемые ВМ и предлагает их удалить, чтобы исключить бессмысленные траты. А еще может показать топ дорогих ресурсов, позволяя сравнивать траты за разные периоды.

https://cloud.ru/ai-assistant https://cloud.ru/ai-assistant https://cloud.ru/ai-assistant?utm_source=tg&utm_medium=im&utm_campaign=admguides_oth_aias_std_txt_smm_pmm

1,510

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

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

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

❓Вопрос: Что такое TCP keepalive и зачем он используется?

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

Как это работает: • Если соединение простаивает, ядро периодически отправляет keepalive-пакеты (probe) другой стороне. • Если ответ не получен после заданного числа попыток, соединение считается мёртвым и закрывается. • Тайминги задаются параметрами ядра (tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes).

1,570

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

docker bridge vs host network: где теряется производительность и появляются «странные» лаги

Контейнер работает стабильно, но при нагрузке появляются задержки, нестабильные ответы или разница между локальными и внешними запросами. Часто это не приложение, а тип сети контейнера.

В bridge-сети Docker добавляет слой: виртуальный интерфейс, NAT и iptables. Трафик проходит через bridge и трансляцию адресов, что даёт дополнительную обработку на каждом пакете.

Посмотреть, в какой сети контейнер:

docker inspect container | grep NetworkMode

Или список сетей:

docker network ls

В bridge режиме каждый пакет идёт через NAT и connection tracking. Под нагрузкой это может давать latency и увеличивать CPU на уровне ядра.

Проверить нагрузку на conntrack:

cat /proc/sys/net/netfilter/nf_conntrack_count

И активные соединения:

conntrack -S

В host network контейнер использует сеть хоста напрямую - без NAT и без bridge. Это убирает лишний слой и снижает задержки.

Запуск контейнера в host-сети:

docker run --network host ...

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

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

Linux 7.1: удаление устаревших драйверов и отказ от поддержки i486

В ядро Linux 7.1 добавлен набор патчей, убирающих старые Ethernet-драйверы, ISDN, AX.25, CAIF и Bluetooth CMTP, а также часть сетевых и радиоподсистем. Это сокращает десятки тысяч строк кода.

Также продолжается поэтапный отказ от поддержки процессоров i486: конфигурация ядра больше не будет включать сборку под эту архитектуру.

Решение принято в ходе обсуждения в сообществе разработчиков и уже поддержано Линусом Торвальдсом.

1,620

Admin Guides | Сисадмин

11 мая 2026 г., 00:27

📷 Photo

nsswitch и порядок резолвинга, который меняет поведение сервисов

Один и тот же домен может резолвиться по-разному: где-то правильный IP, где-то старый, а где-то вообще ошибка. Обычно это не DNS-сервер, а порядок источников в системе.

В Linux резолвинг идёт по цепочке: /etc/hosts → mDNS → DNS (или в другом порядке). Если в nsswitch стоит, например, [NOTFOUND=return], система может вообще не дойти до DNS.

Посмотреть порядок:

cat /etc/nsswitch.conf

Ключевая строка - hosts. Именно она определяет, куда система идёт сначала.

Проверить, откуда реально приходит ответ:

getent hosts example.com

Важно: getent использует системный резолвинг. В отличие от dig, который всегда идёт напрямую в DNS.

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

cat /etc/hosts

Если там есть запись - она перекрывает DNS полностью.

mDNS может добавлять задержки или ломать резолвинг, если сеть не отвечает на multicast:

avahi-resolve -n hostname.local

⏺Что ломается на практике:
• /etc/hosts перебивает реальные записи
• mDNS даёт задержки или блокирует DNS
• разные процессы получают разные IP

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

Совет на 2026 год — переходите в ML.

Пока обычные разрабы конкурируют с ИИ-копилотами, ML-инженеры эти самые нейронки создают.

В эпоху нейростей это самые востребованые люди в мире программирования. Зарплаты мидлов начинаются от 250 000 ₽, а у сеньоров в BigTech доходят до 700 000 ₽.

А чтобы освоить его всего за 4 месяца без лишней суеты — изучите канал Артема Алехина.

Его бэкграунд: Руководитель команды в Сбере, валютная удаленка. К 22 годам вышел на доход 1 000 000+ ₽ в месяц.

На канале вы найдёте:

— Всё про самые востребованные стеки(Python, ИИ-агенты, NLP) и почему математика — это не страшно, если учить только нужное.

— Как оформить резюме, чтобы оно пролетало через любые LLM-фильтры и ATS-системы прямо к тимлидам.

— Скрипты переговоров, которые помогли его ученикам прыгнуть с 0 до 360к всего за 8 месяцев.

Во времена острой нехватки ML-разработчиков, это лучшее время, чтобы перекатиться. Переходи и изучай: https://t.me/+4VMrjA4vN_dmN2Ey

1,370

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

UDP RX ring buffer переполняется

Сеть вроде работает нормально, NIC не показывает ошибки, но часть пакетов теряется, throughput падает, а latency скачет. Проблема не в канале - ядро не успевает обработать входящие пакеты.

ss -u -a -i

Проверяем количество дропов и состояние сокетов.

cat /proc/net/udp

Видно, какие сокеты накапливают очередь и сколько пакетов уже дропнуто.

ethtool -S  | grep rx

Смотрим статистику RX на интерфейсе - дропы на уровне NIC.

cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/netdev_max_backlog

Проверяем лимиты буферов ядра: rmem_max и очередь netdev_max_backlog.

dmesg | grep -i dropped

Иногда ядро логирует, что пакеты теряются из-за переполнения очереди.

1,680

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

Amazon обнаружил, что Linux 7.0 почти вдвое тормозит PostgreSQL на ARM64

Сальваторе Дипьетро заметил: тест pgbench «simple‑update» упал с 98 565 до 50 751 операций.

И дело в том, что планировщик сменил режим с PREEMPT_NONE на PREEMPT_LAZY, из‑за чего PostgreSQL 55 % CPU тратит на вызовы s_lock().

Автор изменений Питер Зейлстра и мейнтейнер планировщика считают, что падение связано с особенностями вытеснения процессов в ядре.

Эксперты подчеркивают: Linux 7.0 на финальной стадии тестирования, а пользователи могут столкнуться с резким снижением производительности одной из самых популярных СУБД.

1,890

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

Ephemeral порты исчерпаны

Сервис активно делает исходящие соединения. CPU и сеть свободны, но часть connect() начинает «залипать».

Новые порты не создаются, потому что диапазон ephemeral портов полностью занят.

ss -s

Смотрим количество открытых TCP-соединений и их состояния.

cat /proc/sys/net/ipv4/ip_local_port_range

⏺Диапазон ephemeral портов - сколько одновременно можно открывать исходящих соединений.

netstat -an | grep TIME-WAIT | wc -l

Сколько соединений в TIME-WAIT блокирует повторное использование портов.

cat /proc/sys/net/ipv4/tcp_fin_timeout

Время удержания TIME-WAIT соединений.

lsof -i -nP | grep 

Сколько портов реально занимает процесс.

1,340

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

OverlayFS тормозит запись в контейнерах

Внутри контейнера всё «нормально», диск быстрый, но запись идёт медленно.

Упирается не в устройство, а в copy-on-write: каждое изменение файла может тянуть копирование из lower слоя в upper.

mount | grep overlay

Показывает, где используется overlay и какие слои задействованы (lowerdir/upperdir/workdir).

docker inspect  | grep -i overlay

Где реально лежит upper слой контейнера.

iostat -x 1

Диск не всегда загружен, но await растёт — операции становятся длиннее из-за COW.

pidstat -d 1

Какие процессы внутри контейнера генерируют запись и с каким latency.

strace -tt -e trace=file 

Видно, как простые write превращаются в цепочку операций (copy + metadata).

2,210

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

1,740

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

[poll]

1,940

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

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

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

❓Вопрос: Что такое CFS bandwidth control и как оно управляет CPU-ресурсами в Linux?

✅Ответ: CFS bandwidth control — это механизм планировщика Completely Fair Scheduler (CFS) для ограничения доли процессорного времени, доступного группе задач (cgroup). Он позволяет задавать квоты CPU для контейнеров и процессов, предотвращая «захват» CPU одним нагрузочным процессом.

Как это работает:
• Задаётся период (cpu.cfs_period_us) и квота (cpu.cfs_quota_us).
• Планировщик распределяет CPU среди процессов так, чтобы группа не превышала выделенную квоту за период.
• Если квота исчерпана, процессы группы ждут до следующего периода, а остальные задачи продолжают выполняться.

1,810

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

Epoll очередь забивается и даёт задержки

Сервис принимает соединения, CPU не упирается, но обработка событий идёт с лагом. Сокеты готовы, а приложение не успевает их вычитывать - очередь событий накапливается.

cat /proc/sys/fs/epoll/max_user_watches

⏺Глобальный лимит на epoll watchers - при упоре новые дескрипторы начинают вести себя нестабильно.

lsof -p  | wc -l

Сколько файлов/сокетов реально держит процесс.

ss -lnt
ss -s

Общее состояние сокетов и накопление соединений.

strace -tt -e epoll_wait -p 

Видно, сколько времени процесс проводит в ожидании и как часто просыпается.

perf top

Если очередь растёт, часто видно перекос в обработке событий или узкое место в userspace.

2,000

Admin Guides | Сисадмин

14 апр. 2026 г., 00:36

📷 Photo

⸻

Read-ahead мешает случайному I/O

Диск быстрый, загрузка невысокая, но при random доступе появляются скачки latency. Ядро продолжает подтягивать данные «вперёд», как при последовательном чтении, и создаёт лишние операции.

blockdev --getra /dev/sda

Текущий размер read-ahead в секторах.

cat /sys/block/sda/queue/read_ahead_kb

То же самое в KB, быстрее сравнивать между устройствами.

iostat -x 1

Смотрим await и r/s: при лишнем read-ahead растёт latency без роста полезного throughput.

pidstat -d 1

Какие процессы генерируют random I/O и как ведёт себя их latency.

blktrace -d /dev/sda -o - | blkparse -i -

Показывает реальные паттерны доступа: видно, что за одним read идут дополнительные, не связанные с workload.

1,760

Showing 30 of 41 posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

Admin Guides | Сисадмин

Admin Guides | Сисадмин

Рейтинг

Рост участников (Последние 9 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Random Open Science

Сердце 🧡 Сообщества

Чат для общения

Студия Никитина | event | нейросети

Прокси тут

Techlead Russia

Помощь подключение

Градостроительный комплекс Москвы

Похожие каналы Telegram

Random Open Science

Сердце 🧡 Сообщества

Чат для общения

Студия Никитина | event | нейросети

Прокси тут

Techlead Russia

Помощь подключение

Градостроительный комплекс Москвы

Отзывы пользователей (0)

Последние посты