Это вопрос, ради которого мы доработали память своего Codex. MikroTik здесь имя специализированного чата, которому мы поручаем задачи по RouterOS. В текущей документации можно найти, как сеть устроена сейчас. В переписке за июль могли остаться обсуждение, отменённый план и отчёт о выполненной работе. Если смешать их, получится убедительная история, в которой запланированное изменение уже выглядит выполненным.

Нам нужен был ответ с датами и источниками: кто сообщил о работе, что именно сообщил и чем это можно проверить. Для этого мы связали канонические документы, индекс MySQL, отчёты специализированных чатов и архивы переписки. Ниже описана наша действующая реализация на 2 октября 2026 года. Примеры запросов не содержат частных адресов, ключей или выгрузок из рабочих чатов.

Что у нас называется памятью

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

У этой системы несколько разных хранилищ.

Где лежат сведения: Канонические Markdown-документы
Что мы там храним: Архитектуру, действующие решения, инструкции, актуальный статус
Для чего читаем: Выяснить, что принято и как система должна работать

Где лежат сведения: MySQL, у нас Percona Server 8.0
Что мы там храним: Структурированные факты, связи, решения, проверки и индекс документов
Для чего читаем: Найти нужный источник и собрать короткий начальный контекст

Где лежат сведения: События координатора задач
Что мы там храним: Назначения специалистам и их итоговые отчёты
Для чего читаем: Найти сообщения о работе по владельцу и времени

Где лежат сведения: Локальные записи сессий и отдельный архив
Что мы там храним: Сохранившуюся переписку Codex
Для чего читаем: Разобрать старый эпизод, которого нет в структурированных отчётах

Где лежат сведения: Таблица activity_events
Что мы там храним: Отобранные краткие записи со ссылкой и отпечатком источника
Для чего читаем: Сохранить указатель на исторический отчёт без копирования его тела

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

Канонические документы остаются основой для действующих решений. Индекс помогает их найти. Исторический отчёт объясняет, что автор сообщил в определённый момент, но не отменяет более позднего решения и не подтверждает состояние оборудования сегодня.

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

Как новый чат получает нужный контекст

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

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

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

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

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

Вызовы доступны через MCP. Протокол позволяет приложению обнаруживать инструменты сервера и вызывать их с описанными аргументами; правила отбора источников и пределы ответа реализованы уже в нашем сервере памяти. Это разделение соответствует архитектуре MCP.

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

«Что делали в июле» требует другого поиска

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

Вот параметры вызова для нашего июльского примера. Здесь месяц намеренно задан по UTC. Для календаря в другом часовом поясе нужно передать его явно.

Параметры вызова memory_activity · JSON

JSON

{
"name": "memory_activity",
"arguments": {
"owner": "MikroTik",
"start": "2026-07-01",
"end": "2026-07-31",
"timezone": "UTC",
"kind": "all",
"limit": 50
}
}

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

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

Результаты различаются по типу:

Тип: reported_change
Как читать запись: Автор сообщил об изменении. Нужен исходный отчёт, если важны подробности и подтверждение

Тип: read_only
Как читать запись: В отчёте указана работа без изменений, например диагностика

Тип: discussion
Как читать запись: Найден материал обсуждения; выполненное действие из него не установлено

Отдельное поле хранит результат отчёта: reported_complete, reported_stop или unknown. «Сообщил о завершении» не равняется «независимо проверено». Классификация консервативная и основана на тексте и метаданных отчёта, а не на наблюдении за каждой командой специалиста.

Когда мы проверили сохранившиеся июльские материалы MikroTik, поиск по локальной истории и архиву сработал. Но старые сообщения вернулись кандидатами обсуждения: оснований объявить их структурированными отчётами о выполненных изменениях не было. Мы не стали задним числом заполнять журнал предполагаемыми действиями.

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

Что находится в записи активности

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

Поиск по периоду опирается на составной индекс (owner_chat, occurred_at, event_key). Сначала мы ограничиваем владельца, затем диапазон времени. Такой порядок соответствует использованию левого префикса составных индексов MySQL. Конкретный план выполнения всё равно следует проверять на своих данных.

Даты интерфейса включают оба выбранных календарных дня. Код переводит их в UTC и строит полуоткрытый интервал: от начала первого дня до начала дня после последнего. Это избавляет от угадывания последней секунды месяца.

У DATETIME нет автоматического преобразования часового пояса, которое MySQL выполняет для TIMESTAMP. Поэтому хранение UTC в нашем DATETIME(6) является договорённостью приложения, а не свойством типа, которое само исправит переданные локальные значения. Различие описано в документации MySQL о датах и времени.

Ниже показана только выборка из отобранной таблицы активности. Это иллюстрация SQL для июля по UTC, не полный код memory_activity: в нём дополнительно читаются события координатора и, при отсутствии записей, локальные кандидаты. Запрос имеет смысл в схеме с описанной таблицей; сам он ничего не создаёт и не меняет в ней.

Выборка отобранных событий за июль · SQL

SQL

SELECT occurred_at, kind, result, title, source_ref
FROM activity_events
WHERE owner_chat = 'MikroTik'
AND occurred_at >= '2026-07-01 00:00:00'
AND occurred_at < '2026-08-01 00:00:00'
ORDER BY occurred_at, event_key
LIMIT 50;

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

Что действительно ускорилось

После доработки мы сравнили старый и новый поиск на двадцати фиксированных вопросах. Прогоны выполнялись последовательно на одном хосте и одном индексе. Для каждого вопроса заранее был определён ожидаемый источник.

Показатель: Ожидаемый источник среди первых трёх результатов
До: 10 из 20
После: 20 из 20

Показатель: Медиана первого поиска без готового пакета в кэше
До: 339,915 мс
После: 325,05 мс

Показатель: Медиана повторного поиска
До: 344,23 мс
После: 115,63 мс

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

Кэш находится в памяти процесса MCP-сервера. Он ограничен 128 записями с временем жизни 60 секунд; ключ включает владельца, запрос и бюджет. Перед использованием готового пакета сервер всё равно обращается к MySQL и сравнивает ревизию индекса и фактов, включая состояние их срока действия.

При промахе мы объединяем получение ревизии, фактов и поисковых результатов в одну транзакцию чтения. Это сокращает отдельные обращения. Существующий клиент MySQL остаётся в пути запроса; новый постоянный пул соединений мы здесь не вводили.

Проверка ревизии относится к уже обновлённому индексу. Если Markdown-файл изменился на диске, а переиндексация ещё не прошла, кэш не узнает об этом сам. Плановое обновление индекса у нас идёт раз в 30 минут; для важных изменений его можно обновить отдельно. Короткий TTL не превращает индекс в мониторинг файлов или оборудования.

Максимальный новый пакет в тестовом наборе составил 796 приблизительных токенов. Бюджет начального контекста ограничен 800 такими единицами. Оценка основана на длине JSON, а не на токенизаторе конкретной модели: это инженерный ограничитель объёма, не точный расчёт стоимости.

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

Почему мы не отправляем модели весь архив

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

Есть и исследовательское основание проверять, как модель использует длинный контекст. В работе Lost in the Middle, опубликованной в 2023 году, Liu и соавторы изучали поиск значений и ответы по нескольким документам. У исследованных моделей результат зависел от положения нужной информации: середина длинного контекста часто оказывалась менее удачным местом, чем его начало или конец.

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

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

Где память заканчивается

Указатель на источник полезен ровно настолько, насколько понятно его происхождение и покрытие поиска. Мы сохраняем это различие в нескольких местах.

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

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

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

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

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

Те же примеры JSON и SQL с подсветкой синтаксиса доступны в статье.

Больше технических разборов публикую на сайте.

Пометка NVMe в тарифе не гарантирует предсказуемых задержек для Cloud VPS. Реальные характеристики дисковой подсистемы зависят от архитектуры хранилища, QoS-политик и уровня виртуализации I/O. NVMe важен, но не решающий фактор.

Что на самом деле определяет скорость диска в VPS

Производительность VPS под дисковой нагрузкой ограничивается несколькими факторами одновременно. QoS-политика и burst-лимиты IOPS могут влиять на результат не меньше, чем тип накопителя. Виртуализация I/O через virtio добавляет небольшой накладной расход. Конкуренция соседей по хосту даёт непредсказуемость p99-задержек.

Local NVMe vs сетевое хранилище

Local NVMe даёт наименьшую задержку: p99 в пределах 100–300 мкс. Сетевые решения (NVMe-oF, Ceph RBD, SDS) повышают p99 из-за сетевого round-trip, зато включают репликацию и снапшоты. Выбор NVMe VPS оправдан для stateful-нагрузок с жёсткими требованиями к fsync-задержкам.

IOPS, латентность и предсказуемость под нагрузкой БД

PostgreSQL и MySQL создают смешанную дисковую нагрузку: случайное чтение небольших блоков, fsync для WAL и последовательные сканирования. В продакшен-среде на Cloud VPS p99-задержка fsync напрямую влияет на задержку коммита. Burst-лимиты могут скрывать ограничение дисковой подсистемы до тех пор, пока нагрузка не превысит гарантированный уровень IOPS.

Как правильно бенчмаркать

Классическая ошибка: фиксировать средний throughput вместо p99-latency. Запускайте fio с параметрами --rw=randread --bs=4k --iodepth=32 и смотрите процентили задержки. Утилита ioping показывает задержку одиночного I/O. Для PostgreSQL используйте pgbench после нескольких прогонов на прогрев кэша.

Что узнать у провайдера до миграции

•  Гарантированные IOPS и burst-лимит вашего VPS

•  Архитектура хранилища: локальный NVMe или распределённое хранилище

•  Есть ли гарантии по p99-задержке

•  Схема репликации и RPO при сбое диска

•  Доступность снапшотов и периодичность их создания

•  Наличие оверкоммита и политика изоляции I/O

Тип диска в тарифе – это отправная точка. Перед миграцией проверьте дисковую подсистему по чек-листу и прогоните собственные тесты: реальные p99-задержки и стабильность IOPS могут отличаться от описания тарифа.

походу не надо)))))))

Для СУБД важна не максимальная скорость в коротком тесте, а стабильный отклик диска под рабочей нагрузкой. Требования к I/O зависят от профиля: OLTP, аналитика и смешанные нагрузки по-разному используют чтение, запись, WAL, временные файлы и кэш. VDS для баз данных оценивают по стабильному IOPS, p99-задержке и поведению под длительной нагрузкой, а не по лучшей цифре из прайса.

Почему БД чувствительны к стабильности I/O

PostgreSQL пишет WAL, MySQL – redo log и, если включён, binlog. При скачках задержки fsync с 2 до 80 мс транзакции могут ждать диск, а очередь запросов расти даже при нормальной средней скорости. io_wait сам по себе не всегда означает проблему: его нужно смотреть вместе с latency диска, p95/p99 и временем ответа запросов.

Пиковая скорость vs устойчивый IOPS

На VDS с burst-профилем короткий тест может показать высокий результат, но через несколько минут упереться в лимит хоста или нагрузку соседних VM. Для OLTP важнее, чтобы 5 000 IOPS держались ровно 10–15 минут, чем разовый пик в 50 000 IOPS на старте теста.

Метрики, на которые смотреть

Смотрите не только среднюю задержку, а p95/p99, джиттер и самые медленные операции записи. Оценивать график лучше относительно SLO конкретной СУБД и приложения: p99-задержка, время ответа запросов и io_wait не должны регулярно выходить за допустимые для проекта значения при одинаковой нагрузке.

Как проверить VDS перед миграцией БД

Перед переносом запустите fio со случайным чтением и записью блоками 4K минимум на 10 минут и отдельно проверьте СУБД через pgbench или другой нагрузочный тест. fio помогает оценить диск, но не полностью повторяет поведение PostgreSQL или MySQL: важны WAL, fsync, cache hit ratio и размер рабочего набора данных. Размер тестового файла должен быть больше объёма памяти, который может использоваться под page cache, иначе результат может попасть в кэш и показать нереалистично высокую скорость. Тестируйте VDS-сервер в то же время суток, когда у проекта обычно пиковая нагрузка.

Что замерить до переноса продакшена

•  Стабильный IOPS на длительном fio-тесте

•  p99-задержка чтения и записи

•  p99-задержка fsync при типичной нагрузке вашей СУБД

•  io_wait во время pgbench или тестовой нагрузки

•  Наличие резервирования дисков, RAID-схему и поведение платформы при сбое накопителя

•  Доступный объём RAM, использование page cache и активность swap под нагрузкой

•  Поведение диска после 10–15 минут непрерывной нагрузки

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

На контейнерной схеме CPU и I/O могут делиться между всеми на хосте, а степень изоляции зависит от настроек хоста, лимитов и политики провайдера. Современные контейнерные решения могут нормально работать под нагрузкой, если ресурсы распределены корректно. Если сосед по железу активно загружает физические ядра или диск, ваш контейнер может тормозить, а без доступа к хостовой стороне причину сложнее подтвердить.

Например, два тарифа могут иметь одинаковые характеристики: 4 vCPU и 8 ГБ RAM. Один сервер будет работать стабильно под нагрузкой благодаря корректным лимитам ресурсов и контролю плотности размещения VM, а другой может показывать просадки из-за высокой конкуренции за ресурсы на хосте.

CPU steal time (%st в top и vmstat) показывает, сколько времени виртуальный процессор ждал, пока гипервизор выделит ему физическое ядро. Проще говоря, это время, когда VPS хотел получить CPU, но физический ресурс был занят другими задачами на хосте. При нормальной конфигурации хоста показатель держится близко к нулю. fio и vmstat позволяют увидеть симптомы деградации (рост latency, steal time), но не позволяют однозначно подтвердить оверселлинг.

Сценарии, где разница решает

• PostgreSQL и MySQL под нагрузкой: нужна I/O-предсказуемость и стабильный RAM.

• Low-latency API: скачки задержки в правильно написанном сервисе могут быть связаны с CPU steal, I/O или нагрузкой на сеть, а не только с кодом.

• CI/CD-раннеры и k8s-ноды: всплески нагрузки у соседей не должны валить ваши сборки и поды.

Чек-лист: как проверить изоляцию у провайдера

• Тип виртуализации: KVM/Xen или OpenVZ/LXC?

•  vCPU гарантированы или мягкий лимит с троттлингом?

• Есть ли гарантии IOPS или диск работает в shared-режиме без ограничений?

• Публикует ли провайдер политику оверселлинга?

• Можно ли измерить steal time через vmstat или встроенный мониторинг?

Перед выбором тарифа пройдитесь по этому чек-листу. Маркировка «VDS» на сайте провайдера не гарантирует аппаратной изоляции, посмотрите тип гипервизора отдельно.

У двух провайдеров могут быть одинаковые характеристики: 4 vCPU, 8 GB RAM, 100 GB SSD, гигабитный канал. При этом цена отличается на 15%, и разница неочевидна. Но через неделю нагрузочных тестов выясняется: p99-задержки у серверов расходятся в разы.

Облачный сервер с «бумажными» характеристиками это то, что провайдер выделил виртуально. Что происходит в железе, остаётся отдельным вопросом. Когда сосед по гипервизору кладёт что-то тяжёлое, дисковая очередь растёт или канал режут по полосе, ничего из этого в спецификации тарифа нет.

Чтобы не обнаружить проблему уже в продакшене, стоит прогнать три блока тестов до миграции: CPU steal, дисковая подсистема и сеть. Инструменты стандартные: vmstat, fio, iperf3. Интерпретировать результаты нужно в контексте нагрузки, тарифа и времени измерения.

Почему синтетических бенчмарков недостаточно

Geekbench, sysbench, UnixBench замеряют потолок: максимум, который сервер может показать в коротком тесте. Продакшен так не работает. Нагрузка нестабильна, а соседи по физическому узлу непредсказуемы.

В облаке ресурсы виртуальные, и провайдеры применяют оверкоммит: виртуальных ядер на узле выделяется больше, чем можно гарантировать физически при одновременной нагрузке. Пока суммарная нагрузка умеренная – всё в порядке. Когда несколько VM одновременно дают всплески, растёт steal time и дисковая очередь, сеть упирается в лимиты или шейпинг. Это и есть эффект «шумных соседей». Он проявляется непредсказуемо, потому что зависит от того, кто ещё размещён на вашей физической ноде прямо сейчас.

Короткие синтетические тесты не всегда это показывают: они выполняются на общей ноде, но могут не попасть в периоды конкуренции с другими VM за ресурсы. Реальное тестирование облачного сервера должно включать не только короткие синтетические тесты, но и наблюдение за поведением системы в динамике. Для первичной проверки обычно достаточно 30–60 минут нагрузки, а более длительный мониторинг в течение 24–72 часов помогает выявить периодические проблемы с конкуренцией за ресурсы.

Три вещи остаются за кадром при коротком синтетическом тесте. Первое – эффект соседей: ваша VM не одна на физической машине. Второе – нелинейность дисков: SSD ведёт себя по-разному при чистом чтении, чистой записи и их смеси. Третье – временные эффекты сети: burst-лимиты, суточные паттерны шейпинга, перестройка BGP-маршрутов при переключении аплинков.

CPU steal: как увидеть ожидание CPU на гипервизоре

CPU steal time – это процент времени, когда ваш vCPU готов к работе, но гипервизор не предоставляет ему физическое ядро. Причиной может быть высокая загрузка хоста, конкуренция с другими VM, особенности планировщика или условия конкретного тарифа. Для приложения это будет дополнительной задержкой без видимой причины – процессор загружен, а работу не выполняет.

Следить за CPU steal time удобнее всего в реальном времени. В выводе vmstat правая группа колонок – блок cpu: us – user, sy – system, id – idle, wa – ожидание диска, st – steal. Если st держится выше нуля несколько строк подряд, нужно смотреть динамику, а не разовый всплеск:

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

Можно посмотреть показатели по каждому vCPU отдельно, чтобы убедиться, нет ли концентрации steal на отдельных vCPU. Такая картина может указывать на особенности планирования или размещения VM:

Если вы используете Prometheus, node_exporter экспортирует node_cpu_seconds_total с меткой mode="steal". Так удобно смотреть изменение steal во времени, а не отдельные срезы в терминале.

Практические ориентиры по значениям steal:

Как интерпретировать steal в разных сценариях

Для CPU-bound задач (транскодирования, ML-инференса, компиляции) steal транслируется напрямую во время выполнения. Steal 5% может означать близкую по масштабу потерю доступного CPU-времени, а также нерегулярные паузы от гипервизора, которые нарушают предсказуемость.

Для latency-sensitive API – REST, gRPC, запросов к базам данных – зависимость нелинейная. Медиана может держаться в норме, а p99 растёт: в моменты роста steal запросы накапливаются в очереди. Производительность облачного сервера при steal выше 3–5% для таких сервисов стоит проверять под реальной нагрузкой, синтетический тест этого поведения не показывает.

Отдельный случай – кратковременные всплески steal до 15–20% на несколько секунд при нормальных фоновых показателях. Так бывает при «пробуждении» нагруженной VM на соседнем слоте. Для realtime-сервисов такие пики особенно опасны: даже 3-секундный скачок latency может спровоцировать каскадные таймауты ниже по стеку.

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

Сравните значения st в разные промежутки. При устойчивом росте в пиковые часы стоит обратиться в поддержку и проверить, связана ли проблема с конкретной нодой, тарифом или инфраструктурой провайдера.

Диск: IOPS, latency и поведение под смешанной нагрузкой

нагрузкой

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

В выводе iostat важны два параметра. await – среднее время выполнения запроса к диску в миллисекундах, включая ожидание в очереди. avgqu-sz – средняя глубина очереди: когда она растёт, await растёт следом. В новых версиях sysstat await разделён на r_await и w_await – лучше смотреть оба.

Мониторинг дисковой подсистемы запускайте параллельно с нагрузочным тестом:

Для нагрузочного теста используется fio. Крайне важен флаг --direct=1: без него тест уходит в страничный кеш Linux и не отражает поведение диска. Параметры numjobs и iodepth задают глубину очереди: в примере с numjobs=4 и iodepth=32 суммарная глубина очереди равна 128, что перекрывает большинство всплесков при конкуренции потоков. В выводе смотрите на iops и clat p99: этот показатель помогает оценить вклад диска в хвостовые задержки запросов. В примерах ниже используется ioengine=libaio, но для современных Linux-конфигураций также можно рассматривать io_uring, если он поддерживается системой и версией fio.

Случайное чтение 4K – типичная OLTP-нагрузка:

Последовательная запись 1 MB – журналы, бэкапы, дамп БД:

Смешанная нагрузка 70/30 – реалистичная модель для большинства веб-приложений:

Ориентиры для БД и веб-приложений

Нет единого числа IOPS, которое подходит всем: зависит от характера нагрузки, размера рабочего набора и активности кеша. Примерные ориентиры для тестирования облачного сервера под разные типы нагрузок:

• PostgreSQL / MySQL, средняя — 4K rand IOPS: ≥5 000; await: <2 мс; %util: <70%

• PostgreSQL / MySQL, высокая — 4K rand IOPS: ≥20 000; await: <1 мс; %util: <70%

• Redis (с AOF) — 4K rand IOPS: ≥10 000; await: <1 мс; %util: <60%

• Nginx / файловый сервис — 4K rand IOPS: ≥1 000; await: <5 мс; %util: <80%

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

Если avgqu-sz устойчиво держится выше 8–10 под OLTP-нагрузкой, это первый признак насыщения: запросы встают в очередь, потому что диск не успевает. %util близко к 100% само по себе не катастрофа для SSD, но если при этом растёт await – диск работает на пределе.

Для облачных блочных устройств с гарантированными IOPS пороги обычно срабатывают раньше, чем %util достигнет 100%: провайдер режет I/O на установленном лимите, и очередь начинает расти задолго до насыщения железа. Именно await покажет это первым.

Тестировать стоит с той же глубиной очереди, что предполагается в продакшене: для PostgreSQL это обычно 8–32, для Redis – ниже.

Сеть: полоса, PPS, latency и потери

Настройка облачных серверов под продакшен без проверки сети – частая ошибка. Заявленный гигабит или 10 Gbps – это верхний предел, а не гарантированная полоса. Под длительной нагрузкой провайдеры нередко применяют шейпинг или rate limiting, и в документации это обычно не указано.

Базовый тест полосы между двумя нодами в одном датацентре (нужен iperf3-сервер на второй машине):

В строке receiver смотреть на Bandwidth. Ключ -P 4 запускает 4 параллельных TCP-потока – один поток не всегда показывает реальный потолок канала: результат зависит от RTT, настроек TCP и доступного размера окна передачи. Параметр -t 60 задаёт длительность 60 секунд – этого достаточно, чтобы обнаружить burst-лимиты, если они есть.

UDP-тест для оценки потерь и jitter под заданной скоростью:

Latency и jitter:

Параметры виртуального интерфейса – если драйвер отдаёт данные (имя может отличаться: eth0, ens3 и т.п.):

В выводе mtr обращайте внимание на колонки Loss% и Last. Потери только на одном промежуточном хопе при нормальном трафике дальше – скорее всего, роутер деприоритизирует ICMP TTL-exceeded. Устойчивые потери на нескольких хопах подряд – другое дело.

Примерные ориентиры для внутрисетевого трафика в одном датацентре: RTT < 1 мс, потери = 0%, jitter < 0.5 мс. Реальные значения зависят от сети провайдера, маршрута и требований приложения. Устойчивые потери до конечного узла могут стать поводом разбираться.

Частые проблемы сети в облаке

Rate limiting и шейпинг. Если iperf3 даёт полную полосу первые 10–15 секунд, а затем резко снижает результат – провайдер применяет burst-лимиты. Реальная устойчивая полоса в таком случае ниже заявленной, и это нужно учитывать при выборе тарифа.

MTU в overlay-сетях. VXLAN и Geneve добавляют заголовок к каждому пакету, снижая эффективный MTU ниже стандартных 1500 байт – обычно до 1450. Пакеты с DF-флагом при этом дропаются без уведомления приложения.

Проверка MTU для IPv4 при стандартном MTU 1500:

Ответ «Frag needed» или «Message too long» означает, что пакет такого размера не проходит без фрагментации. Для IPv6, туннелей и нестандартных MTU значения будут другими. Нужно снижать TCP MSS или настраивать PMTUD на стороне приложения, иначе соединения будут зависать или деградировать непредсказуемо.

Нестабильный роутинг. Если mtr показывает устойчивые потери до конечного узла или аномальный рост RTT по маршруту – запустите повторно через 5–10 минут. Если ситуация не меняется – возможны BGP-флап, перегрузка маршрута или внутренний сбой у провайдера. В таком случае настройка облачных серверов внутри одного VPC не поможет – проблема на уровне сети провайдера или внешних аплинков.

Чек-лист проверки облачного сервера перед production

Последовательность шагов для оценки нового сервера перед миграцией:

1. Базовый срез в покое. Сразу после деплоя, до всякой нагрузки: vmstat 1 60, iostat -xz 1 60, ping к соседней машине в той же зоне. Запишите исходные значения st, await, avgqu-sz – это точка отсчёта для сравнения.

2. CPU steal под нагрузкой. Создайте реальную или приближенную к продакшену нагрузку (например, через stress-ng или аналог), параллельно мониторя vmstat 1. Сам по себе синтетический тест не гарантирует конкуренцию ресурсов на стороне гипервизора, поэтому важна динамика steal под фактической нагрузкой. Steal выше 3–5% под умеренной нагрузкой – повод проверить динамику, сопоставить её с p95/p99 и обратиться в поддержку. Причина может быть в ноде, тарифе или инфраструктуре провайдера.

3. Дисковый тест. fio с профилем нагрузки, близким к продакшену: 4K randread для OLTP, 1 MB sequential write для стриминга. Зафиксировать IOPS, await, avgqu-sz. В соседнем терминале – iostat -xz 1.

4. Сетевой тест. iperf3 минимум 60 секунд, ping с 1000 пакетами, mtr до ключевых endpoint’ов. Отдельно – проверка MTU: для стандартного MTU 1500 в IPv4 с ICMP можно использовать ping -M do -s 1472. Для IPv6, туннелей и нестандартных MTU значения будут другими.

5. Мониторинг 24–72 часа. Вывод в продакшен без наблюдения за суточным паттерном – ещё одна частая ошибка. sar с записью в файл или любой агент метрик (node_exporter, collectd) покажут поведение steal и await в разное время суток и помогут поймать пиковую конкуренцию на ноде.

6. Анализ p95/p99. Если есть возможность запустить реальное приложение или нагрузочную копию – собрать гистограмму latency за несколько часов. p95 и p99 в контексте всей системы точнее любого синтетического теста и позволяют напрямую сверить результат с SLO.

Одинаковые характеристики не означают одинаковую производительность. CPU steal, дисковый await и реальная полоса – три параметра, которые можно измерить заранее, не дожидаясь первого инцидента.

Все приведённые утилиты доступны в стандартных репозиториях Linux-дистрибутивов. Развернуть облачный сервер у провайдера, прогнать чек-лист по описанному порядку и сравнить результаты с ориентирами – это несколько часов работы. Это значительно меньше, чем стоит инцидент в продакшене, который можно было предотвратить.