Узкое место в системе находят через связь трёх факторов: ограниченного ресурса, роста задержки и ухудшения результата для пользователя или сервиса. Высокая загрузка CPU сама по себе не подтверждает проблему. Нужны сопоставимые метрики до инцидента, во время него и после восстановления.
Начните с точного симптома: выросла p95 latency, снизился throughput, появились ошибки, стала расти очередь, замедлились чтение и запись или просело время тика приложения. Затем разделите систему на уровни: CPU, RAM, storage, network, приложение и его конфигурация. Для каждого уровня сформулируйте одну гипотезу, проверьте её измерением и меняйте один параметр за раз.
Такой порядок защищает от типичных потерь времени: перезапуска всех сервисов, случайного изменения sysctl, увеличения RAM при проблеме в дисках или расширения сетевого канала при ограниченном connection pool. Цель расследования состоит в том, чтобы получить воспроизводимое доказательство причины.
Как определить bottleneck: краткий алгоритм диагностики
Зафиксируйте симптом и временной интервал. Соберите показатели приложения и инфраструктуры в один диапазон времени: RPS, latency, error rate, глубину очереди, загрузку CPU по ядрам, available memory, swap, iowait, задержку дисков, сетевые ошибки. Узкое место подтверждается, когда при росте нагрузки ресурс насыщается или начинает ждать, а пользовательский показатель ухудшается синхронно.
Практический порядок выглядит так: описать симптом, определить границы проблемы, собрать базовую линию, выбрать слой проверки, сформулировать гипотезу, выполнить контролируемое изменение и повторить исходный сценарий. Более детальный порядок разбора симптомов и логов приведён в инструкции по диагностике снижения производительности автоматизированных систем.
Сначала определите, что именно ухудшилось
Фраза «система тормозит» не подходит для расследования. Запишите измеримый симптом: p95 latency выросла с 120 до 900 мс, очередь задач увеличилась с 20 до 8 000 элементов, запись на том стала занимать секунды, часть контейнеров вошла в CrashLoopBackOff или пользователи увидели timeout.
Укажите время начала, затронутые сервисы, регионы, tenant или namespace, тип запросов и интенсивность нагрузки. Один медленный endpoint при стабильной работе остальных чаще указывает на код, запрос к БД, внешний API или лимит пула. Одновременная деградация многих сервисов требует проверки общих зависимостей: сети, DNS, storage, базы данных, ingress или хоста виртуализации.
Проверяйте уровень обнаружения и уровень выполнения отдельно
Асинхронная обработка часто содержит два независимых участка: выбор задачи и её выполнение. Очередь может сформировать неверный путь, отфильтровать нужный файл, направить сообщение не в тот worker или повторно выдать старую задачу. Исполнитель при этом может работать штатно.
В обработке медиа сначала проверьте поиск файла и фильтры очереди, затем совместимость параметров HandBrake или FFmpeg: кодек, контейнер, дорожки, разрешение и аргументы команды. Тот же принцип применим к цепочке client - ingress/Nginx - service - worker - database. Увеличение CPU не исправит ошибочную маршрутизацию, а изменение таймаута не устранит неподдерживаемый формат входных данных.
Устойчивое узкое место или кратковременный всплеск нагрузки
Один снимок `top`, график за пять минут или единичный алерт не показывают характер проблемы. Сравните нормальный период, момент деградации и восстановление. Повторяемость при одинаковом профиле нагрузки служит сильным признаком устойчивого bottleneck.
Признаки устойчивого ограничения
Устойчивое ограничение повторяется в часы пик, при пакетных запусках или после достижения похожего RPS. Одновременно растут время ожидания, глубина очереди и latency, а throughput перестаёт увеличиваться. Например, сервис принимает больше запросов, но число успешно обработанных операций в секунду остаётся на прежнем уровне.
Проверяйте CPU по каждому ядру. Суммарная загрузка сервера может составлять 35-45%, когда один поток основного цикла держит ядро на 95-100%. Для однопоточного игрового сервера это проявляется как рост времени тика и rubber banding после увеличения онлайна. Для API аналогичный эффект возникает на одном блокирующем worker-процессе или в синхронной функции.
Признаки кратковременного события
Короткий пик часто совпадает с cron-задачей, резервным копированием, сборкой индексов, rollout, очисткой образов, snapshot, scrub, resilver, массовым импортом или сетевым разрывом. Он имеет ограниченную длительность, после которой метрики возвращаются к базовой линии без изменений конфигурации.
Зафиксируйте начало, конец, частоту и календарную привязку события. Если iowait и latency storage растут каждую ночь во время backup, проблема предсказуема. Сначала перенесите задачу, ограничьте её скорость или исключите конкуренцию с рабочей нагрузкой. Закупка дисков до этой проверки может не дать заметного эффекта.
Как выбрать окно наблюдения
Для веб-сервиса сравнивайте одинаковые часы буднего дня и одинаковые типы трафика. Для очереди задач используйте несколько запусков с похожим размером и составом входных данных. Для NAS сравните штатный доступ с периодом резервного копирования, репликации или проверки пула.
В Kubernetes отдельно наблюдайте штатную работу, rollout, autoscaling и период после запуска новых pod. Смотрите на requests и limits, рестарты, throttling CPU, eviction и задержки readiness. Изменения версий ОС, Docker, Kubernetes, Nginx, TrueNAS и ZFS фиксируйте в журнале, поскольку поведение метрик и значения по умолчанию могут различаться.
Базовая линия и сбор доказательств до изменений
Базовая линия нужна для сравнения. Снимите её под обычной нагрузкой и сохраните конфигурацию до любых правок. После изменения оценивайте тот же интервал, похожий RPS и одинаковый сценарий, иначе случайное снижение трафика можно принять за улучшение.
Какие метрики связать в одну картину
Связывайте ресурсные показатели с пользовательским эффектом: RPS, p50/p95/p99 latency, error rate, число активных соединений, глубину очереди и фактический throughput. Рост load average без увеличения latency ещё не подтверждает ограничение. Рост p95 latency одновременно с iowait, disk latency и очередью операций записи даёт сильную гипотезу о проблеме storage.
Для CPU смотрите user, system, iowait, steal и загрузку каждого ядра. Для памяти нужны available memory, swap in/out, major page faults, OOM-события и потребление по процессам или контейнерам. Для сети соберите RTT, retransmissions, drops, packet loss, throughput, ошибки интерфейсов и число переустановленных соединений.
Prometheus и Grafana для наблюдения за динамикой
Prometheus хранит временные ряды, Grafana помогает сопоставить их на одном дашборде. Минимальный набор панелей включает CPU по ядрам, память и swap, файловые системы, I/O latency, IOPS, сетевой throughput, retransmissions, latency приложения, ошибки и длину очередей.
Пороги не переносите между разными системами без проверки. Например, постоянный iowait выше 10% при росте задержки может быть тревожным сигналом, но на хосте с интенсивной пакетной записью требуется сравнение с обычным режимом. Рабочий набор метрик для Linux, Docker, Kubernetes, NAS и ZFS разобран в руководстве по метрикам производительности.
Минимальный журнал инцидента
Записывайте симптом, время, затронутые компоненты, интенсивность нагрузки, графики и логи, гипотезу, точное изменение и результат. Добавляйте версию приложения, образ контейнера, параметры запуска, версию ОС и сведения о недавних деплоях.
Отмечайте опровергнутые гипотезы. Запись «сеть проверена: RTT стабилен, retransmissions нет, канал не насыщен» сокращает повторную работу в следующем инциденте. Для production заранее подготовьте окно изменений, план отката и ответственного за проверку после правки.
Как найти узкое место в CPU и памяти
CPU и RAM проверяют вместе, но их симптомы различаются. Низкий CPU при высокой задержке часто означает ожидание диска, сети, блокировки или лимита приложения. Почти заполненная RAM не доказывает дефицит памяти: Linux использует свободную память под файловый кэш и может освободить её при необходимости.
Узкое место в CPU: общая загрузка против одного ядра
Смотрите загрузку каждого ядра, число runnable-задач, время user/system/iowait/steal и потребление CPU отдельными процессами. Одно ядро, стабильно занятое на 90-100%, при росте latency указывает на последовательный участок: главный цикл, single-threaded worker, блокирующий обработчик, сериализацию или тяжёлый plugin.
Проверьте профили приложения и распределение запросов между worker. Увеличение числа worker помогает только при наличии независимой параллельной работы и свободных ресурсов. Слишком высокий concurrency создаёт конкуренцию за базу, диски, внешний API или lock, после чего latency растёт при формально свободном CPU.
Узкое место в памяти: давление, swap и OOM
Проверяйте `MemAvailable`, swap in/out, major page faults, OOM killer, evictions и рестарты контейнеров. Повторяющийся swap in/out вместе с ухудшением p95 latency означает давление на память. OOMKilled у pod при потреблении, близком к memory limit, указывает на ошибочный лимит или неконтролируемый рост процесса.
Отделяйте файловый кэш от памяти, недоступной приложению. Если available memory остаётся достаточной, swap не используется, а latency стабильна, заполненная RAM может быть нормальным состоянием. Добавлять память в таком случае бессмысленно, пока не подтверждён эффект на рабочую нагрузку.
Что изменить без покупки CPU или RAM
Уберите лишние фоновые задания, сократите число тяжёлых plugin, исправьте неоправданно высокий concurrency и проверьте лимиты контейнеров. Разделите CPU-intensive и I/O-intensive задачи по очередям. Для Kubernetes задавайте requests по наблюдаемому потреблению, а limits оставляйте с запасом, который не вызывает постоянный throttling или OOM.
Меняйте один параметр за раз. После корректировки worker-процессов повторите тот же сценарий и сравните p95 latency, throughput, CPU по ядрам, память, error rate и глубину очереди. Результат без повторной проверки остаётся гипотезой.
Как проверить узкое место в дисковой подсистеме и хранилище
Storage часто ограничивает сервис при свободных CPU и RAM. Главные признаки: рост iowait, latency чтения или записи, queue depth, ошибки устройств, зависание записи логов и заполнение файловой системы. Для ZFS и NAS дополнительно учитывайте состояние пула, snapshots, репликацию, scrub, resilver и долю свободного места.
Заполненный диск как причина инцидента
Проверяйте свободное место и inode на каждой файловой системе, где приложение пишет логи, временные файлы, базы, кэш, образы контейнеров и результаты обработки. Том может иметь свободные гигабайты, но закончить inode. В такой ситуации создание маленького файла или сокета завершится ошибкой.
df -h
df -i
du -xhd1 /var | sort -hАнализ состава файлов через treemap или аналогичный инструмент быстро показывает крупные каталоги, старые saves, bundles, неочищенные логи, пакеты и временные артефакты. Удаляйте данные только по политике хранения и после проверки владельца процесса. Полный разбор IOPS, задержек и очередей есть в материале о влиянии хранилища на скорость работы серверов.
Высокая задержка диска и конкуренция за I/O
Сопоставьте latency сервиса с `iostat`, iowait, queue depth, IOPS и throughput. Высокий throughput не всегда плох: последовательная запись может занимать канал без заметной задержки. Опасная картина возникает, когда растёт время ожидания операций и приложение начинает копить запросы.
iostat -xz 1
pidstat -d 1
vmstat 1Проверьте backup, scrub, resilver, индексацию, snapshots, массовую распаковку образов и batch-задачи. В Docker и Kubernetes найдите контейнер или workload с максимальной записью. Лимитирование шумной задачи, перенос запуска за пределы пика или разделение рабочих данных и резервных копий часто снимает проблему без замены оборудования.
Force wipe, массовые операции и повторяемые пики
Force wipe, импорт, миграция, генерация отчётов или пересборка индекса создают предсказуемую нагрузку. Если в этот момент проседает FPS или растёт API latency, снимите CPU по ядрам, iowait, disk latency, свободное место и число параллельных задач.
Сравните два запуска: до ограничения параллелизма и после него. Если перенос фоновой операции снижает p99 latency рабочего сервиса, а общее время её выполнения остаётся приемлемым, ограничение было в конкуренции за ресурсы. Если latency диска остаётся высокой даже при одном потоке, потребуется оценить IOPS, тип носителей и схему хранения.
Как определить узкое место в сети
Термин «медленная сеть» скрывает разные причины: насыщение канала, высокий RTT, packet loss, retransmissions, drops, ошибки интерфейса, неверный MTU, DNS-задержки, ограничения ingress или проблемы конкретного соединения. Эти сценарии требуют разных действий.
Пропускная способность, задержка и потери пакетов
Насыщенный канал проявляется высоким throughput, близким к доступной полосе, и ростом очередей на передаче. Packet loss и retransmissions приводят к повторной передаче и увеличению времени ответа даже при свободном канале. RTT может вырасти из-за маршрута, перегруженного балансировщика, TLS handshake или медленного удалённого сервиса.
Проверяйте счётчики ошибок и drops на интерфейсах, TCP retransmissions, время DNS-резолвинга и latency на прикладном уровне. Один высокий ping не доказывает, что bottleneck находится в сети. Нужна корреляция с ошибками запросов, временем соединения или повторными передачами.
Проверка сети между уровнями приложения
Измеряйте каждый переход: client - CDN или load balancer - ingress/Nginx - service - database или storage. Сравните latency внутри pod, между pod одного узла, между узлами и снаружи кластера. Это сужает поиск до конкретного участка.
Проверьте `worker_connections`, keepalive, proxy timeout, connection pool, DNS, NetworkPolicy, MTU и лимиты балансировщика. В Docker и Kubernetes сетевой путь отличается по версии CNI, режиму Service и настройке ingress. Перед изменением параметров сохраните текущую конфигурацию и подготовьте откат.
Когда масштабирование канала не поможет
Увеличение полосы не устранит медленный backend, длинный запрос к БД, заполненный pool соединений, сериализацию большого JSON-ответа или rate limit внешнего API. Если интерфейс передаёт 15% доступной полосы, retransmissions нет, а upstream отвечает 20 секунд, искать нужно на стороне приложения или зависимости.
Проверьте breakdown времени запроса: DNS, connect, TLS, ожидание первого байта, скачивание тела, обработка на backend. Трейсинг помогает увидеть участок с максимальной задержкой. После этого меняйте конкретную причину, а не всю сетевую инфраструктуру.
Узкое место в приложении и его конфигурации
Инфраструктура может выглядеть здоровой, когда ограничение создают очередь, блокировка, тяжёлая функция, plugin, кэш, pool соединений, rate limit или таймаут. Поэтому метрики хоста дополняйте профилированием, логами запросов и трассировкой.
Профилирование тяжёлой функции или плагина
Per-function tick profiler показывает hook time и invoke time отдельных plugin или функций. Найдите компонент с заметной стоимостью на критическом пути, сопоставьте его работу с ростом времени тика или latency, затем отключите либо измените только этот компонент в контролируемом окне.
Массовое отключение plugin не даёт доказательства причины и создаёт новый риск. Точечная проверка даёт измеримый результат: например, время тика снизилось после исключения одной функции, а остальные показатели остались стабильными. Такой же подход применяйте к middleware, сериализаторам, SQL-запросам и обработчикам очереди.
Очередь: проблема маршрутизации или обработчика
Смотрите глубину очереди, возраст старейшего сообщения, скорость поступления и обработки, число retries, dead-letter queue и ошибки worker. Очередь растёт при свободных CPU и RAM, когда worker ограничен лимитом, обработчик блокируется на внешнем сервисе, задача неверно маршрутизируется или сообщения не подтверждаются.
Разделите проверку на две части: корректность выбора задачи и способность исполнителя обработать входные параметры. Для файловой очереди сначала подтвердите путь и фильтры, затем проверьте кодек, контейнер и аргументы обработчика. Ошибка несовместимой команды не исправляется повышением производительности сервера.
Кэширование без ложного ощущения ускорения
Перед настройкой кэша измерьте hit ratio, стоимость cache miss, размер объектов, TTL, инвалидацию и расход памяти. Кэш полезен, когда повторные запросы к дорогому ресурсу имеют предсказуемый срок актуальности. Ошибочная инвалидация вызывает устаревшие данные, а слишком большой кэш создаёт давление на RAM.
Сравнивайте p95 latency, нагрузку на storage или БД, error rate и память до и после изменения. Не переносите ожидаемый эффект с другого сервиса: профиль запросов, размер объектов и допустимая свежесть данных различаются.
Лимиты и настройки, которые маскируются под нехватку ресурсов
Проверьте лимиты файловых дескрипторов, соединений, worker-процессов, CPU и памяти контейнеров, настройки очереди, retries, rate limit и timeout. Свободные CPU и RAM не помогут, если Nginx достиг `worker_connections`, приложение исчерпало pool БД или pod упирается в CPU limit.
Сопоставьте фактическое потребление с установленным пределом. События throttling, отказ новых соединений, timeout при занятом pool или рост очереди около лимита дают прямую проверяемую гипотезу. Меняйте ограничение только после оценки того, какой следующий ресурс примет нагрузку.
Как подтвердить гипотезу до изменения системы
Корреляция ещё не доказывает причину. Гипотеза становится сильнее, когда контролируемое изменение одного фактора повторяемо улучшает целевой показатель без скрытых побочных эффектов.
Матрица «симптом - метрика - проверка»
| Симптом | Связанные метрики | Проверка |
|---|---|---|
| Рост latency и timeout | iowait, disk latency, queue depth | Ограничить фоновую запись, повторить нагрузку, сравнить p95 |
| Рестарты и ошибки памяти | swap in/out, OOMKilled, major page faults | Проверить лимит контейнера и рост памяти процесса |
| Просадка тиков при свободном среднем CPU | Загрузка одного ядра, время функции, очередь выполнения | Снять профиль и проверить тяжёлый plugin или главный цикл |
| Ошибки соединения и рост времени ответа | RTT, retransmissions, drops, pool соединений | Разделить путь до ingress, service и backend |
| Рост очереди при свободных ресурсах | Возраст задач, retries, лимиты worker, время обработчика | Проверить маршрутизацию и параметры исполнителя |
Таблица задаёт направление проверки, но не заменяет измерения. Например, высокий iowait может сопровождать storage-проблему, а может быть следствием задержек сетевого хранилища. Подтверждение требует повторного сценария.
Контрольное изменение и критерии успеха
До правки выберите одну переменную и запишите критерий успеха. Пример: уменьшить concurrency фонового worker с 32 до 8, затем проверить, снизилась ли p99 latency API при прежнем RPS и не выросло ли недопустимо время обработки очереди.
Фиксируйте побочные эффекты: рост RAM, потерю сообщений, увеличение времени восстановления, больше retries, падение throughput или ухудшение SLO другого сервиса. Считайте изменение успешным, когда исходный симптом исчезает в сопоставимом сценарии и эффект сохраняется дольше короткого окна после перезапуска.
Когда нужно остановить локальные правки
Локальные настройки перестают давать пользу, когда узкое место подтверждено, а безопасные изменения уже исчерпаны. Примеры: один поток упирается в архитектурное ограничение, хранилище стабильно не даёт нужную latency, база не выдерживает требуемую конкуренцию, один узел стал единственной точкой отказа.
Сравните стоимость простоя, сопровождения, миграции и дополнительного контура с измеримым выигрышем. Второй контур, реплика, отдельный worker-pool или увеличение IOPS оправданы при подтверждённой нагрузке и понятном улучшении. При малом объёме запросов такие расходы могут превысить пользу.
Как повысить производительность без лишних затрат
Начинайте с обратимых действий, которые устраняют доказанную причину. Сначала очистите накопившиеся данные и уберите лишние фоновые задачи, затем исправьте лимиты, таймауты, очереди и параметры приложения. К архитектурным изменениям и покупке ресурсов переходите после повторной проверки метрик.
Меры с низким риском и небольшими затратами
Удалите устаревшие логи, временные файлы, старые образы, bundles и saves по утверждённой политике. Отключите дублирующие cron-задачи, перенесите backup за пределы пика, ограничьте шумные plugin и устраните бесконечные retries. Проверьте, не конкурируют ли на одном диске рабочие данные, snapshots и резервные копии.
Скорректируйте worker-процессы, connection pool, лимиты файловых дескрипторов и очередь. Уменьшение параллелизма часто снижает давление на storage, БД или внешний API. Измеряйте результат после каждого изменения, иначе несколько одновременных правок скроют реальную причину улучшения.
Кэш, очереди и ограничение параллелизма
Кэш ставьте перед дорогим повторяемым чтением, если вы можете контролировать TTL и инвалидацию. Bounded queue защищает backend от неограниченного роста нагрузки. Разумные retries с задержкой снижают повторный удар по зависимому сервису во время сбоя.
Подбирайте concurrency по метрикам. Слишком низкое значение создаёт очередь при свободных ресурсах. Слишком высокое значение насыщает CPU, storage, БД или внешнее API, после чего throughput падает. Проверяйте работу под реальным или воспроизводимым профилем запросов.
Когда оправданы дополнительные ресурсы или второй контур
Увеличивайте CPU, RAM, IOPS, сетевую полосу или число узлов после подтверждения, что ограничен именно этот ресурс. Зафиксируйте ожидаемый эффект: например, снижение p95 latency при том же RPS, рост числа обработанных задач или сокращение времени batch-операции.
Для тестирования роста ресурса можно поднять отдельный стенд или временный узел в облачной инфраструктуре Timeweb Cloud и повторить измеряемую нагрузку. Сравнивайте не только скорость, но и стоимость сопровождения, резервного копирования, мониторинга и восстановления после сбоя.
Практический разбор: от симптома до подтверждённого bottleneck
Короткие сценарии показывают порядок расследования. В каждом случае исходный симптом не равен первопричине. Решение принимают после связи метрик с конкретным компонентом и контрольной проверки.
Просадка производительности после роста онлайна
Симптом: после роста онлайна появляются rubber banding и задержки, средняя загрузка CPU сервера держится около 50%. Ошибочная гипотеза: ресурсов CPU достаточно, проблема находится в сети. Проверка показывает одно ядро на 100%, рост времени основного тика и тяжёлый hook одного plugin.
Действие: снять per-function tick profile, отключить или переписать дорогой обработчик на тестовом сегменте, затем повторить нагрузку. Подтверждение: время тика и p95 latency снижаются, а загрузка проблемного ядра перестаёт достигать насыщения. Средний CPU в этом сценарии был слабым индикатором.
Падение производительности во время массовой операции
Симптом: во время force wipe, импорта или пересборки индекса растёт время ответа API и падает FPS. Ошибочная реакция: перезапустить все сервисы. Проверка `iostat` показывает рост latency записи и queue depth, а `df -h` выявляет почти заполненный том с временными артефактами.
Действие: освободить место по политике хранения, ограничить параллелизм массовой операции и перенести её из пикового окна. На следующем запуске сравните iowait, disk latency, p99 latency и время завершения задачи. Если задержка storage остаётся высокой при низком concurrency, исследуйте возможности пула и носителей.
Очередь обработки файлов выполняется с ошибками и задержками
Симптом: очередь растёт, часть задач завершается ошибкой, CPU и RAM свободны. Проверка обнаружения файлов показывает неверный путь у части сообщений. После исправления пути остаются ошибки обработчика, связанные с конкретным сочетанием контейнера и кодека.
Действие: разделить метрики маршрутизации и выполнения, исправить фильтр очереди, затем валидировать параметры обработчика на тестовом файле. Изменение размера сервера не устраняет несовместимую команду. Такой сценарий показывает, почему слой выбора задачи и слой выполнения проверяют отдельно.
Сервис замедляется из-за заполненного хранилища
Симптом: сервис перестаёт записывать логи, задачи зависают, появляются ошибки при создании временных файлов. Проверка показывает заполнение нужной файловой системы или исчерпание inode. Анализ каталогов выявляет старые архивы, временные данные и неочищенные логи.
Действие: удалить только разрешённые артефакты, настроить срок хранения, проверить ротацию логов и ограничить рост временных данных. После очистки подтвердите запись логов, скорость обработки очереди и latency. Состав данных на томе полезнее одного показателя процента заполнения.
Чек-лист диагностики производительности сервера
- Опишите симптом в измеряемой форме: latency, throughput, error rate, очередь, время чтения или записи.
- Зафиксируйте время начала, масштаб, затронутые сервисы и недавние изменения.
- Снимите базовую линию под обычной нагрузкой.
- Сопоставьте RPS, latency, ошибки и глубину очереди с инфраструктурными метриками.
- Проверьте CPU по ядрам, user/system/iowait/steal и процессы с максимальным потреблением.
- Проверьте available memory, swap in/out, page faults, OOM и лимиты контейнеров.
- Проверьте storage: свободное место, inode, latency, IOPS, queue depth, ошибки и фоновые операции.
- Проверьте network: throughput, RTT, retransmissions, drops, DNS, ingress и connection pool.
- Проверьте приложение: профили, трейсы, очередь, блокировки, retries, кэш, таймауты и лимиты.
- Сформулируйте одну гипотезу с ожидаемым эффектом.
- Измените один параметр, повторите тот же сценарий и сравните контрольные метрики.
- Запишите результат, побочные эффекты, план мониторинга и условия отката.
Что проверить перед изменением конфигурации
Сохраните текущую конфигурацию, список зависимых сервисов и параметры запуска. Убедитесь, что есть резервная копия, понятный план отката и окно для проверки. Для Docker, Kubernetes, Nginx, TrueNAS и ZFS сверяйте параметры с используемой версией: значения по умолчанию и доступные метрики меняются.
Не вносите несколько несвязанных правок одновременно. Комбинация изменения лимитов, версии образа, worker-процессов и кэша не позволит понять, что именно исправило проблему или вызвало регрессию.
Что считать доказанным результатом
Результат подтверждён, когда в сопоставимом сценарии улучшились заранее выбранные показатели, исходный симптом исчез, не появился новый bottleneck и эффект сохраняется после короткого периода наблюдения. Для сервисов с пиками оценивайте несколько циклов нагрузки, а не один удачный запуск.
После подтверждения настройте алертинг по связанным метрикам: latency и error rate, очередь и возраст задач, disk latency и заполнение файловой системы, CPU по ядрам и throttling, swap и OOM. Интерпретацию связей между графиками, логами и событиями можно углубить в разборе анализа метрик производительности системы.