Системное администрирование *

Compact OS в Windows: как освободить место без удаления файлов

Если системный SSD почти заполнен, не обязательно сразу удалять программы, игры или личные данные. В Windows есть встроенный механизм Compact OS, который сжимает системные файлы и помогает освободить несколько гигабайт.

Функция появилась в Windows 10 и поддерживается в Windows 11. Отдельного переключателя в настройках нет: управлять Compact OS нужно через команду Compact.exe.

Как работает Compact OS

Windows хранит часть системных файлов в сжатом виде, а при обращении распаковывает их на лету. Компоненты ОС при этом не удаляются и не отключаются.

Технология поддерживается на компьютерах с UEFI и классическим BIOS. Windows Update также умеет обслуживать сжатую установку: заменять и удалять необходимые файлы без постоянного увеличения её размера.

Главный компромисс — дополнительная нагрузка на процессор. Сжатые данные приходится распаковывать, поэтому на современном ПК влияние обычно минимально, а на старом или маломощном компьютере оно может быть заметнее.

Как проверить и включить функцию

Откройте командную строку от имени администратора и выполните:

Compact.exe /CompactOS:query

Команда покажет, используется ли Compact OS сейчас.

Для включения сжатия:

Compact.exe /CompactOS:always

Чтобы вернуть обычное состояние:

Compact.exe /CompactOS:never

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

Сколько места можно освободить

Точный результат зависит от версии Windows и конфигурации системы. В документации Microsoft для 64-разрядной Windows 10 версии 1607 приведён пример установки объёмом 15,06 ГБ. После применения Compact OS размер уменьшался до 11,3 ГБ — экономия составляла более 3,7 ГБ.

При дополнительном single-instancing объём снижался до 10,09 ГБ, а суммарная экономия превышала 4,75 ГБ.

Это ориентиры, а не гарантия для любого компьютера. На Windows 11 результат может быть другим.

Когда Compact OS имеет смысл

Функция пригодится, если:

• системный SSD небольшой;

• раздел почти заполнен;

• удалять приложения и пользовательские файлы не хочется;

• нужно освободить несколько гигабайт именно за счёт компонентов Windows.

На компьютере с SSD на 1–2 ТБ польза обычно ограничена: несколько гигабайт редко решают проблему нехватки места.

Важно помнить, что Compact OS сжимает только системные файлы. Место также занимают:

• Pagefile.sys и Hiberfil.sys;

• обновления Windows;

• точки восстановления;

• журналы и кэши;

• языковые пакеты;

• компоненты Windows;

• приложения и временные файлы.

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

Итог

Compact OS — штатный способ уменьшить размер Windows без удаления системных компонентов. Он особенно полезен на устройствах с небольшими накопителями, но не является универсальным решением проблемы нехватки места.

Если свободного пространства критически мало, можно начать с проверки:

Compact.exe /CompactOS:query

А затем, при необходимости, включить режим:

Compact.exe /CompactOS:always

Подробные ограничения и таблицы с результатами измерений опубликованы в документации Microsoft.

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Разработчик Гийом Мейер представил открытый инструмент Watermarks Remover, который помогает удалять невидимые водяные знаки из текста и изображений от ИИ-систем. «Если исследователь использует ИИ, чтобы изменить одну строку в конце десятистраничной работы, вся публикация потенциально может получить отметку. Это может превратиться в кошмар для доверия», — пояснил автор решения.

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

Как выстроить аварийное восстановление в гибриде и мультиоблаке. Вебинар Хайстекс

Привет, Хабр! Гибридная инфраструктура дает гибкость в штатном режиме, но превращается в хаос при серьезном сбое. Когда в едином контуре связаны локальные серверы, облака и унаследованный сегмент, обычный бэкап перестает гарантировать понятные сроки восстановления.

26 августа в 11:00 (МСК) команда Хайстекс проведет вебинар. Эксперты разберут, почему в гибридной инфраструктуре недостаточно просто настроить бэкап, и покажут на практике, как в Хайстекс Акура выстраивать сценарии восстановления для разрозненных платформ и площадок.

Что обсудим:

• где чаще всего ломаются бэкап и репликация – сеть, окна копирования, ручные операции, ограничения площадок;

• когда достаточно резервной копии, а когда уже нужен полноценный DR-сценарий;

• почему заявленные RTO/RPO без тестовых восстановлений мало что значат;

• как организовать восстановление между разными площадками и платформами.

После основной части спикеры проведут Q&A-сессию: можно принести архитектуру своего контура в чат и получить разбор от инженеров Хайстекс.

Зарегистрироваться на вебинар

«Наташа, мы всё уронили»: восстанавливаем виртуальную инфраструктуру с zVirt DR

Привет! 27 августа в 11:00 приглашаем на вебинар Orion soft по аварийному восстановлению инфрасттруктуры с помощью механизма Disaster Recovery в zVirt.

Отказ оборудования, электропитания или целой площадки может привести к длительной недоступности критически важных ИТ-сервисов. Ручное восстановление усложняет ситуацию: требует времени и не гарантирует правильную последовательность запуска систем.

На вебинаре разберем, как с помощью DR в расширенной версии zVirt организовать аварийное восстановление виртуальной инфраструктуры на резервной площадке. Покажем настройку программной и аппаратной репликации, подготовку плана аварийного восстановления и его запуск при недоступности основной площадки.

Что в программе?

- Подготовка инфраструктуры и развертывание компонентов DR

- Настройка программной репликации средствами zVirt DR и аппаратной репликации на базе СХД YADRO TATLIN.UNIFIED

- Развертывание и подключение виртуальных машин к контуру защиты

- Подготовка плана аварийного восстановления

- Live-demo: моделирование недоступности основной площадки и восстановления ВМ на резервной инфраструктуре 

Участники увидят практический сценарий работы с DR в платформе виртуализации zVirt — от настройки репликации до аварийного восстановления — и узнают, как заранее подготовленный DR-план помогает сократить число ручных операций при переключении виртуальной инфраструктуры на резервную площадку.

Присоединяйтесь! Регистрация открыта по ссылке.

Как не отставать от технологий, не изучая всё подряд: 14 открытых уроков на этой неделе

Когда в работе появляется новая задача, часто выясняется, что привычных инструментов или знаний уже недостаточно. Но разбираться во всём подряд долго — важнее быстро найти нужный подход, проверить его на практике и понять, как применить в своём проекте.

На этой неделе на открытых уроках OTUS разбираем задачи из разработки, инфраструктуры, AI и ML, аналитики, тестирования и других направлений — чтобы увереннее решать рабочие задачи и двигаться дальше в профессии.

Выбирайте направление и подключайтесь.

AI и ML

• 24 августа, 20:00. «Современные модели прогнозирования — TimesNet, TimeGPT и новое поколение моделей временных рядов»

• 31 августа, 20:00. «Построение программ без кода: создание умного помощника и автоматизаций в n8n»

Архитектура и системный анализ

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне»

• 25 августа, 20:00. «Создаём ИИ‑ассистента для системного аналитика за 1 час»

Разработка

• 24 августа, 20:00. «От обычного JavaScript к профессиональному TypeScript»

• 25 августа, 20:00. «С без компромиссов: обработка ошибок и полиморфизм»

• 26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients»

• 26 августа, 20:00. «Vue умеет проще: пишем игру, пока React грузит стейт»

Инфраструктура и сети

• 24 августа, 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает»

• 26 августа, 19:00. «Nftables без потери SSH: безопасно настраиваем firewall на удалённом сервере»

Embedded‑разработка

• 24 августа, 20:00. «АЦП в ESP32. Оцифровать сигнал, а не „погоду на Марсе“: нюансы, особенности, повышение точности»

Тестирование и GameDev

• 24 августа, 20:00. «Тестирование игровых уровней: как находить ошибки, которые влияют на игровой опыт»

Управление и поддержка

• 25 августа, 20:00. «Postmortem: как провести разбор инцидента и избежать конфликтов с коллегами»

1С

• 27 августа, 20:00. «Технический проект 1С с ИИ: от структуры до ревью»

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

Больше открытых вебинаров и практических занятий — в дайджесте.

Открытый проект ffmpeg webCLI (веб-версия) для работы с видео позволяет выполнять больше 20 различных манипуляций за один клик с любыми роликами: менять размер, вырезать аудио, сжимать, конвертировать в gif или другие форматы, ускорять, миксовать, стираем вотермарки, добавлять блюр, зацикливать.

12 уроков по системному администрированию: от nftables до RAID

Пока всё работает, инфраструктура редко требует пристального внимания. Настоящая проверка начинается в момент сбоя: L2-петля кладёт сеть, изменение firewall грозит потерей SSH‑доступа, место на диске заканчивается не вовремя, а по логам сложно понять, где именно возникла проблема.

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

Собрали бесплатные открытые уроки, на которых можно точечно разобрать эти темы с практикующими специалистами, задать вопросы и заодно посмотреть, как устроено обучение в OTUS.

Linux: безопасность, сервисы и хранение

• 20 августа, 20:00. «Средства защиты в ядре Linux». Записаться

• 26 августа, 19:00. «Nftables без потери SSH: безопасно настраиваем firewall на удаленном сервере». Записаться

• 3 сентября, 19:00. «Первый веб‑сервер на Linux: Nginx, Apache и проверка доступности». Записаться

• 8 сентября, 20:00. «LVM без простоя: расширение тома, перенос данных и аварийный откат через snapshot». Записаться

• 17 сентября, 20:00. «Где Linux хранит настройки и логи: разбираем файловую структуру на практике». Записаться

• 21 сентября, 20:00. «Типовые задачи с RAID‑массивами: создание, эксплуатация, перенос данных и восстановление». Записаться

Сети

• 24 августа, 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться

Windows‑инфраструктура

• 7 сентября, 20:00. «Linux для Windows администратора за 60 минут». Записаться

• 22 сентября, 20:00. «Топ GPO, которые помогут тебе». Записаться

Автоматизация, диагностика и высокая доступность

• 10 сентября, 20:00. «Настройка GitLab Runners». Записаться

• 23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

ЧТО ПОЧИТАТЬ ПО ТЕМЕ:

• «Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec» — практический разбор защиты сервера: работа с логами, блокировка нежелательного трафика и настройка nftables. Читать на Хабре

• «Пять проблем Bash, которые ломают скрипты в самый неудачный момент» — о типичных ошибках в Bash‑скриптах, которые могут проявиться уже при эксплуатации и автоматизации системных задач. Читать на Хабре

• «Ищем петли и шторма в L2 сети» — как диагностировать L2-петли, broadcast‑штормы и MAC flapping, найти проблемный порт и восстановить работу сети. Читать на Хабре

Больше открытых уроков по инфраструктуре и смежным направлениям собрали в дайджесте.

NUMA и топология CCD Ryzen 9 9950X: как размещение vCPU влияет на задержки.

NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.

Как определить, какие vCPU находятся на одном CCD?

Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.

lscpu -e=CPU,CORE,SOCKET,NODE,CACHE
grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list

Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.

От физических ядер к vCPU, emulatorpin и vNUMA

vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.

virsh vcpupin vm-latency
virsh emulatorpin vm-latency
virsh numatune vm-latency

Компактный CCD, разнесённые CCD и свободное планирование

Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.

Насколько размещение между CCD увеличивает задержку?

Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.

Как не принять boost, нагрев или соседнюю VM за эффект CCD

Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.

Связь задержки с миграциями, кэш-промахами и удалённой памятью

Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.

perf stat -e context-switches,cpu-migrations,cache-misses \
   -- ./test
numastat -p "$(pgrep -fo 'guest=vm-latency')"

Когда пиннинг vCPU улучшает p99?

1. Рабочие потоки часто обращаются к общим данным.

2. Без pinning они мигрируют между группами L3.

3. p99 снижается без потери throughput и роста %st.

Где компактность помогает, а где ограничивает параллелизм

Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.

Как превратить топологию 9950X в правило эксплуатации

До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.

<vcpu>2</vcpu>
<iothreads>1</iothreads>
<cputune>
 <vcpupin vcpu='0' cpuset='0'/>
 <vcpupin vcpu='1' cpuset='1'/>
 <emulatorpin cpuset='2'/>
 <iothreadpin iothread='1' cpuset='3'/>
</cputune>
<numatune><memory mode='strict' nodeset='0'/></numatune>

Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.

🎓 Linux со школьной скамьи

Ровно через две недели — 1 сентября. Для тысяч школьников этот звонок станет ещё и первым входом в мир Linux. И это отличный повод поговорить о том, как отечественные ОС входят в образование.

Помните, как в первый раз ставили программу на Linux? И это заняло полдня. Многие ещё тогда прочувствовали стресс перехода с привычных Windows или macOS. Даже когда новая система решает все привычные задачи, первое время она кажется чужой. И этот дискомфорт легко принять за недостаток самой платформы.

Сейчас отечественные ОС всё чаще появляются в школах и вузах. Но если ребёнок с первых уроков информатики работает в Linux, для него это не «альтернативная ОС» и не вынужденная замена. Это обычная среда, в которой он учится, пишет код, готовит презентации и монтирует видео.

Школьный Linux даёт два плюса: дети привыкают к системе без стресса, а компании получают готовых специалистов.

Уже сейчас бизнесу нужны не только сами операционные системы, но и люди, которые умеют с ними работать без страха и раздражения. Таких специалистов проще вырастить со школьной скамьи, чем переучивать.

Кто-то из сегодняшних школьников станет разработчиком, специалистом по ИБ или Linux-администратором. Командная строка, права доступа и установка пакетов уже не будут казаться ему чем-то чужим.

Из того, что уже работает в школах, — РЕД ОС Образовательная редакция и «Альт Образование».

РЕД — не урезанная система «только для уроков»: на ней можно и роботов собирать, и 3D-модели рисовать, и код писать. Плюс есть лёгкий режим для слабых ПК и серверная часть для дневников и учёта.

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

Конечно, одной ОС тут мало — нужны учителя, методики, инфраструктура. Но хорошее начало положено.

Получается последовательность длиной в целое поколение:

школьный компьютер → колледж или вуз → первая работа → ИТ-инфраструктура.

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

Как поменять firewall на удалённом сервере и не отрезать себе SSH

Настраивать firewall по SSH всегда немного тревожнее, чем кажется в документации. Одно неудачное правило — и вместо аккуратно закрытых портов получаем сервер, до которого теперь нужно добираться через консоль провайдера или просить кого-то вернуть доступ.

26 августа в 19:00 на бесплатном демо-уроке будем разбираться, как работать с nftables на удалённом Linux-сервере так, чтобы изменения можно было вносить контролируемо и без неприятных сюрпризов. Заодно станет понятнее, чем nftables отличается от привычного iptables и что учитывать при постепенном переходе между ними.

Урок проведёт Николай Лавлинский — преподаватель-практик курса «Администратор Linux. Продвинутый уровень». Формат рассчитан на разбор реальной админской задачи, где цена ошибки вполне ощутима.

Больше бесплатных уроков на август собрали в дайджесте — там можно быстро посмотреть темы и выбрать нужную сейчас.

В команде VideoLan (разработчики открытого проекта VLC Media Player) предупредили пользователей о регрессии, проявляющейся в ОС Windows 11. Симптомы проблемы: 30-секундное зависание перед началом воспроизведения некоторых видов файлов, включая MP3. Регрессия объясняется ошибкой, допущенной в приложении Microsoft Defender и проявляющейся после установки последнего обновления Windows 11. Из‑за ошибки каталог с кэшем плагинов VLC был помещён Microsoft Defender в карантин. Для ошибки рекомендуется переустановить VLC, очистить или перегенерировать кэш плагинов командой «vlc ‑-reset‑plugins‑cache». Также проблема может быть решена через добавление vlc.exe в список исключений Microsoft Defender.

Подборка вебинаров на август

В августе разберем, как быть во всеоружии на случай отказа ЦОД, выбрать инфраструктуру для ИИ-проектов и упростить работу со Spark-задачами. Регистрируйтесь, чтобы не пропустить.

Отказ ЦОД: выстраиваем защиту с DRaaS и BaaS
Разберем, как подготовиться к отказу дата-центра и выстроить защиту инфраструктуры с помощью Evolution Disaster Recovery и Evolution Agent Backup. Обсудим, чем отличаются DRaaS, BaaS, репликация и аварийное восстановление, а также как выбрать решение с учетом требований к непрерывности, скорости восстановления и безопасности.
🧑‍💻 Для кого: ИТ-директора, руководители инфраструктуры, системные администраторы и специалисты по информационной безопасности.
📅 Когда: 18 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ИИ-проекты: когда и как переходить от API к Bare Metal
Расскажем, когда API для инференса перестает отвечать требованиям проекта и почему стоит переходить на выделенную инфраструктуру. Разберем, чем Evolution Bare Metal отличается от облачной виртуализации, как подобрать GPU-конфигурацию для инференса, обучения и дообучения моделей, а также как масштабировать ИИ-нагрузки.
🧑‍💻 Для кого: ML-инженеры, разработчики ИИ-продуктов, архитекторы и технические руководители.
📅 Когда: 25 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как ИИ помогает создавать и сопровождать Spark-задачи в облаке
Покажем, как Evolution Managed Spark с ИИ помогает создавать, запускать и анализировать Spark-задачи с помощью запросов на естественном языке. Разберем работу с данными в Evolution Object Storage, поиск причин ошибок, рекомендации по их устранению и оптимизацию производительности приложений.
🧑‍💻 Для кого: дата-инженеры, разработчики Spark-приложений, аналитики данных и DevOps-инженеры.
📅 Когда: 27 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ФСТЭК опубликовала методику оценки уровня зрелости в области технической защиты информации, которая затрагивает в том числе значимые объекты КИИ. Документ вводит пять уровней зрелости (от «нулевого» до «верифицируемого») и 21 направление оценки — от управления защитой до применения ИИ. Эксперты отмечают, что методика призвана бороться с недобросовестными подрядчиками и перевести ИБ из разрозненных задач в стратегию, однако её реализацию могут осложнить неясность с проведением оценки и отсутствие должного контроля со стороны регулятора.

Память VDS. Что стоит за строкой «8 ГБ» в тарифе
Число в тарифе отвечает на один вопрос: сколько памяти увидит гостевая система. Зарезервирован ли объем физически, может ли гипервизор забрать страницы обратно и что будет при пике соседей, оттуда не следует.

Три слова, которые каждый понимает по своему. Dedicated обычно означает объем, постоянно доступный машине по условиям тарифа. Слово «постоянно» стоит уточнить: резервируется ли память на хосте и может ли ballooning ее уменьшить. В burstable часть доступна всегда, остальное при свободном ресурсе узла. Shared значит, что резервирования нет. Даже при dedicated провайдер может разрешать swap на хосте, поэтому гарантия в договоре важнее названия модели.

Ballooning и overcommit. Ballooning работает через драйвер внутри гостя. По команде хоста он занимает страницы, ядро гостя освобождает кеш или уходит в свой swap, а высвобожденную память гипервизор отдает другим машинам. Пока баллон надут, приложения работают с меньшим объемом, чем в тарифе. Overcommit это когда сумма лимитов больше физической RAM узла. Умеренная переподписка работает годами, пока гости используют часть лимитов. Пример: после резерва под системные процессы на узле осталось 120 ГБ, машинам назначено 180. При суммарном рабочем наборе 80 ГБ никто ничего не заметит. При 140 придется забирать страницы через ballooning или уходить в swap хоста. Overselling это тот же overcommit, но с недостаточным запасом: разница не в технологии, а в коэффициенте.

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

free -m && grep -E "MemAvailable|SwapFree" /proc/meminfo
vmstat -y 1 10

procs ---swap-- -----io---- ---cpu---
 r  b   si   so    bi    bo  us sy id wa st
 1  2  184  412  1240   980  22  6 61 10  1

Смотреть надо на MemAvailable, а не на free: файловый кеш при нужде освобождается. Ненулевые si и so в нескольких интервалах подряд это обмен сейчас, а не след прошлого пика.

cat /proc/pressure/memory

some avg10=14.82 avg60=9.31 avg300=3.07 total=8123441
full avg10=6.55 avg60=4.02 avg300=1.18 total=3910228

PSI это доля времени, потерянного задачами из за нехватки памяти. Строка some означает, что простаивала хотя бы одна задача, full что вставала вся работа. Четырнадцать процентов в avg10 при выросшем времени ответа это разговор, а не шум.

journalctl -k -g "oom|Killed process"

Если процесс убило ядро гостя, запись будет здесь. Отсутствие записи при остановившейся машине это отдельный сюжет: OOM хоста может завершить процесс самой машины, и в журнале гостя причины не будет.

Признаки, которые стоит собрать вместе. Задержка растет в одни и те же часы при сопоставимой нагрузке. Устойчивые si и so без изменения профиля приложения. PSI растет синхронно с замедлением. Машина останавливается без записи об OOM у себя. Один признак ничего не доказывает, три совпавших уже повод писать в поддержку с временем эпизодов и метриками.

Что спросить до заказа. Какой объем зарезервирован, а не просто виден. Допускается ли ballooning и до какого минимума. Разрешен ли swap на хосте для памяти машин. Для burstable отдельно: гарантированная часть и условия доступа к остальному.

Тип гипервизора говорит об архитектуре, а не о гарантиях: overcommit поддерживают и KVM, и VMware, и Xen. SLA обычно описывает доступность и компенсацию за простой, но не производительность.

Представлен открытый проект torlink, который умеет искать и работать с торрентами из проверенных источников. Запускается командой npx torlnk. Одновременно проверяет FitGirl, YTS, The Pirate Bay, 1337x, Nyaa и другие источники, а результаты показывает вместе с размером и числом сидов. Выбранный файл скачивается в фоне, а после завершения автоматически встаёт на раздачу.

«Найти торрент в наши дни — сплошная головная боль. Один сайт — это минное поле из поддельных кнопок загрузки. Другой скрывает настоящую ссылку под всплывающим окном, которое открывает ещё две вкладки. И после всего этого половина результатов — это неработающие сайты с нулевым количеством раздающих. Torlink — это программа для поиска торрентов, которая работает в вашем терминале, не требует никакой настройки и конфигурации. Один поиск проверяет короткий, тщательно отобранный список надёжных источников, и всё, что вы выберете, загрузится прямо на ваш компьютер. Файлы ваши, сохранены в папке загрузок», — пояснил автор проекта.

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

Колонка %steal показывает время, когда система готова работать, а процессор ей не дали. Важна повторяемость: единичный всплеск это шум, рост в одни часы это конкуренция. На контейнерном тарифе лимит виден как троттлинг, steal остается низким.

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat

200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

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

Память. Объем в тарифе это то, что видит гостевая система, а не то, что зарезервировано на хосте. При ballooning драйвер отдает страницы гипервизору, и наличие устройства подтверждает механизм, но не политику.

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

Как сравнивать? Не складывайте IOPS, миллисекунды и баллы в один рейтинг. Сначала отсеките тарифы, не проходящие пороги приложения, потом расставьте веса: базе важнее p99 диска, агенту сборки процессор, медиасервису исходящая полоса. Для каждого прогона сохраняйте дату, локацию, образ, версии утилит и команду.

Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.

Представлен открытый проект skales — ИИ‑агент, который запустится даже на слабом ПК:

• работает как обычное приложение в Windows, macOS и Linux;

• агент получает доступ к файлам, браузеру, почте и календарю;

• умеет выполнять сложные задачи в фоновом режиме;

• можно запланировать любую таску по таймеру;

• своя встроенная память для важного контекста;

• при этом команды отправлять можно даже со смартфона — агент выполнит их на ПК;

• можно тестировать на бесплатном пробном режиме, подключить API или локальную модель.

Представлен первый релиз эмулятора терминала под необычным названием Shitty. Автор проекта считает его «серьёзным эмулятором терминала с глупым названием». Код решения написан с помощью ИИ-ассистента на C++23 (сbundled libstd, требующей -std=c++26) и распространяется под двойной лицензией MIT и GPL-3.0. Поддерживаются macOS и Linux.

Проект делает ставку на обеспечение низких задержек, быстрого запуска и предсказуемого потребления ресурсов: состояние терминала обрабатывается на CPU, а отрисовка выполняется через бэкенды на базе Vulkan в Linux и Metal в macOS, без использования стороннего графического тулкита. При тестировании производительности вывод 100 МБ ASCII через терминал Shitty показывает ~118 МБ/с, обгоняя alacritty (0.81 с против 0.96 секунд), kitty и ghostty. На «случайных байтах» с некорректным UTF-8 отрыв от alacritty ещё заметнее (~51 МБ/с против ~31 МБ/с). Корректность работы Shitty обеспечивается более чем 5000 тестами, собранными из десятка с лишним внешних наборов — kitty, esctest, vttests из xterm, vttest, tack, libvterm, libtsm, alacritty, ghostty, contour, konsole, mosh. Тесты выполняются с проверкой работы на реальном PTY.

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

12 августа в 11:00 МСК пройдет бесплатный вебинар «Импортозамещение ≠ долго, дорого, формально. Миграция корпоративных коммуникаций: опыт VK WorkSpace и кейсы крупных компаний».

Эксперты VK Tech расскажут, как подготовить инфраструктуру к переходу, какие данные можно перенести в SaaS-версию и нужно ли при этом останавливать работу на прежней платформе. Отдельно разберут возможные ошибки при миграции, восстановление неперенесенных данных и адаптацию сотрудников после запуска новой системы.

В прямом эфире покажут работу сервисов VK WorkSpace: почты, календаря, мессенджера, видеоконференций, документов, облачного диска и таск-трекера. На примерах крупных компаний спикеры объяснят, сколько времени может занять переход и какие сложности обычно возникают в процессе. Вебинар проведут Сергей Кирсанов, менеджер по развитию продаж VK WorkSpace, и Иван Бородин, пресейл-архитектор VK WorkSpace.

Облако для продакшена. Что показывают steal, await и реальная полоса?
Два провайдера, одинаковая строка в тарифе: 4 vCPU, 8 ГБ, 100 ГБ SSD, гигабит. Цена расходится на 15 процентов, и непонятно почему. Через неделю тестов выясняется, что p99 отличается в разы. Тариф описывает то, что выделено виртуально. Что происходит в железе, туда не попадает.

Почему синтетика не отвечает на вопрос? Geekbench и sysbench меряют потолок за короткий тест. Продакшен работает иначе: нагрузка неровная, соседи по ноде непредсказуемы. Провайдеры делают оверкоммит, и пока суммарная нагрузка умеренная, все хорошо. Стоит нескольким машинам дать всплеск разом, растет steal, удлиняется дисковая очередь, канал упирается в шейпер. Короткий тест может не попасть в это окно. Нужно от получаса нагрузки, а на суточные паттерны от 24 часов.

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

vmstat 1 30

procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache  us sy id wa st
 2  0      0 512344  81920 210488  31  4 58  1  6

Колонка st справа. Шесть процентов несколько строк подряд это не шум. Разбивку по ядрам дает mpstat -P ALL 1 10, длинный срез пишут в файл через sar -u 1 3600 и сравнивают часы между собой.

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

Для транскодирования и компиляции steal переводится во время выполнения почти линейно. Для API и запросов к базе иначе: медиана держится, а p99 растет, потому что в моменты steal запросы копятся в очереди. Отдельная история это всплески до 20 процентов на пару секунд при спокойном фоне. Такой скачок опаснее ровного высокого steal, он тянет каскад таймаутов.

Диск. Публикуемые IOPS измерены в идеальных условиях и под смешанной нагрузкой мало о чем говорят. Мониторинг запускают параллельно с тестом.

iostat -xz 1 10

В выводе важны два числа: await это время запроса вместе с ожиданием в очереди, avgqu-sz это глубина очереди. Растет второе, следом первое. Профиль OLTP проверяют так:

fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
    --numjobs=4 --iodepth=32 --size=4G --runtime=60 \
    --time_based --ioengine=libaio --group_reporting

Флаг direct обязателен, без него тест уедет в страничный кеш и покажет память вместо диска. В отчете смотрите iops и clat p99, именно второе объясняет хвосты запросов. Ориентир для средней базы это 5000 IOPS на чтении 4К при await ниже 2 мс, для нагруженной 20000 при await ниже миллисекунды.

Очередь выше восьми под OLTP это первый признак насыщения. Загрузка под 100 процентов для SSD не приговор, тревожно когда вместе с ней растет await. У дисков с лимитом IOPS порог срабатывает раньше насыщения железа, и покажет это именно await.

Сеть. Заявленный гигабит это верхний предел, а не гарантия. Шейпинг под нагрузкой в документации обычно не описан.

iperf3 -c 10.0.0.5 -t 60 -P 4
mtr --report --report-cycles 100 10.0.0.5

Четыре потока нужны потому, что один упирается в размер окна и RTT, а не в канал. Минута нужна, чтобы поймать burst лимит: полная полоса первые пятнадцать секунд и просадка дальше это он. Потери на одном промежуточном хопе при чистом трафике дальше это деприоритизация ICMP роутером. Потери подряд на нескольких хопах уже другое.

Проверьте MTU. Overlay сети добавляют заголовок к каждому пакету, 1500 превращаются в 1450, а пакеты с флагом DF молча теряются.

ping -M do -s 1472 10.0.0.5

Порядок проверки. Срез в покое сразу после деплоя, он же точка отсчета. Затем steal под боевой нагрузкой. Дальше fio с профилем приложения и iostat в соседнем терминале. Потом сеть. И наблюдение сутки или трое, иначе суточный паттерн конкуренции пройдет мимо.

Одинаковые характеристики не означают одинаковую производительность. Steal, await и реальная полоса измеряются за несколько часов.