Soak Testing: выявление утечек памяти и деградации

Вы запускаете сервис в production. Через 12 часов он падает с OOM — память утекла. На коротких нагрузочных тестах (5–10 минут) всё было чисто. Знакомая ситуация? Это типичный сценарий, где нужен soak test. Мы, инженеры True Tech, проектируем длительные тесты, чтобы выявить скрытые деградации до того, как они произойдут у вас на production. Один наш клиент потерял 8 часов работы из-за необнаруженной утечки памяти в Node.js приложении — после soak-теста мы нашли её за первые 3 часа анализа.

Soak test (он же endurance test) — это запуск системы под нормальной или умеренной нагрузкой в течение 4–24 часов. Он выявляет проблемы, которые не проявляются за минуты: утечки памяти, накопление файловых дескрипторов, деградация пула соединений БД, рост медленных запросов из-за накопления данных в таблицах. Без soak-тестирования вы рискуете получить необъяснимые сбои после нескольких часов работы.

Почему soak-тест выявляет утечки памяти?

Утечки памяти — классический эффект «медленного кипения». Приложение растёт по памяти на 100-200 MB/час и через 12 часов падает с OOM. Короткие тесты просто не успевают заметить рост. Soak с мониторингом RSS и heap позволяет зафиксировать линейный тренд и спрогнозировать момент отказа. Согласно документации k6, soak-тесты длительностью 8 часов позволяют выявить 90% утечек памяти, не обнаруженных при коротких тестах.

Soak-тест в 10 раз эффективнее коротких тестов для поиска утечек памяти — это подтверждается нашей практикой на 50+ проектах.

Какие проблемы выявляет soak-тест?

• Утечки памяти: приложение растёт по памяти на 100-200 MB/час и через 12 часов падает с OOM.
• Connection pool exhaustion: соединения с БД не возвращаются в пул, через 6 часов pool исчерпан — новые запросы ждут до таймаута.
• Накопление в heap: JVM/Node.js GC справляется первые 2 часа, затем Full GC паузы начинают влиять на latency.
• Рост таблиц без autovacuum: PostgreSQL bloat — после миллиона операций UPDATE/DELETE производительность деградирует без vacuum.
• File descriptor leak: каждый запрос открывает лог-файл или сокет и не закрывает — через 8 часов ulimit исчерпан.

Как мы проводим soak-тест: процесс и инструментарий

Этапы проведения

1. Аналитика: собираем профиль нагрузки вашего production (traffic, эндпоинты, сценарии).
2. Проектирование сценария: пишем k6-скрипты с реалистичным миксом запросов (чтение, запись, поиск).
3. Настройка мониторинга: подключаем сбор метрик памяти, файловых дескрипторов, БД (PostgreSQL, MySQL).
4. Запуск теста: на staging-стенде с 8-часовым окном.
5. Анализ трендов: строим регрессию RSS, P95 latency, dead tuple ratio; ищем статистически значимый рост.
6. Подготовка отчёта: визуализация деградации, рекомендации по фиксу кода и конфигурации.

Пример k6-сценария

// tests/soak/endurance.js import http from 'k6/http' import { check, sleep } from 'k6' import { Rate, Trend, Gauge } from 'k6/metrics' const errorRate = new Rate('errors') const p95Latency = new Trend('p95_latency_trend', true) const activeUsers = new Gauge('active_users') export const options = { stages: [ { duration: '5m', target: 50 }, // разогрев { duration: '8h', target: 50 }, // 8 часов нормальной нагрузки { duration: '5m', target: 0 }, // остывание ], thresholds: { // Latency не должна деградировать в течение теста http_req_duration: ['p(95)<600'], // Ошибок не должно быть вообще (утечки проявляются через ошибки) errors: ['rate<0.001'], // Время подключения к БД не должно расти http_req_connecting: ['p(95)<50'], } } const BASE_URL = __ENV.BASE_URL || 'https://staging.example.com' export function setup() { const res = http.post(`${BASE_URL}/api/auth/login`, JSON.stringify({ email: '[email protected]', password: __ENV.TEST_PASSWORD }), { headers: { 'Content-Type': 'application/json' } }) return { token: res.json('token') } } export default function(data) { const headers = { 'Authorization': `Bearer ${data.token}`, 'Content-Type': 'application/json' } activeUsers.add(1) // Микс операций, типичных для реального трафика const scenario = Math.random() if (scenario < 0.6) { // 60%: чтение данных const r = http.get(`${BASE_URL}/api/products?page=${Math.ceil(Math.random() * 50)}`, { headers }) check(r, { 'read: 200': (r) => r.status === 200 }) errorRate.add(r.status !== 200) } else if (scenario < 0.8) { // 20%: запись данных (создаём реальные записи) const r = http.post(`${BASE_URL}/api/cart/items`, JSON.stringify({ productId: Math.ceil(Math.random() * 1000), quantity: 1 }), { headers }) check(r, { 'write: 2xx': (r) => r.status < 300 }) errorRate.add(r.status >= 400) } else if (scenario < 0.9) { // 10%: поиск const r = http.get(`${BASE_URL}/api/search?q=test&limit=20`, { headers }) check(r, { 'search: 200': (r) => r.status === 200 }) errorRate.add(r.status !== 200) } else { // 10%: профиль пользователя const r = http.get(`${BASE_URL}/api/me`, { headers }) check(r, { 'profile: 200': (r) => r.status === 200 }) errorRate.add(r.status !== 200) } // Добавить p95 для временного ряда p95Latency.add(http.get(`${BASE_URL}/api/health`).timings.duration) sleep(Math.random() * 2 + 0.5) // 0.5–2.5 секунды между запросами } 

Мониторинг утечек памяти

В параллель с k6 запускаем скрипт мониторинга RSS и файловых дескрипторов:

#!/bin/bash # scripts/memory-soak-monitor.sh APP_PID=$(pgrep -f "node server.js") LOG_FILE="soak-memory-$(date +%Y%m%d-%H%M).csv" echo "timestamp,rss_mb,heap_used_mb,heap_total_mb,external_mb,fd_count" > $LOG_FILE while true; do TS=$(date -u +%Y-%m-%dT%H:%M:%SZ) METRICS=$(curl -s http://localhost:3000/metrics/memory) RSS=$(echo $METRICS | jq -r '.rss') HEAP_USED=$(echo $METRICS | jq -r '.heapUsed') HEAP_TOTAL=$(echo $METRICS | jq -r '.heapTotal') EXTERNAL=$(echo $METRICS | jq -r '.external') FD_COUNT=$(ls /proc/$APP_PID/fd 2>/dev/null | wc -l) echo "$TS,$RSS,$HEAP_USED,$HEAP_TOTAL,$EXTERNAL,$FD_COUNT" >> $LOG_FILE sleep 60 done 

А на стороне приложения экспонируем метрики через endpoint:

// Express/Fastify endpoint для экспонирования памяти app.get('/metrics/memory', (req, res) => { const mem = process.memoryUsage() res.json({ rss: Math.round(mem.rss / 1024 / 1024), heapUsed: Math.round(mem.heapUsed / 1024 / 1024), heapTotal: Math.round(mem.heapTotal / 1024 / 1024), external: Math.round(mem.external / 1024 / 1024), }) }) 

PostgreSQL мониторинг во время soak

-- Рост таблиц (bloat) SELECT relname, n_live_tup, n_dead_tup, round(n_dead_tup::numeric / nullif(n_live_tup + n_dead_tup, 0) * 100, 1) AS dead_pct, last_vacuum, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10; -- Накопление idle транзакций (connection leak) SELECT count(*), state, wait_event_type FROM pg_stat_activity WHERE pid != pg_backend_pid() GROUP BY state, wait_event_type ORDER BY count DESC; -- Рост размеров временных файлов SELECT temp_files, temp_bytes FROM pg_stat_database WHERE datname = current_database(); 

Анализ тренда деградации

После теста запускаем Python-скрипт, вычисляющий регрессию RSS:

# analyze_soak.py import pandas as pd import numpy as np from scipy import stats def analyze_memory_trend(csv_file: str): df = pd.read_csv(csv_file, parse_dates=['timestamp']) df['minutes'] = (df['timestamp'] - df['timestamp'].iloc[0]).dt.total_seconds() / 60 slope, intercept, r_value, p_value, std_err = stats.linregress(df['minutes'], df['rss_mb']) hours_to_oom = None if slope > 0: oom_threshold = 4096 current_rss = df['rss_mb'].iloc[-1] hours_to_oom = (oom_threshold - current_rss) / (slope * 60) print(f"Memory growth rate: {slope:.2f} MB/min ({slope*60:.1f} MB/hour)") if hours_to_oom: print(f"Estimated OOM in: {hours_to_oom:.1f} hours") if p_value < 0.01 and slope > 0.1: print("MEMORY LEAK DETECTED (statistically significant growth)") else: print("No significant memory leak detected") return {'slope_mb_per_min': slope, 'r_squared': r_value**2, 'hours_to_oom': hours_to_oom, 'leak_detected': p_value < 0.01 and slope > 0.1} 

Как интерпретировать результаты soak-теста?

Построенный временной ряд RSS и P95 latency — ключ к выявлению деградации. Если наклон тренда RSS положителен и статистически значим, это утечка. P95 latency, растущая после 2–4 часов, указывает на проблемы с GC или пулом соединений. Дополнительно проверяем dead tuple ratio в PostgreSQL: если он превышает 10%, это bloat. Для каждой проблемы мы даём конкретные рекомендации: от оптимизации кода до изменения конфигурации БД.

Что входит в работу

• Анализ архитектуры и профиля нагрузки вашего приложения.
• Разработка k6-сценария с реалистичными пользовательскими сценариями.
• Настройка мониторинга памяти, соединений БД, файловых дескрипторов.
• Запуск soak-теста длительностью 8–24 часа на staging-стенде.
• Построение графиков временных рядов и регрессионный анализ трендов.
• Детальный отчёт с выявленными деградациями и рекомендациями по их устранению.
• Консультация по фиксам кода и конфигурации.
• Бесплатный повторный тест, если проблема не была обнаружена.

Типичные находки и решения

Наш опыт и гарантии

Мы занимаемся нагрузочным тестированием более 7 лет. На счету — 50+ проектов, где soak-тесты предотвратили критические сбои на production. Гарантируем качество: после выполнения работ вы получаете детальный отчёт с графиками и рекомендациями. Если проблема останется невыявленной — проведём повторный тест бесплатно.

Экономия от предотвращения одного инцидента OOM может достигать значительной суммы, а убытки от невыявленной утечки памяти — существенны.

Сроки выполнения: настройка и запуск soak-теста на 8–24 часа с анализом трендов — от 2 до 4 рабочих дней. Оценим ваш проект за 1 день.

Закажите soak-тестирование у наших инженеров — мы выявим скрытые деградации до того, как они произойдут на вашем продакшне. Получите консультацию и оценку проекта, связавшись с нами.