Admin Guides | Сисадмин

Проверка бинарей: как убедиться, что твой ls — не троян Когда сервер скомпрометирован, особенно root-доступом, не факт, что top, ps, ss и другие привычные утилиты — настоящие. Их могли подменить. Вот как проверить целостность системных бинарей: Для RPM-систем (CentOS, RHEL, Fedora):

    
        sudo rpm -Va | grep '^..5'{}
    

Символ 5 означает: контрольная сумма не совпадает. Для DEB-систем (Debian, Ubuntu): Установи debsums:

    
        sudo apt install debsums{}
    

Проверка:

    
        sudo debsums -s{}
    

-s показывает только несовпадения. AIDE (Advanced Intrusion Detection Environment) Установка:

    
        sudo apt install aide{}
    

Инициализация:

    
        sudo aideinit{}
    

Проверка:

    
        sudo aide --check{}
    

Можно запускать через cron и мониторить системные изменения, даже если debsums и rpm -V не используются.

На Stepik добавили курс «Linux с нуля» Этот курс закрывает всю обязательную Linux-базу для работы в IT. Подойдёт для:

- разработчиков - девопсов и админов - специалистов по данным и ML - специалистов поддержки и сопровождения - тестировщиков и безопасников

Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой) Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами После прохождения вы получите сертификат, который можно добавить в резюме. В ближайшие 48ч курс доступен со скидкой 30% по промокоду «ADMIN30»: открыть курс на Stepik

Почему нагрузка растёт после увеличения RAM Добавили памяти - ожидали стабильность и запас. Вместо этого вырос load average, усилился write I/O, сервис начал вести себя менее предсказуемо.

    
        Парадокс, который периодически встречается в проде.{}
    

⏺С увеличением RAM меняется поведение page cache. Ядро начинает агрессивнее кэшировать данные, реже сбрасывать dirty-страницы и дольше держать их в памяти. В итоге writeback происходит реже, но более крупными пачками. Это может приводить к коротким, но интенсивным I/O-волнам. Проверить картину можно так:

    
        cat /proc/meminfo | grep -E "Dirty|Writeback|Cached"
vmstat 1{}
    

Если Dirty растёт до больших значений и затем резко падает, а в vmstat видны всплески bo, система работает циклами накопления и массового сброса. Ещё один эффект - изменение reclaim-поведения. Больше памяти → больше кэша → выше watermark’и зон памяти.

    
        cat /proc/zoneinfo | grep pages
sysctl vm.dirty_ratio{}
    

Из-за этого процессы могут дольше писать «в память», а потом синхронно ждать диск. Load при этом растёт не из-за CPU, а из-за процессов в D-state. Иногда увеличение RAM раскрывает сетевые или TCP-лимиты: стек начинает выделять больше буферов на соединения.

    
        cat /proc/net/sockstat
cat /proc/sys/net/ipv4/tcp_mem{}
    

Суммарная TCP memory растёт, что увеличивает давление на систему при пиках соединений.

Торвальдс о версии 7.0: «Когда-нибудь Linux возглавит тот, кто не боится чисел больше 10–15» Линус Торвальдс в рассылке к выходу Linux 7.0-rc1 пошутил, что новый основной номер появился просто потому, что он путается в больших числах. По его словам, версии давно носят формальный характер и не связаны с крупными изменениями.

    
        Релизы выходят 5–6 раз в год, а переход на новую «x.0» происходит примерно раз в 3,5 года - так после 6.19 появилась 7.0. Ранее аналогично произошло с переходом с 5.19 на 6.0.{}
    

В проекте есть план преемственности без конкретного кандидата - с описанным процессом передачи управления. Сам Торвальдс считает, что смена лидера со временем произойдёт естественно. ⏺Linux он начал разрабатывать в 1991 году, и сегодня система используется на миллиардах устройств - от смартфонов до суперкомпьютеров.

Почему сервис начинает отвечать рывками Средний latency выглядит нормально, CPU не забит, ошибок нет - но каждые несколько секунд ответы «замирают». Затем всё снова быстро. Такой профиль часто связан не с приложением, а с тем, как ядро сбрасывает dirty pages на диск.

    
        Когда процессы активно пишут данные, они сначала попадают в page cache. Память накапливает dirty-страницы, и в какой-то момент ядро запускает writeback - массовую запись на диск. {}
    

В этот период процессы могут блокироваться, особенно если диск или файловая система не успевают обрабатывать поток записи. Снаружи это выглядит как периодические скачки latency. Проверить состояние можно так:

    
        cat /proc/meminfo | grep -E "Dirty|Writeback"
vmstat 1{}
    

Если в vmstat видно рост bo (blocks out) одновременно со скачками задержек, а Dirty в meminfo регулярно раздувается и резко падает - система работает циклами накопления и сброса. Поведение сильно зависит от настроек:

    
        sysctl vm.dirty_ratio
sysctl vm.dirty_background_ratio{}
    

Слишком высокие значения позволяют накапливать большой объём dirty-страниц, что приводит к резким «волнам» writeback. Слишком низкие - создают постоянный мелкий flush и лишнюю нагрузку.

АЭРОДИСК ПРИГЛАШАЕТ ВАС НА БЕСПЛАТНЫЙ ВЕБИНАР: «ENGINE AQ 460 — mid-range СХД, которая растёт быстрее, чем ваши задачи». Вебинар состоится 4 марта в 15:00 (МСК) Спикер: Алексей Никифоров — ведущий системный архитектор Программа вебинара: — АЭРОДИСК сегодня: компания и развитие продуктовой линейки — ENGINE AQ 460: поддержка NVMe и архитектура решения — Возможности масштабирования и расширения — ПО «Восток» 6: ключевые функциональные обновления — Модель лицензирования — Типовые сценарии применения — Roadmap развития продуктов — Техническая поддержка и сервисные опции И ответы на вопросы зрителей. Регистрация по ссылке Реклама. ООО "АЕРО ДИСК". ИНН 7731475010. erid: 2W5zFHitCNm

Когда «просто в облако» — не срабатывает.На сайте всё выглядит красиво: переносим в облако — масштабируемся — живём счастливо.В реальности чаще так:• Задержки при работе с критичными приложениями.• Вопросы с безопасностью и комплаенс.• Ограниченные конфигурации.• Сюрпризы в “биллинге”.В таких случаях приходит на помощь не «коробочное решение для всех», а спроектированная архитектура под конкретную задачу.В канале'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'> DataSpace мы разбираем:— как 'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'>онлайн-ритейлер выдержал рост нагрузки в 10 раз без деградации сервисов— где 'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'>гибридная модель действительно оправдана— как быстро сравнить разные 'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'>варианты конфигурации стоимости— какие ошибки чаще всего допускают 'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'>при выборе провайдераТолько разбор архитектуры и практики, с которыми потом не больно жить в проде. Подписывайтесь — 'https://t.me/+FHFzwNe-oJMzZGM6?erid=2W5zFFwVZmB' rel='nofollow'>@dataspace_ru

❓ Как настроить «гибридный порт» на коммутаторах доступа?➡️ Разбираем на вебинаре: "Конфигурирование «гибридного порта» на коммутаторах доступа"В этот раз углубимся в тонкости настройки коммутаторов доступа. Разберем, как корректно организовать работу Voice VLAN и обеспечить безопасность портов.🗓 27 февраля 2026 (пятница)🕒 14:00 по МСКВ программе:☑️Voice vlan - как коммутатору узнать, что к нему подключен телефон?☑️LLDP-MED - как коммутатор сообщает телефону параметры работы?☑️Альтернативные варианты реализации☑️Особенности совместной работы с port security и 802.1х🎙 Спикер:Алексей Листаров — инженер с многолетним опытом работы в крупном операторе связи. Сертифицированный преподаватель нашего авторизованного центра Академии Eltex.❓ Есть сложные кейсы? Записывайте вопросы и приходите на трансляцию👉 Регистрация#eltex #eltexcm #webinar #вебинар #voice_vlan📱@eltexcm#рекламаО рекламодателе

GRO/LRO и скрытая нагрузка на CPU Интерфейс держит трафик, потерь нет, но одно ядро стабильно загружено softirq. Остальные почти простаивают.

    
        При этом CPU в среднем «низкий». Часто это эффект offloading - в частности GRO (Generic Receive Offload) или LRO.{}
    

GRO/LRO агрегируют несколько пакетов в один крупный буфер ещё до передачи в стек. Это снижает количество обработок на уровне TCP/IP и уменьшает overhead на каждый пакет. Но агрегированные пакеты обрабатываются тем CPU, который обслуживает очередь RX. Если IRQ и RPS не распределены, вся тяжёлая работа концентрируется на одном ядре. Проверить, включён ли offloading:

    
        ethtool -k eth0{}
    

Посмотреть, где обрабатываются сетевые прерывания:

    
        cat /proc/interrupts
cat /proc/softirqs | grep NET_RX{}
    

Если счётчики растут в основном на одном CPU, нагрузка не распределяется. ⚡️При высоком PPS или burst-трафике это может давать latency spikes, даже если общая загрузка системы выглядит безопасной.