Сервис показывает стабильные p95 и пропускную способность первые 20 минут, затем постепенно ухудшается при неизменной нагрузке. Какой класс причин следует проверить первым?
В первую очередь следует проверить накопительное исчерпание ресурса: утечку памяти или соединений, рост очереди, незакрытые файловые дескрипторы, неограниченное увеличение кэша либо постепенную деградацию сборки мусора. Такая динамика указывает не на мгновенное достижение предельной производительности, а на состояние, которое ухудшается со временем.
Короткий нагрузочный тест хорошо выявляет проблемы пропускной способности и задержки при установившейся нагрузке, но может не обнаружить дефекты жизненного цикла ресурсов. Поэтому в практике появились длительные soak-тесты: они предназначены для поиска деградации, проявляющейся только после накопления состояния.
Исходная проблема таких тестов — отличить временный прогрев от постепенного ухудшения. Для этого нагрузку удерживают стабильной дольше обычного и анализируют не только итоговые значения, но и временной тренд метрик.
Если остановить тест через первые 20 минут, система будет ошибочно признана стабильной. В эксплуатации это может привести к росту задержки, исчерпанию памяти или пулов, увеличению числа ошибок и последующему перезапуску экземпляров.
Нельзя автоматически считать причиной именно утечку памяти. Похожую картину создают медленно растущая очередь, исчерпание пула соединений, накопление элементов в кэше, деградация базы данных или внешнего сервиса. Главный признак — зависимость ухудшения от прошедшего времени при неизменной интенсивности нагрузки.
Сначала нужно проверить временные ряды p95/p99, пропускной способности, ошибок и тайм-аутов. Затем их следует сопоставить с RSS и размером управляемой памяти, частотой и длительностью сборок мусора, количеством открытых соединений и файловых дескрипторов, длиной очередей, размером кэшей и утилизацией CPU.
Важна форма изменения метрик. Постепенный рост памяти с восстановлением после перезапуска указывает на накопление состояния; рост очереди при стабильной скорости обработки — на утечку или задержку потребителя; увеличение времени сборки мусора — на давление на память; снижение числа доступных соединений — на их незакрытие или слишком медленное освобождение.
Полезно повторить тест после принудительного возврата сервиса в исходное состояние. Если деградация исчезает после перезапуска и снова появляется через сопоставимый интервал, это усиливает гипотезу о накопительном дефекте, но само по себе не доказывает конкретный тип утечки.
Следует также исключить внешние причины: изменение нагрузки из-за генератора, нестабильность базы данных, фоновые задания и лимиты контейнера. Сравнение нескольких прогонов повышает достоверность вывода, а раздельный анализ экземпляров помогает обнаружить проблему, скрытую средними значениями кластера.
При постоянной нагрузке p95 API начал расти через полчаса, а RSS экземпляров увеличивался почти линейно. Рассматривались три варианта: увеличить память, чаще перезапускать экземпляры или найти источник накопления состояния. Увеличение памяти могло лишь отсрочить отказ, а регулярные перезапуски уменьшили бы последствия, но скрыли дефект.
Выбранным решением стала корреляция роста памяти с конкретными типами операций и проверка снимков памяти на нескольких этапах теста. После устранения удерживаемых объектов RSS стабилизировался, частота сборок мусора снизилась, а p95 перестал расти в течение длительного прогона. Перезапуск оставили как защитный механизм, но не как замену исправлению причины.
Как отличить утечку памяти от обычного прогрева кэша?
Нужно смотреть не только на рост памяти, но и на достижение устойчивого уровня. При прогреве кэш обычно увеличивается до ограниченного размера, после чего память стабилизируется; при утечке или неограниченном кэше рост продолжается при неизменной нагрузке. Полезны повторный прогон, очистка кэша и проверка поведения после штатного освобождения объектов.
Может ли стабильный p95 скрывать накопительную проблему?
Да. Средние и процентильные задержки могут оставаться приемлемыми, пока свободный ресурс ещё не исчерпан. При этом уже могут расти RSS, длина очереди, время сборки мусора или число занятых соединений, поэтому одних SLA-метрик недостаточно для оценки длительной стабильности.
Почему повторный запуск теста с той же нагрузкой не всегда подтверждает дефект?
Результат может зависеть от состояния внешних систем, кэшей, фоновых задач и планирования сборки мусора. Если деградация появляется только в одном прогоне, нужна проверка воспроизводимости и контроль условий. Надёжный вывод строится на повторяющемся временном паттерне, корреляции с ресурсной метрикой и эксперименте, который устраняет или изменяет предполагаемую причину.