🏗 Docker: Multistage Build — худеем в 10 раз

Типичная ошибка новичка: в Docker-образе лежат исходники, компиляторы (GCC, Go), кэши и сам бинарник. Образ весит 800 МБ. Архитектор использует Multistage Build.

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

Пример (Go/C++/Rust):

# Этап 1: Сборка (Builder)
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp main.go

# Этап 2: Финал (Production)
# Берем Alpine (5 МБ) или Distroless
FROM alpine:latest  
WORKDIR /root/
# Копируем ТОЛЬКО бинарник из первого этапа
COPY --from=builder /app/myapp .

CMD ["./myapp"]

Профит:

1. Размер: Было 800 МБ → Стало 20 МБ.

2. Безопасность: В проде нет компиляторов и исходного кода — хакеру сложнее развернуться.

3. Скорость: Быстрее пушится в Registry и скачивается на сервер.

Если ваши образы весят гигабайты — сегодня самое время их переписать.

#docker #devops #optimization #bestpractice #architecture

🏎 TCP BBR: Ускоряем интернет одной строкой

Вы знали, что Linux по умолчанию использует алгоритм контроля перегрузки сети CUBIC, разработанный в 2000-х? Он считает, что если пакет потерялся — канал забит, и резко снижает скорость. Но в 2025 году потеря пакетов не всегда означает перегрузку (привет, Wi-Fi и LTE).

Google придумал BBR (Bottleneck Bandwidth and RTT). Он не смотрит на потери пакетов. Он строит модель пропускной способности канала.

Результат: На серверах с высоким пингом или нестабильным каналом (VPN, трансграничный трафик) скорость скачивания вырастает в разы.

Как включить (Ядро 4.9+):

Проверяем доступность:

modprobe tcp_bbr

Включаем:

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

Проверяем:

sysctl net.ipv4.tcp_congestion_control
# Должно быть: bbr

Попробуйте включить это на своем VPN-сервере или прокси. Разница вас шокирует.

#linux #network #performance #bbr #kernel #optimization

🚀 PowerShell: Ускоряем чтение логов в 100 раз (XPath)

Задача: Найти в Event Log событие блокировки пользователя (ID 4740) за последний час. Обычный админ пишет так:

# 🐢 Медленно (Client-side filtering)
Get-WinEvent -LogName Security | 
Where-Object { $_.Id -eq 4740 -and $_.TimeCreated -gt (Get-Date).AddHours(-1) }

Проблема: PowerShell сначала выкачивает ВСЕ миллион событий из журнала к себе в память, и только потом отсеивает нужные. Это вешает сервер.

Сеньор использует Server-side filtering (XPath):

# 🐇 Быстро (Фильтрация на уровне движка Windows)
$XML = "*[System[(EventID=4740) and TimeCreated[timediff(@SystemTime) <= 3600000]]]"
Get-WinEvent -LogName Security -FilterXPath $XML

Результат: Вместо 2 минут команда отрабатывает за 0.3 секунды. Фильтруйте данные на источнике, а не в пайплайне.

#powershell #windows #performance #scripting #optimization #xml

🐧 Linux: Почему твой сервер тормозит при свободной памяти? (swappiness)

Вы смотрите в free -h : свободной RAM еще 2 ГБ, но система уже начала сбрасывать данные в Swap (на диск). Из-за этого всё тормозит. Виноват параметр Swappiness. По умолчанию он равен 60 (из 100 ). Для десктопа это ок, для сервера баз данных — это катастрофа.

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

sysctl vm.swappiness
# Вывод: 60

Как исправить (Best Practice для серверов): Снижаем до 10 . Это скажет ядру: "Используй Swap только тогда, когда RAM действительно кончается".

1. На лету (до перезагрузки):

sysctl vm.swappiness=10

2. Навсегда: Добавьте в файл /etc/sysctl.conf:

vm.swappiness=10

Ваша БД скажет вам спасибо.

#linux #kernel #performance #optimization #swap #memory

🪟 Windows: Отключаем "Search Highlights" и лишний мусор через реестр 🧹

Заметили, как поиск в Windows 11/Server 2025 стал забиваться картинками, новостями и рекламой ("Search Highlights")? Это не только бесит, но и жрет ресурсы процесса SearchHost.exe. Для админской машины это лишний мусор.

Убираем всё лишнее одной командой в PowerShell:

# Отключаем интернет-результаты в поиске и "интересные факты"
$path = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Search"
Set-ItemProperty -Path $path -Name "BingSearchEnabled" -Value 0
Set-ItemProperty -Path $path -Name "SearchboxTaskbarMode" -Value 0

# Отключаем Search Highlights (те самые картинки в поиске)
$path2 = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Windows Search"
if (!(Test-Path $path2)) { New-Item $path2 -Force }
Set-ItemProperty -Path $path2 -Name "EnableAllowedDaysCondition" -Value 0

Результат: Чистый, быстрый поиск только по локальным файлам и приложениям. Минимум сетевого трафика в сторону Bing. ✨

#windows #registry #powershell #optimization #sysadmin #clean #windows11

🐧 Linux: Сетевой тюнинг — боремся с очередями (Softirq) 🚄

Если у тебя мощный сервер, гигабитный канал, но сетевая подсистема тормозит, а одно из ядер CPU загружено на 100% (в графе %si в top), ты столкнулся с проблемой обработки прерываний сетевой карты. В 2026 году при 10Gbps+ сетях это база.

Решение: Раскидываем обработку пакетов по всем ядрам CPU с помощью RSS (Receive Side Scaling) и RPS (Receive Packet Steering).

Как включить маски для очередей (пример для eth0 и 8 ядер):

# Разрешаем обработку пакетов на всех 8 ядрах (маска f = 11111111)
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

Почему это важно: Это позволяет системе обрабатывать входящий трафик параллельно на всех ядрах, а не душить одно ядро софт-прерываниями. Пинг падает, пропускная способность растет. 🏎️

#linux #networking #performance #sysadmin #kernel #optimization #10gbps

🐧 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

🚀 DevOps: Очистка старых Docker-образов по расписанию 🧹

Если твой сервер внезапно перестал отвечать, проверь место на диске. Часто причиной становятся гигабайты «висячих» (dangling) слоев и старых образов Docker, которые копятся после каждого деплоя. В 2026-м ручная чистка — это моветон.

Техническое решение:

Используем встроенную систему очистки Docker с фильтрами, чтобы не снести лишнее.

Команда для тотальной, но безопасной чистки:

# Удалить все неиспользуемые контейнеры, сети и образы (dangling)
docker system prune -f

# Удалить вообще все образы, которые не используются ни одним запущенным контейнером
docker image prune -a --force --filter "until=168h"

Фильтр until=168h удалит только те образы, которые старше недели, оставив свежие билды для быстрого отката (rollback).

#docker #devops #optimization #linux #cleanup #sysadmin #automation #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: Даем серверу «второе дыхание» через 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

🐧 Linux: Диета для ARM. Btrfs и прозрачное сжатие под давлением санкций

Привет, коллеги! В 2026 году, когда объемы логов растут быстрее, чем бюджеты на новые NVMe-накопители, а ARM-серверы стали стандартом в наших ДЦ, умение экономить каждый гигабайт — это не жадность, а профессиональное выживание. Если вы до сих пор используете ext4 на системных разделах, вы просто добровольно сжигаете ресурс ячеек памяти и деньги компании.

Техническая суть:
Мы переходим на Btrfs с использованием алгоритма ZSTD. В отличие от старого доброго Gzip, ZSTD нативно поддерживается ядром и умеет в «умное» сжатие: если данные не сжимаются (например, уже зашифрованные бинарники), драйвер просто перестает тратить циклы CPU.

Под капотом: Используем механизм Copy-on-Write (CoW). При записи блок данных сначала сжимается в памяти, а затем атомарно пишется на диск. Это не только экономит до 40-60% места на типичных текстовых логах и конфигах, но и продлевает жизнь SSD, так как физических операций записи становится меньше.

Практика:

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

# 1. Добавляем опции сжатия в fstab (уровень 3 — золотая середина для ARM)
# UUID=...  /var/log  btrfs  defaults,compress-force=zstd:3,noatime  0  0

# 2. Если раздел уже смонтирован, применяем на лету к существующим данным
btrfs filesystem defragment -r -czstd /var/log

# 3. Смотрим реальное потребление (df тут бессилен)
# Утилита compsize показывает магию чисел
compsize /var/log

# Вывод будет примерно такой:
# Processed 12405 files, 204856 blocks.
# Raw size: 12.4G
# Compressed size: 4.1G (33.06%)

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

Экономия дискового пространства в 3 раза без потери производительности (а на медленных дисках — даже с приростом, так как узкое место — шина данных, а не CPU). Плюс, мгновенные снапшоты позволяют откатить неудачное обновление системы за секунды.

#linux #btrfs #arm #optimization #storage #admin_future