🌐 Skill: curl с секундомером — дебажим тормоза сайта ⏱️

Пользователи жалуются: "Сайт открывается медленно".
Ты пингуешь — пинг отличный.
В чем дело? В DNS? В установке SSL? В генерации страницы бэкендом?

Обычный curl просто качает HTML.
Но если добавить форматирование, он превращается в мощнейший профайлер.

Команда-диагност:

curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL Handshake: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://google.com

Что ты увидишь:
* DNS: Сколько искали IP.
* Connect: Сколько устанавливали TCP.
* SSL Handshake: Сколько времени заняло шифрование (частая причина тормозов!).
* TTFB: Как долго думал сервер, прежде чем отдать первый байт.

Сразу видно: если DNS быстрый, а TTFB долгий — иди пинать разработчиков БД, сеть тут ни при чем. 🏎️

#networking #curl #performance #troubleshooting #web #devops #latency

🐧 Linux: Быстрая очистка RAM без перезагрузки через Drop Caches 🧹

Бывает, что Linux «съедает» всю свободную память под кэш (buff/cache), и хотя ядро должно само освобождать её при необходимости, иногда тяжелые приложения (Java, базы данных) начинают свопиться (Swap), видя, что свободных страниц мало.

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

Как проверить текущее использование:

free -h

Команда для сброса кэша страниц, dentry и inodes:

# Очистка только PageCache (самое безопасное)
echo 1 | sudo tee /proc/sys/vm/drop_caches

# Очистка инодов и дендриев
echo 2 | sudo tee /proc/sys/vm/drop_caches

# Полная очистка всего кэша (максимальный эффект)
echo 3 | sudo tee /proc/sys/vm/drop_caches

Важно: Перед этим выполни команду sync, чтобы все данные из памяти точно записались на диск. Это временная мера, но она отлично помогает «продышаться» серверу перед тяжелой задачей.

#linux #performance #sysadmin #memory #optimization #kernel #lifehack

🐧 Linux: Оптимизируем Swap с помощью vm.swappiness и vfs_cache_pressure 🧠

Многие админы до сих пор спорят: выключать Swap или нет?
В 2026 году ответ — нет, но его нужно настроить.
Если оставить дефолтные значения, ядро может начать вымывать полезный кэш приложений в Swap слишком рано, вызывая «фризы».

Параметры, которые меняют всё:

vm.swappiness: определяет, насколько активно ядро скидывает данные в Swap.
Для серверов с базами данных лучше ставить 10 (вместо дефолтных 60).

vm.vfs_cache_pressure: контролирует, как долго ядро хранит кэш файловой системы (inodes/dentry).
Если памяти мало, а файлов много, поставь 50 вместо 100.

Как применить без перезагрузки:

sudo sysctl -w vm.swappiness=10
sudo sysctl -w vm.vfs_cache_pressure=50

# Чтобы сохранить после ребута, добавь в /etc/sysctl.conf

Результат: Сервер станет заметно отзывчивее при операциях с диском и перестанет «тупить» при заполнении RAM.

#linux #performance #sysadmin #kernel #optimization #swap #devops

🐧 Linux: Мониторим открытые сокеты с помощью ss вместо netstat 🔍

Многие до сих пор по привычке пишут netstat -antp, хотя этот инструмент давно помечен как deprecated.
В современных дистрибутивах (Debian 13+, RHEL 10+) используй ss (socket statistics) — он берет данные напрямую из ядра через netlink, что в разы быстрее и информативнее.

Полезные комбинации для админа:

# Показать все слушающие TCP-порты с именами процессов
ss -tulpn

# Посмотреть установленные соединения с конкретным IP
ss -at dst 192.168.1.50

# Статистика по типам сокетов (сколько TCP, UDP, RAW)
ss -s

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

#linux #networking #ss #terminal #sysadmin #performance #admin_future

🐧 Linux: Быстрый тюнинг дескрипторов — исправляем «Too many open files» 📂

Бывает, что сервис (особенно нагруженный Nginx или БД) начинает захлебываться и сыпать ошибками `Too many open files`. Это значит, что процесс уперся в лимит открытых файловых дескрипторов. В 2026 году ручное редактирование `limits.conf` — это долго.

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

# Берем PID процесса (например, 1234) и смотрим его мягкие и жесткие лимиты
cat /proc/1234/limits | grep "Max open files"

Как изменить лимит «на лету» без перезапуска всей системы (через systemd):
Если сервис управляется через systemd, создаем override-конфиг:

sudo systemctl edit nginx

Добавляем в открывшийся файл:

[Service]
LimitNOFILE=65535

Затем: `systemctl daemon-reload` и `systemctl restart nginx`.

Зачем это нужно: Современные приложения открывают сотни соединений и временных файлов.
Стандартный лимит в 1024 — это «бутылочное горлышко», которое ты теперь умеешь расширять за минуту.

#linux #systemd #performance #optimization #sysadmin #admin_future

🐧 Linux: systemd-run — запускаем тяжелые задачи в «песочнице» без лишних конфигов

Часто бывает нужно запустить скрипт или тяжелую задачу (например, пересборку логов или парсинг), но ты боишься, что она «отъест» все ресурсы у боевого веб-сервера. Создавать полноценный .service файл лень? Используй systemd-run.

Техническая суть:
Команда создает временный (transient) юнит и позволяет лимитировать ресурсы (CPU, RAM, I/O) «на лету» прямо из командной строки.

Команда для запуска с лимитом памяти в 500МБ:

# Запускаем скрипт в отдельном слайсе с жестким лимитом по памяти
sudo systemd-run --scope -p MemoryMax=500M -p CPUWeight=50 ./heavy-script.sh
# Посмотреть статус этого временного юнита
systemctl status run-*.scope

Зачем это нужно:
Это намного надежнее, чем просто nice или ionice.
Ты гарантируешь, что скрипт не уронит сервер по OOM (Out Of Memory), даже если в коде утечка.

#linux #systemd #optimization #performance #sysadmin #admin_future

🐧 Linux: Здоровье ваших NVMe — заглядываем в «мозги» диска через nvme-cli 🏎️

В 2026 году обычные SATA SSD в серверах — это уже почти легаси. Все сидят на NVMe, но многие по привычке проверяют их через smartctl. Однако для глубокой диагностики накопителей на шине PCIe есть родной и более мощный инструмент — nvme-cli.

Техническая суть:
Утилита позволяет не только смотреть SMART, но и управлять очередями, форматировать блоки под разный размер (LBA) и проверять реальный износ ячеек памяти (NAND Endurance).

Команды для проверки:

# Установка (если еще нет)
sudo apt install nvme-cli

# Вывести список всех NVMe дисков и их базовую инфу
sudo nvme list

# Показать детальный лог здоровья (критические предупреждения, температуру, износ)
sudo nvme smart-log /dev/nvme0n1

Зачем это нужно: В поле percentage_used вы увидите реальный износ в процентах. Если там >80% — пора планировать замену, не дожидаясь внезапного Read-Only режима.

#linux #nvme #storage #performance #troubleshooting #sysadmin #admin_future

🐧 Linux: Даем серверу «второе дыхание» через zRAM ⚡

Если у тебя есть виртуалка, которой периодически не хватает оперативной памяти, а классический Swap на диске безбожно тормозит систему и «выжигает» ресурс SSD — пора вспомнить про zRAM. В 2026-м это стандарт для многих дистрибутивов, но на серверах про него часто забывают.

Техническая суть:
zRAM создает сжатое блочное устройство прямо в оперативной памяти. Когда RAM начинает заканчиваться, ядро сжимает неиспользуемые страницы и складывает их в этот «быстрый swap», не обращаясь к медленному диску. Степень сжатия часто достигает 1:3.

Команды для настройки (Debian/Ubuntu):

# Устанавливаем утилиту
sudo apt install zram-tools

# Настройка в /etc/default/zramswap:
# ALGO=zstd (самый эффективный алгоритм сжатия в 2026-м)
# PERCENT=50 (выделяем до 50% RAM под сжатый пул)

# Перезапуск сервиса
sudo systemctl restart zramswap

# Проверка статуса
zramctl

Зачем это нужно: Ты получаешь «виртуальное» увеличение объема памяти почти без потери производительности. Идеально для контейнеров и небольших VPS.

#linux #optimization #zram #performance #sysadmin #admin_future

🛡️ Security: Рентген для ядра. eBPF вместо гадания на логах

В 2026-м копаться в `strace` или `tcpdump` на высоконагруженном сервере — это как пытаться замерить пульс у бегущего спринтера, вставляя ему палки в колеса. Сервис либо упадет от оверхеда, либо вы утонете в гигабайтах мусора. Когда база «лагает», а сеть «тупит», нам нужны точные ответы, а не догадки.

Техническая суть:
Используем eBPF (Extended Berkeley Packet Filter). Это технология, которая позволяет запускать микропрограммы прямо внутри ядра Linux без его пересборки или загрузки модулей.

Под капотом: Мы вешаем «хуки» на системные вызовы (kprobes) или функции в пользовательском пространстве (uprobes). eBPF-программа собирает статистику в реальном времени с нулевым влиянием на производительность. Вы видите всё: от задержек записи на диск конкретным процессом до того, какой именно микросервис рвет TCP-сессию.

Практика:
Используем bpftrace, чтобы мгновенно найти, кто «насилует» диск медленными запросами (более 10 мс):

# Запускаем однострочник, который строит гистограмму задержек I/O
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } 
             kretprobe:vfs_read /@start[tid]/ { 
                 $lat = (nsecs - @start[tid]) / 1000000; 
                 if ($lat > 10) { @[comm] = lhist($lat, 0, 100, 10); }
                 delete(@start[tid]); 
             }'

# На выходе получаем четкую картину:
# @[postgres]:
# [10, 20)      |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 152
# [20, 30)      |@@@@                                | 18
# [50, 60)      |@                                   | 2

Зачем это нужно:

Обнаруживаем «невидимые» проблемы: блокировки в ядре, микро-всплески трафика или утечки дескрипторов. В эпоху Cloud-Native и сложных распределенных систем это единственный способ не сойти с ума при поиске иголки в стоге сена.

#security #ebpf #linux #performance #monitoring #admin_future

🐧 Linux: Быстрее тени. Почему find уходит на пенсию в 2026-м

Привет, коллеги! Понедельник, 16 марта, начинаем неделю с очистки кармы и ускорения пальцев. Если ты до сих пор ждешь по три минуты, пока find / прочешет твои терабайтные NVMe-массивы на ARM-кластере, то у меня для тебя плохие новости: твое время стоит дороже, чем циклы процессора. В 2026-м, когда плотность данных зашкаливает, админ должен находить иголку в стоге сена за миллисекунды.

Техническая суть:

Мы переходим на связку fd и ripgrep (rg).
Под капотом: В отличие от классического find, который последовательно обходит дерево ФС, fd использует многопоточность и по умолчанию игнорирует скрытые папки и .gitignore. А ripgrep — это grep на стероидах, написанный на Rust, который пролетает сквозь бинарные логи и огромные конфиги, используя SIMD-инструкции процессоров ARM и x86. Это не просто «быстрее», это другой уровень отзывчивости системы.

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

# 1. Найти все файлы .conf в /etc, измененные за последние 10 минут
# Быстрее, чем ты успеешь моргнуть
fd -e conf -t f --changed-within 10m . /etc

# 2. Найти строку "error" во всех логах, игнорируя бинарный мусор
# -z позволяет искать даже в сжатых .gz архивах (must have 2026)
rg -z "critical_error" /var/log/app/

# 3. Киллер-фича: интерактивный поиск через fzf
# Интегрируем fd в fzf для мгновенного перехода к файлу
alias pf="fd -t f | fzf --preview 'bat --color=always {}' | xargs -r vim"

Зачем это нужно:

Для бизнеса это сокращение времени простоя (MTTR). Пока твой коллега смотрит на мигающий курсор find, ты уже нашел проблемную строчку в конфиге, поправил её и ушел обсуждать план миграции на новый сегмент сети.

#linux #performance #rust #cli #sysadmin #admin_future

🪟 Windows: Кто съел мою память? (PowerShell)

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

PowerShell позволяет сделать это одной строкой, отсортировав процессы по реальному потреблению (WorkingSet).

Скрипт для поиска виновных:

# Топ-10 процессов по потреблению памяти в Мб
Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 10 Name, @{Name='RAM_MB'; Expression={[math]::round($_.WorkingSet / 1mb, 2)}} | Format-Table -AutoSize

Зачем это нужно:
Для оперативного реагирования. Ты сразу видишь, что это: утечка в браузере, разросшаяся база или «зависшее» приложение. Зная имя процесса, его можно тут же перезапустить или изучить подробнее, не тратя время на графику.

#windows #powershell #performance #monitoring #sysadmin #admin_future

🐧 Linux: bpftrace — Твой рентген для ядра

Привет, коллеги! Если ты когда-нибудь бился над проблемой, которую не видят логи и не ловит strace, значит, пришло время заглянуть глубже. Инструмент bpftrace позволяет писать однострочники, которые вытаскивают данные прямо из функций ядра в реальном времени.

1. Ноль оверхеда: В отличие от тяжелых отладчиков, bpftrace практически не грузит систему. Можно безопасно запускать на боевом сервере под нагрузкой.
2. Универсальность: Хочешь увидеть, какие файлы открывает конкретный процесс? Или почему сетевой пакет дропается на уровне стека TCP? Легко.

Практика (однострочники на вес золота):

# Показать распределение времени выполнения системного вызова read (гистограмма)
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; } tracepoint:syscalls:sys_exit_read /@start[tid]/ { @runtime = hist(nsecs - @start[tid]); delete(@start[tid]); }'

# Кто и какие файлы открывает прямо сейчас (в реальном времени)
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

Зачем это нужно:

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

#linux #ebpf #bpftrace #performance #troubleshooting #admin_future

🪟 Windows: Dev Drive — Как выжать максимум из файловой системы

Коллеги, если вы админите рабочие станции разработчиков или серверы с тяжелыми дисковыми операциями (сборка кода, работа с тысячами мелких файлов, Docker-контейнеры), стандартный NTFS может стать бутылочным горлышком. В 2026 году для этих задач в Windows есть Dev Drive на базе ReFS (Resilient File System).

1. Copy-on-Write (CoW): Файловая система не копирует данные физически, пока они не изменены. Это делает копирование проектов мгновенным.
2. Режим доверия (Trust Mode): Антивирус (Microsoft Defender) переходит в асинхронный режим сканирования для таких дисков. Это дает прирост скорости до 30% на операциях чтения/записи.

Как настроить (PowerShell):

# Создаем VHDX диск для Dev Drive (например, на 50Гб)
New-VHD -Path "C:\DevStorage.vhdx" -SizeBytes 50GB -Dynamic

# Инициализируем его как Dev Drive
Initialize-Disk -Number (Get-VHD -Path "C:\DevStorage.vhdx").DiskNumber
New-Partition -DiskNumber (Get-VHD -Path "C:\DevStorage.vhdx").DiskNumber -UseMaximumSize -DriveLetter V | Format-Volume -FileSystem ReFS -DevDrive

Зачем это нужно:

Чтобы пользователи не жаловались на тормоза при работе с IDE или тяжелыми скриптами. Dev Drive — это официальный способ Microsoft признать, что NTFS не идеален для всего, и дать нам инструмент для специфических нагрузок.

#windows #refs #devdrive #performance #sysadmin #admin_future

🐧 Linux: eBPF-трейсинг вместо strace — хирургия без анестезии

Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.

В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.

Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:

# Все открываемые файлы процессом nginx в реальном времени
bpftrace -e '
  tracepoint:syscalls:sys_enter_openat
  /comm == "nginx"/
  {
    printf("%s -> %s\n", comm, str(args->filename));
  }
'

# Латентность read() по перцентилям — находим I/O-узкое место
bpftrace -e '
  tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
  tracepoint:syscalls:sys_exit_read  /@start[tid]/
  {
    @lat = hist(nsecs - @start[tid]);
    delete(@start[tid]);
  }
'

Зачем это нужно:
Бизнес платит за uptime, а не за твои ночные медитации над strace-логом. bpftrace работает в ядре, не требует перезапуска процессов, не ломает продакшн и даёт гистограммы латентности за секунды. Когда Роман спрашивает "в чём причина деградации?", у тебя есть ответ с цифрами, а не с "ну, мы смотрим".

Итог: strace незаменим для разработки. Но в живом продакшне — только eBPF. Это разница между вскрытием и МРТ.

#linux #ebpf #bpftrace #performance #sysadmin #admin_future

🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры

Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.

Почему это важно для нас, а не только для датацентров?

Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.

Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.

Практика — запускаем готовый планировщик на продакшн-хосте:

# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds

# Ubuntu 26.04 (из репозитория):
apt install scx-scheds

# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS

# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &

# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state     # -> enabled
cat /sys/kernel/sched_ext/root/ops  # -> lavd

# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2

# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
  {
    "name": "critical",
    "matches": [["CgroupPrefix", "system.slice/nginx"]],
    "kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
  },
  {
    "name": "background",
    "matches": [["CgroupPrefix", ""]],
    "kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
  }
]
EOF

# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма

Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.

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

#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future

🪟 Windows: Создатель диспетчера задач признался — CPU% всегда было «некрологом недавнего прошлого»

Коллеги, на этой неделе Дэйв Пламмер — инженер Microsoft, написавший оригинальный Task Manager — объяснил то, о чём многие из нас догадывались, но не формулировали чётко. Цифра загрузки CPU в диспетчере задач никогда не была «сейчас».

«Число CPU в диспетчере задач — это движущийся некролог недавнего прошлого», объяснил Пламмер. «Не то, что происходило в момент, когда ваши глаза остановились на строке».

Как это работало изнутри:

Windows не хранит никакого магического значения загрузки CPU, готового к считыванию. Вместо этого Task Manager работал по таймеру: при каждом срабатывании запрашивал у ядра накопленное процессорное время каждого процесса и сравнивал с предыдущим снимком.

Это решение умное и дешёвое — но у него есть фундаментальное ограничение на современном железе:

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

Процессоры с Turbo Boost, тепловым троттлингом и глубокими состояниями простоя разорвали связь между «занятым временем» и «реально выполненной работой». 73% в диспетчере может означать совершенно разный объём вычислений в зависимости от того, на какой частоте работал CPU в этот момент.

Что из этого следует практически — чем смотреть вместо Task Manager:

# Реальная утилизация CPU с учётом частоты (не просто время)
# Performance Monitor — метрика "Processor Information\% Processor Utility"
# Именно её Microsoft начала использовать по умолчанию с июля 2025

# Через PowerShell — утилизация с учётом частоты:
Get-Counter '\Processor Information(_Total)\% Processor Utility' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# Сравниваем с классическим % (время):
Get-Counter '\Processor(_Total)\% Processor Time' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# На нагруженном сервере разница между двумя метриками
# может достигать 30-40% — именно столько "врал" старый Task Manager

# Для глубокого анализа — PAL (Performance Analysis of Logs)
# или просто смотрим в Windows Admin Center -> Performance Monitor

Кстати, Microsoft уже исправила это: с июля 2025 года Task Manager использует стандартную метрику утилизации для отображения нагрузки CPU на всех вкладках — Processes, Performance и Users — приводя её в соответствие с отраслевыми стандартами и сторонними инструментами.

Зачем это знать:
Если вы делаете выводы о нагрузке на сервер по старому диспетчеру задач — вы смотрите на интерпретацию прошлого через упрощённую формулу. Для реального capacity planning используй Performance Monitor, метрику % Processor Utility и нормальный мониторинг с историей.

Пламмер точно сформулировал суть: «Инструмент мониторинга, который требует семинара по инженерии перед завтраком, уже проиграл». Task Manager и не должен был быть точным осциллографом. Он должен был быть быстрым и понятным — и он им был. Просто не путай его с инструментом точного анализа.

Итог: то, что ты видишь в Task Manager — это не ложь. Это упрощение. Разница принципиальная, и понимать её важно, особенно когда объясняешь бизнесу почему 40% в мониторинге это не то же самое, что 40% реальной нагрузки.

#windows #performance #troubleshooting #sysadmin #admin_future

🪟 Windows: Native NVMe в WS2025 — +80% IOPS, и это ещё не включено по умолчанию

Коллеги, фича которая доступна с октября 2025-го, но большинство администраторов её не включили — потому что она opt-in и спрятана за реестром.

Всё Windows Server до 2025 включительно общался с NVMe-дисками через SCSI-эмуляцию. Команды NVMe переводились в SCSI и обратно — лишний слой абстракции, shared locks в kernel I/O path, лишние CPU-циклы. Включение native NVMe даёт до 80% выше IOPS и до 45% ниже CPU utilization под высокой I/O нагрузкой.

Это особенно важно для Storage Spaces Direct, SQL Server и любых disk-intensive workloads.

# Проверяем установлено ли обновление KB5066835 (октябрь 2025) или новее
Get-HotFix | Where-Object {$_.InstalledOn -gt "2025-10-01"} |
  Select-Object HotFixID, InstalledOn |
  Sort-Object InstalledOn -Descending | Select-Object -First 5

# Включаем Native NVMe через реестр (требует перезагрузки):
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" `
  /v 1176759950 /t REG_DWORD /d 1 /f

# Проверяем что драйвер переключился
# После перезагрузки в Device Manager NVMe диски должны показывать
# "NVM Express Controller" вместо "Standard SATA AHCI Controller"
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive"} |
  Select-Object FriendlyName, Status

# Бенчмарк до и после — замеряем IOPS с DiskSpd:
# (скачать с https://github.com/microsoft/diskspd)
.\diskspd.exe -b4K -d30 -o32 -t8 -r -w0 -L C:\testfile.dat

# Для S2D кластеров — проверяем здоровье после включения
Get-StoragePool | Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, IOPS

Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.

Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.

#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future

🐧 Linux: Хватит терпеть зависания при OOM. Включаем PSI и systemd-oomd

Коллеги, добрый понедельник. Знакомая ситуация: на сервере потекла память, своп забился, load average улетел в космос, и вы даже по SSH зайти не можете. Классический OOM Killer в ядре срабатывает слишком поздно, когда система уже фактически в коме.

В 2026 году мы решаем это изящнее. Мы используем PSI (Pressure Stall Information) вместе с systemd-oomd. Этот демон убивает прожорливые cgroups ДО того, как операционная система намертво повиснет.

Скрипт для проверки и активации:

# Проверяем, включен ли PSI в ядре (вывод не должен быть пустым):
cat /proc/pressure/memory

# Если включен, активируем службу systemd-oomd:
systemctl enable --now systemd-oomd

# Смотрим статус и кто сейчас под угрозой:
oomctl status

Зачем это нужно:
Сервер должен оставаться управляемым при любых утечках памяти. Лучше пусть упадет один проблемный контейнер или веб-сервис, чем вся нода уйдет в hard reset по питанию, утащив за собой соседние процессы.

#linux #systemd #oom #performance #sysadmin #admin_future