Ответ
Первым делом я смотрю на дашборды в Grafana, подключенные к Prometheus, чтобы определить масштаб проблемы: это внезапный скачок или постепенный рост (утечка). Ключевые метрики — container_memory_working_set_bytes и container_memory_usage_bytes для контейнеров или process_resident_memory_bytes для процессов.
Далее я анализирую логи в централизованной системе, например, в ELK-стеке или Grafana Loki, ищу ошибки OutOfMemoryError или предупреждения от сборщика мусора (GC).
Если проблема неочевидна, подключаю профилировщик. Для Java-приложений использую jcmd <pid> GC.heap_dump для создания дампа и анализирую его в Eclipse MAT или VisualVM. Для Go — pprof с эндпоинта /debug/pprof/heap.
Немедленные действия в оркестраторе:
# В манифесте Pod в Kubernetes устанавливаю/корректирую лимиты
spec:
containers:
- name: app
resources:
requests:
memory: "512Mi"
limits:
memory: "1Gi"Параллельно проверяю, не исчерпаны ли квоты на namespace (kubectl describe resourcequota).
Поиск причины в коде/конфигурации:
- Проверяю настройки кэшей (например, в Redis или in-memory кэше приложения) на наличие неограниченного TTL.
- Ищу утечки в соединениях с БД или внешними API, которые не закрываются в finally-блоке.
- Анализирую, не загружаются ли в память большие файлы или datasets целиком вместо потоковой обработки.
Если проблема в высокой нагрузке, рассматриваю горизонтальное масштабирование (увеличение реплик) и настройку HPA на основе потребления памяти.