raidshadowlegend

raidshadowlegend

Пикабушник
0sennijLis
0sennijLis оставил первый донат
20К рейтинг 40 подписчиков 6 подписок 63 поста 43 в горячем
Награды:
Пикабу 17 лет!
4

Читать можно. Писать — нет⁠⁠

NVIDIA выпустила Open Agent Safety Platform. Вместе с ней — OpenShell 0.1.0.

Это не новый агент. OpenShell не заменяет Codex, Claude Code, Hermes и прочие. Он работает чем-то вроде враппера. Агент сидит в песочнице: на уровне ОС ограничиваются файлы и процессы. Рядом Supervisor проверяет исходящий трафик — HTTP, GraphQL и MCP.

Политики пишут на YAML. Дальше они компилируются в правила OPA Rego и проверяются на каждый исходящий запрос. К одному и тому же API можно разрешить чтение и запретить запись. Обычная библиотечная история: книгу дают, карандаш — нет.

Секреты агенту не отдают: они остаются вне его workload. При этом сервис, куда он стучится, свои права всё равно проверяет сам — OpenShell добавляет ещё один слой контроля, а не заменяет авторизацию сервиса.

По умолчанию сети может не быть вообще — тогда curl падает ещё на уровне ядра. Разрешить только чтение GitHub API можно одной командой, причём песочницу перезапускать не надо. Каждое решение политики остаётся в журнале OCSF.

На железе эту схему дополняет NVIDIA Sentry. Она работает на BlueField-4, не на третьем поколении — у BlueField-3 заметно меньше вычислительной мощности. В системах Vera Rubin POD эти DPU стоят на единственном пути к модели. Через NVIDIA DOCA Sentry связывает разговоры агента, решения политик и обращения к инструментам в контекстные записи активности.

На испытаниях агенты до двух часов уговаривали ИИ-ревьюеров дать им права на изменение защищённого репозитория. Уговаривать им не тяжело, не устают. OpenShell в это время показывал ревьюерам, что запрашиваемые права на самом деле позволяют, даже когда агент пытался ими манипулировать. Записей в защищённые репозитории не произошло.

Что тут сказать. Ну наконец-то безопасность агентов начинают строить не вокруг надежды на их хорошее поведение, а вокруг обычных системных ограничений: песочницы, политик доступа, сетевых правил и аудита. Давно пора.

tg

Показать полностью
9

Новый бенчмарк bcachefs⁠⁠

Сегодня наткнулся на новый, основательный бенчмарк bcachefs.

В июньской заметке я гонял Bcachefs против Btrfs на Ubuntu 26.04 в Proxmox Картина тогда была такая:
- Bcachefs заметно быстрее на последовательной записи, 4K random write и создании мелких файлов;
- Btrfs быстрее на последовательном чтении и чуть шустрее на rm -rf дерева мелких файлов;
- сжатие zstd и снапшоты у обеих отрабатывают штатно;
- replicas=2 переживает выдёргивание диска, но это был синтетический стенд с оговорками (ВМ на ZFS, плюс warning про journal_flush_seq stuck).

Новый бенчмарк ту же историю в целом подтверждает и расширяет.

По сводному индексу Bcachefs выглядит сильнее: single 184 против 133 у Btrfs, зеркало replicas=2 — 152 против 103 у Btrfs RAID1. Особенно велик отрыв в Core I/O и responsiveness.

Сырые цифры последнего прогона в ту же сторону, что и летом:
- seq write: Bcachefs single 375 МиБ/с vs Btrfs 284; зеркало 194 vs 168;
- random write 4K + fsync: ~11k IOPS vs ~3.5k на single, ~9k vs ~2.6k на зеркале;
- fsync p99: ~3 мс у Bcachefs против ~6.5 / 10 мс у Btrfs;
- seq read по-прежнему за Btrfs (~415 vs ~374 МиБ/с на single) — это совпадает с моим стендом.

Метаданные смешанные: дерево из 20k файлов Bcachefs создаёт быстрее, копирование и удаление чаще лучше у Btrfs. Сжатие zstd сопоставимо. В деградированном режиме и на «почти полном» диске картина уже не «всегда Bcachefs»: у Btrfs иногда выше скорость записи near-full, scrub у него заметно короче. Corruption probe оба зеркала переживают.

Итог тот же, что и у меня в июне, только теперь на более широкой матрице: Bcachefs после снятия experimental выглядит конкурентоспособным CoW-вариантом и часто быстрее Btrfs на записи и fsync, особенно в multi-device. Btrfs по-прежнему спокойнее читает последовательно и привычнее в эксплуатации. Оба набора цифр синтетические и зависят от подложки; на железных дисках у автора бенчмарка отдельные прогоны, их меньше (но у меня-то их совсем не было, тем и ценен новый бенч). Для homelab интересно, в прод — только с бэкапами и пониманием, что Bcachefs живёт внешним DKMS-модулем.

tg

Показать полностью
49

Патчи пришли тихо: без звука, без RDP и без Ctrl+V⁠⁠

Коллега уже публиковал инфо про это обновление, но как-то без огонька. Хотя оно заслуживает куда больше внимания и отдельного рассказа.

В общем дело было так.

Сентябрь шёл относительно спокойно, пока на прошлой неделе не добрался до Patch Tuesday. В Редмонде закрыли очередную пачку дыр, а взамен раздали три подарка: мёртвый RDP, пропавший звук и Excel без вставки.

Microsoft официально признала все три проблемы, так что спорить не с кем. Разбираем подарки.

Первый подарок: RDP.
Соединение устанавливается и живёт несколько минут. Через несколько минут обрыв. Сервер в это время висит на «Please wait for the Remote Desktop Configuration» и не уточняет, сколько ждать.

Следом перестают отвечать MMC, RDS Licensing Diagnoser и Проводник. Страница Windows Update крутит индикатор бесконечно, так что откатиться через настройки сходу не выйдет. Зоопарк пострадавших широкий: от Windows 11 26H1 до Windows Server 2012.

Есть версии, кто виноват. Самая правдоподобная — накопительное обновление KB5124008: его называют на форумах. Официального подтверждения номера нет.

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

У Windows Server 2012 свой сюжет: 13 октября он выходит из программы расширенных обновлений. Уходит на пенсию. С восхитительным прощальным подарком.

Следом пропал звук.

На Windows 11 24H2, 25H2 и 26H1 отваливается поддержка части устройств USB Audio Class 1.0. Это стандарт конца девяностых. Он пережил три десятилетия прогресса и не пережил один вторник.

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

Некоторым помогло принудительное переключение в двухканальный режим. Звук возвращается в сокращённом составе.

Фикс обещают. Сроков не называют (в Редмонде любят интригу).

И король сезона: Excel.

Патч закрывал уязвимости удалённого выполнения кода и раскрытия информации в Excel 2016, 2019, 2021 и 2024. Заодно закрыл Ctrl+V.

Теперь вставка может не сработать. Источник остаётся выделенным, приёмник не меняется, сообщений об ошибке нет. Формулировка Microsoft достойна цитатника: «The paste operation might fail silently».

Любимое слово в цитате — «might». Вставка не падает и не ругается. Она может просто не сработать, молча. Обнаружится это, когда будет поздно.

Обходного пути нет. На форумах лечатся переустановкой Office или сносом самого обновления.

Со сносом обновления тоже есть нюанс: вместе с ним уходят и закрывавшиеся им дыры. Придётся выбирать между потерей данных и открытыми уязвимостями.
У кого автообновления включены, тем выбирать не пришлось: патч уже стоит.

Фон у истории богатый.

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

На Hacker News под новостью набралось 236 пунктов и 151 комментарий. Спрашивают, сколько человек написали LGTM на том security-патче. Советуют выдерживать патчи месяц, прежде чем ставить. И шутят: корпорация не устаёт хвастаться, будто код у неё теперь пишет ИИ.

tg

Показать полностью
26

Как разблокировать LUKS-корень Альт Linux по SSH⁠⁠

Серия Эксперименты в homelab

Не так давно наткнулся на статью Red Hat про разблокировку LUKS-шифрования по SSH. Суть там простая: сервер с зашифрованным корнем перезагружается, замирает в initramfs и ждёт парольную фразу на консоли, за которой никто не сидит. Решение у редхатовцев выглядит довольно простым: поставить пакет dracut-sshd, включить модуль NetworkManager в initramfs, дописать параметры ядра. Несколько команд, и застрявшая машина открывается по SSH с вашего дивана.

И стало мне интересно: а как та же задача решается, если у меня на серваках крутится не RHEL, а Альт? Копировать редхатовский рецепт вслепую смысла нет: у Альта собственная система сборки initramfs и свои механизмы ранней загрузки. Тем любопытнее посмотреть, как всё устроено здесь.

TL;DR. Сделать можно. Проверил это на живой виртуалке. Рецепт в итоге вышел на удивление прямолинейный, но с двумя-тремя особенностями, о которых лучше узнать из статьи.

Постановка задачи, или зачем шифровать то, что стоит в шкафу

Сначала два слова о проблеме, чтобы не тащить за собой тех, кто уже в теме. LUKS — это формат шифрования блочных устройств в Linux: корневая файловая система лежит внутри зашифрованного контейнера, и пока контейнер не открыт, ранней загрузке нечего монтировать. Разумная практика для сервера, который стоит где-нибудь в чужом дата-центре: вынули диски — получили криптографический мусор вместо базы клиентов.

Обратная сторона фичи: при каждой перезагрузке кто-то обязан вручную ввести фразу. Клавиатура, монитор, поездка в дата-центр (или BMC-консоль, если повезло с железом). Сервер перезагрузился ночью после обновления, и всё: он ждёт вас. Физически.

Идея разблокировки по сети существует столько же, сколько удалённые серверы: положить в initramfs сетевой стек и маленький SSH-сервер, подключиться к машине, пока она стоит на паузе, и вручить ей парольную фразу издалека. Red Hat делает это средствами dracut, своего генератора initramfs, и честно хвастается, что весь рецепт — пакет, строчка конфига и пара параметров ядра (на RHEL пакет тянется из EPEL, на Fedora он в основных репозиториях).

А теперь посмотрим, что для этого есть у альтоводов.

Альт не Рльех: make-initrd против dracut

В ALT Linux свой генератор initramfs, называется make-initrd. Это самостоятельная разработка, которую Альт использует с незапамятных времён. Устроен он концептуально иначе: образ собирается из «фич» (features), каждая фича — набор скриптов и файлов в /usr/share/make-initrd/features/. Нужна сеть в initramfs — есть фича network. Нужен SSH — есть фича dropbear. Нужен LUKS — есть фича luks.

Поддержка LUKS в make-initrd вынесена в отдельный пакет make-initrd-luks. При установке с шифрованием установщик сам ставит этот пакет, сам включает фичу luks в /etc/initrd.mk и сам записывает /etc/crypttab, а make-initrd исправно кладёт этот crypttab в образ.

Если пакета нет, указание отсутствующей фичи не вызывает ошибки — такое поведение задокументировано. Образ соберётся, но внутри не окажется ни cryptsetup, ни обработчика шифрованных разделов. Поэтому после установки пакета и каждой пересборки стоит внимательно смотреть на строку Used features: среди использованных фич должна быть luks.

Стенд: поднимаем сервак, который не жалко

Чтобы не экспериментировать на боевых машинах, я поднял в своём Proxmox виртуалку с Альт Сервер 11.1. В итоговой разметке получились отдельный /boot без шифрования (grub и initramfs должны читаться до ввода пароля), отдельный swap и корень внутри LUKS2-контейнера с aes-xts. Проще говоря, типовой сервер, только с шифрованием из коробки.

Первая же загрузка такой машины выглядит так. В initramfs работает событийная кухня: udev обнаруживает устройства, а демон ueventd передаёт их обработчикам. Обработчик 085-luks видит LUKS-раздел, заглядывает в скопированный в образ /etc/crypttab, не находит файла-ключа и запрашивает парольную фразу на консоли:

udev: session=5: @85-luks: Trying to ask the user for a password.
Enter passphrase for /dev/sda3:

И стоит. Загрузка дальше не идёт, потому что корень физически недоступен. Вот эту сцену мы и будем лечить.

Рецепт

Шаг первый — пакеты. Как я уже говорил, на системе, изначально установленной с LUKS-корнем, make-initrd-luks уже стоит, а фича luks уже включена в /etc/initrd.mk. Остаётся поставить dropbear — маленький SSH-сервер (сама фича dropbear уже есть в базовом пакете make-initrd, но бинарник надо откуда-то взять) — и sysklogd: фича dropbear требует фичу syslog, а syslog без бинарников klogd/syslogd в образ не собирается:

$ apt-get install dropbear sysklogd

Теперь важная строчка в /etc/crypttab. Установщик пишет туда запись с именем вида luks-; мы дописываем опцию headless в четвёртую колонку:

luks-ВАШ-UUID UUID=ВАШ-UUID none luks,headless

Этот флаг разбирает штатный обработчик 085-luks. Без headless он занимает консоль и запускает собственный cryptsetup, а потом наш второй cryptsetup по SSH начинает с ним толкаться локтями. С headless обработчик не спрашивает фразу на консоли и освобождает дорогу удалённой разблокировке. Цена очевидна: обычного запроса фразы на локальной консоли в этой загрузке тоже не будет, поэтому резервный вариант загрузки следует проверить заранее.

Шаг второй — отдельный ключ для разблокировки. Заводим его заранее и не смешиваем с основным:

$ ssh-keygen -t ed25519 -f ~/.ssh/unlock_key -N ''
$ scp ~/.ssh/unlock_key.pub user@сервер:/tmp/unlock_key.pub
$ ssh user@сервер "sudo -S sh -c 'mkdir -p /root/.ssh; cat /tmp/unlock_key.pub >> /root/.ssh/authorized_keys; chmod 700 /root/.ssh; chmod 600 /root/.ssh/authorized_keys'; rm /tmp/unlock_key.pub"

Шаг третий — конфиг /etc/initrd.mk. Эти строки добавляются к существующему файлу, не заменяют его. Строку про luks добавлять не нужно: на установке с шифрованием она там уже есть (если вы шифровали корень уже после установки — добавьте и её, вместе с пакетом make-initrd-luks):

FEATURES += network syslog dropbear
PUT_FILES += /etc/passwd /etc/shells /root/.ssh/authorized_keys
PUT_FILES += /etc/dropbear/dropbear_rsa_host_key /etc/dropbear/dropbear_ecdsa_host_key

Про сеть вопросов быть не должно, как и про /etc/passwd с /etc/shells по идее тоже. SSH-серверу нужно знать, под кем пускать.

Шаг четвёртый — host-ключи dropbear. Без них dropbear сгенерирует новые при каждой загрузке, и ваш ssh будет каждый раз истерить про смену ключа хоста:

mkdir -p /etc/dropbear
dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key

Шаг пятый — маленькая самодельная служба, без которой не будет интерактивного входа. В штатном образе make-initrd нет каталога /dev/pts, поэтому dropbear не может выдать PTY, и ssh -t отваливается с «PTY allocation request failed». Забавно, что rc-скрипт фичи dropbear уже пытается смонтировать devpts, но монтировать некуда: каталога-то нет. Лечится одним скриптом.

Свои каталоги для админских настроек make-initrd пока не завёз, но у него есть переменная PUT_DIRS: каталоги из неё копируются в образ целиком, вместе с деревом. Создаём нашу службу в /etc:

mkdir -p /etc/make-initrd/devpts/etc/rc.d/init.d

Файл /etc/make-initrd/devpts/etc/rc.d/init.d/devpts:

#!/bin/bash
### BEGIN INIT INFO
# Provides: devpts
# Required-Start: cmdline
# Default-Start: 3 4 5
### END INIT INFO
[ "$1" = start ] || exit 0
. /.initrd/initenv
. /etc/init.d/functions
mount_devpts()
{
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts -o mode=0620
}
action_shell 'Mounting devpts:' mount_devpts

Не забудьте chmod +x и допишите в /etc/initrd.mk строку:

PUT_DIRS += /etc/make-initrd/devpts

Шаг шестой — сеть и таймер. Фича network настраивается параметром ядра ip=dhcp. И сразу же, той же строкой, добавьте rootdelay=600 (может пригодится): оба параметра — в переменную GRUB_CMDLINE_LINUX_DEFAULT файла /etc/sysconfig/grub2.

Шаг седьмой — пересборка всего, что зависит от конфигов:

make-initrd
update-grub

В выводе make-initrd появится строка Used features — проверьте глазами, что там есть luks, network, syslog и dropbear. Дальше можно перезагружаться и смотреть.

Момент истины

Перезагружаемся и ждём какое-то время: в initramfs поднимаются сеть (DHCP) и dropbear. Подключаемся самым обычным образом:

ssh -t -o HostKeyAlias=server-initramfs -i ~/.ssh/unlock_key root@сервер

Благодаря службе из пятого шага получаем живое приглашение (initramfs)$ — полноценный интерактивный сеанс. Открываем контейнер:

cryptsetup open /dev/disk/by-uuid/ВАШ-LUKS-UUID ИМЯ-ИЗ-CRYPTTAB

UUID — из второй колонки crypttab, имя (у установщика оно вида luks-) — из первой. cryptsetup сам спросит парольную фразу и отключит эхо; по пути ввод шифрует SSH. Оговорка для параноиков: root на клиенте или в initramfs остаётся доверенной стороной, и от уже подменённого initramfs это не спасает.

Дальше всё происходит само: обработчики прогоняют fsck, монтируют корень, прощаются с dropbear — и наша SSH-сессия обрывается, а система грузится как ни в чём не бывало.

А теперь про rootdelay=600, который может пригодиться. По умолчанию initramfs ждёт корень 180 секунд. Не успели разблокировать — загрузка валится в аварийную оболочку, и дёшево это не лечится: rootdelayd намертво захватывает консольную блокировку, остальные обработчики виснут на ней же, и даже правильно введённая после дедлайна фраза уже ничего не оживит — только перезагрузка и новая попытка. Заодно по консоли в этом состоянии сыплются сообщения «085-luks: unable to activate LUKS (rc=1)» — при headless это нормальный шум, обработчик лишь рапортует, что спрашивать фразу ему запретили. В принципе 180 секунд вполне достаточно чтобы успеть ввести парольную фразу, но для надёжности интервал проще увеличить до rootdelay=600 (на общее время загрузки это всё равно не повлияет).

Проверяем после загрузки: findmnt -n -o SOURCE / отдаёт /dev/mapper/luks-ВАШ-UUID, cryptsetup status показывает активный LUKS2. Сервер поднялся, что не может не радовать.

Про безопасность, без неё никак

Список оговорок, идущий в комплекте с любым рецептом «SSH в раннюю загрузку».

Ваш публичный ключ и host-ключи лежат в initramfs, который лежит в /boot, который не шифруется. Кто-то с физическим доступом к диску получит и ключ, и возможность подменить загрузочную среду. От угрозы «диск вынули и унесли» это спасает; от угрозы «диск подменили и подслушивают фразу» — нет, тут нужны другие механизмы, от Secure Boot до выноса /boot на съёмном носителе.

Отдельный ключ для разблокировки — не волшебная защита: запись в authorized_keys без принудительной команды даёт полноценный root в среде initramfs. Ограничение через forced command в dropbear я на стенде не проверял, поэтому вслух обещать не буду.

В known_hosts у машины появится два разных ключа: initramfs-dropbear и системный openssh. Два SSH-сервера — два ключа, всё честно. ssh при встрече второго устроит сцену про man-in-the-middle — не поддавайтесь: у ранней загрузки свой HostKeyAlias (в командах выше он уже прописан), а отпечаток при первом знакомстве сверяем по консоли. Строгую проверку не выключаем: лучше один раз посмотреть отпечаток глазами, чем потом гадать, кто это у нас там разблокировал сервер.

Заключение

Соберём в одну кучу. Два пакета, три штатные фичи, один самодельный скрипт с открытку, словечко headless в crypttab, rootdelay в параметрах ядра, отдельный ключ, вшитые passwd с shells и host-ключи, пересборка образа с загрузчиком. После перезагрузки вас встречает ssh -t со знакомым запросом фразы, дальше сервер справляется сам. Ручной работы вышло примерно как у редхатовцев; разница в том, что их последнюю милю за них уже написал пакет, а свою мы бахнули сами. Всего-лишь несколько строчек, между прочим (честно говоря на старте я думал, что решение будет куда сложнее).

И напоследок. DHCP в ранней загрузке иногда капризничает, headless запрещает серверу спросить вас на консоли, а таймер тикает при любых раскладах. Так что это, конечно, удобно, но не должно быть единственным ключом от машины. Так что резервный доступ (IPMI, консоль хостера, второй интерфейс со статикой) должен жить отдельно, а всю связку сначала гоняем на сервере, до которого можно дотянуться рукой.

tg

Показать полностью
7

Ваш процессор спит на работе. Показываем, как это прекратить⁠⁠

Пакет приезжает в сервер. Миллисекунды на счету. А ядро процессора в этот момент — в глубоком сне, и его сначала надо разбудить.

Кто виноват? Энергосбережение.

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

За производительность отвечает CPUFreq: governor задаёт политику, а драйвер и сам процессор выбирают подходящий P-state. В результате частота может гулять вверх-вниз.

За сон — отдельная история: простаивающее ядро уходит в C-state.

Для обычного веб-хостинга это разумно. Для высокочастотного трейдинга, VoIP и других систем, чувствительных к задержкам, это уже может стать проблемой. Выход из глубокого C-state занимает микросекунды. Микросекунды складываются в джиттер, лаги и потерянные тики.

Сначала — как устроен сон процессора. Есть несколько состояний, и это почти как на работе:

  • C0 — работает. Исполняет инструкции, кофе, всё такое.

  • C1/C1E — задремал на стуле. Исполнение остановлено, но просыпается быстро.

  • C3/C6 и глубже — уехал домой. Всё больше блоков процессора переводится в энергосберегающий режим.

Экономия растёт с глубиной сна. Но вместе с ней обычно растёт и время выхода из idle.

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

Ядро без работы, тихо сваливающее в C6.

Ядро без работы, тихо сваливающее в C6.

Теперь лечение. Понадобятся две утилиты: cpupower — смотреть и крутить параметры CPU, и tuned — применять готовые профили настройки системы.

Ubuntu/Debian:

sudo apt update
sudo apt install linux-tools-common linux-tools-generic tuned -y

CentOS/RHEL:

sudo dnf install kernel-tools tuned -y

И запускаем демон, чтобы настройки переживали перезагрузку:

sudo systemctl enable --now tuned

Шаг второй — смотрим, что сейчас

Сначала — политика управления частотой:

cpupower frequency-info

В выводе ищем блок current policy: минимальную и максимальную частоты, активный governor и используемый scaling driver.

Для наглядности можно посмотреть и на частоты из /proc/cpuinfo:

watch -n 1 "grep 'cpu MHz' /proc/cpuinfo"

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

Теперь смотрим idle-состояния:

cpupower idle-info

А если хочется увидеть, сколько времени CPU действительно проводит в разных состояниях:

sudo cpupower monitor -i 1

Вот это уже интереснее. Мы можем не только что-то настроить, но и потом проверить, действительно ли процессор перестал проводить время в глубоких C-states.

Смотрим, как частоты и idle-состояния живут своей жизнью.

Смотрим, как частоты и idle-состояния живут своей жизнью.

Дальше — профиль. Вместо ручной крутилки десятков параметров у TuneD есть готовые профили. Для систем, чувствительных к задержкам, нас интересует latency-performance.

tuned-adm list
sudo tuned-adm profile latency-performance
tuned-adm active

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

Процессор перестаёт экономить на каждом удобном случае.

Но физическая частота всё ещё может меняться. Причины: Turbo, аппаратное управление производительностью, ограничения по температуре и мощности. Поэтому правильнее говорить не «частота прибита гвоздями», а «система больше не пытается агрессивно её занижать».

Для сетевых задач у TuneD есть родственный профиль network-latency, но сегодня мы говорим именно про latency-performance.

Но есть нюанс: частота — это P-states. Глубокий сон — C-states.

Сам Governor запретить ядрам уезжать домой не может.

Нельзя просто взять и запретить процессору спать через Governor.

Нельзя просто взять и запретить процессору спать через Governor.

Но мы включили не просто Governor, а профиль TuneD.

latency-performance знает про эту проблему и ограничивает допустимую задержку выхода из idle через PM QoS. В результате CPUIdle перестаёт выбирать слишком глубокие C-states с большой exit latency.

То есть в большинстве случаев на этом уже можно остановиться.

Проверяем:

tuned-adm verify
sudo cpupower monitor -i 1

Если профиль применён корректно, в мониторинге должно быть видно, что процессор перестал надолго проваливаться в глубокие idle-состояния.

А если хочется жёстче?

Иногда хочется не попросить CPUIdle избегать глубоких состояний, а вообще не давать драйверу их использовать.

Тогда можно ограничить C-states через параметры ядра.

Но сначала нужно понять, какой CPUIdle-драйвер работает:

cat /sys/devices/system/cpu/cpuidle/current_driver

Если используется intel_idle, можно ограничить его, например:

intel_idle.max_cstate=1

Если используется acpi_idle:

processor.max_cstate=1

Ориентироваться только на логотип Intel или AMD здесь не стоит. Важен именно активный CPUIdle-драйвер.

На Ubuntu/Debian параметры обычно добавляют в /etc/default/grub в строку:

GRUB_CMDLINE_LINUX_DEFAULT="..."

После чего:

sudo update-grub

И перезагрузка.

На RHEL/CentOS удобнее использовать grubby, например:

sudo grubby --update-kernel=ALL --args="intel_idle.max_cstate=1"

Для acpi_idle соответственно:

sudo grubby --update-kernel=ALL --args="processor.max_cstate=1"

После перезагрузки проверяем ещё раз:

cpupower idle-info
sudo cpupower monitor -i 1

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

Послесловие

Итог: сервер стал прожорливее и горячее (а счета за электричество весомее), зато ядрам больше не дают проваливаться в глубокий сон.

Пакет приехал — разбудить процессор можно гораздо быстрее.

Если процессор не уходит в глубокий сон, из латентности исчезает ещё один источник непредсказуемости.

Для трейдинга, VoIP и других систем, чувствительных к задержкам, это как раз тот случай, когда микросекунды действительно имеют значение.

Показать полностью 3
Отличная работа, все прочитано!

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества

Недвижимость и ремонт

Теги

Популярные авторы

Сообщества