Staging: memory 4Gi, maxReplicas=3 #208

claude · 2026-02-21T08:28:28+01:00

claude commented

2026-02-21 08:28:28 +01:00

Fix OOMKilled on yearly reports

claude added 1 commit 2026-02-21 08:28:28 +01:00

Staging: memory 4Gi, maxReplicas=3 (fix OOMKilled)

AI Review / AI Code Review (pull_request) Successful in 1s

Details

PR Checks / Validate & Security Scan (pull_request) Successful in 8s

Details

c9605d09ee

Yearly report needs ~2.7GB RAM. With 2Gi limit, pod OOMKilled.
3 replicas × (2 CPU, 4Gi) = 6 CPU, 12Gi — fits staging-quota.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

admin approved these changes 2026-02-21 08:28:28 +01:00

claude commented

2026-02-21 08:28:40 +01:00

AI Code Review

Обзор PR: staging-memory-4gi

Статус: ✅ Одобрено с замечаниями

Проблемы

⚠️ Снижение maxReplicas с 4 → 3: Странный выбор для fix OOMKilled. Обычно увеличивают реплики, чтобы распределить нагрузку. Нужна история: были ли проблемы с 4 репликами? Если это намеренно (бюджет/ресурсы), упомяните в описании PR.
ℹ️ Отсутствует контекст: PR не объясняет, почему именно 1Gi request и 4Gi limit. Годовые отчеты — тяжелая работа, но:
- Достаточно ли 1Gi request для production-подобного staging?
- 4x margin (request→limit) — типичный для batch-jobs, но проверьте на HPA срабатывание.

Что хорошо

✅ Requests + limits присутствуют
✅ CPU не трогал (разумно, OOM != CPU)
✅ Оба параметра (request & limit) увеличены пропорционально

Рекомендации

Тестирование: Запустите нагрузочный тест годового отчёта на staging с 1Gi request. Проверьте:
- Не было ли OOMKilled с новыми лимитами?
- HPA реагирует корректно при targetCPUUtilizationPercentage=70?

Обновите описание PR:

Fix OOMKilled on yearly reports

- memory request: 512Mi → 1Gi
- memory limit: 2Gi → 4Gi
- maxReplicas: 4 → 3 (ресурсный бюджет staging)

Monitoring: Добавьте алерт на близость к лимиту:
```
container_memory_usage_bytes > 3.5Gi for 2m
```
Долгосрок: Профилируйте отчёт (pprof/metrics) — возможна утечка памяти.

Proceed with merge если тесты пройдены и maxReplicas=3 — осознанное решение по ресурсам.

Automated review by Claude Haiku | advisory, does not block merge

## AI Code Review # Обзор PR: staging-memory-4gi **Статус:** ✅ **Одобрено с замечаниями** ## Проблемы - **⚠️ Снижение maxReplicas с 4 → 3:** Странный выбор для fix OOMKilled. Обычно увеличивают реплики, чтобы распределить нагрузку. Нужна история: были ли проблемы с 4 репликами? Если это намеренно (бюджет/ресурсы), упомяните в описании PR. - **ℹ️ Отсутствует контекст:** PR не объясняет, *почему* именно 1Gi request и 4Gi limit. Годовые отчеты — тяжелая работа, но: - Достаточно ли 1Gi request для production-подобного staging? - 4x margin (request→limit) — типичный для batch-jobs, но проверьте на HPA срабатывание. ## Что хорошо - ✅ Requests + limits присутствуют - ✅ CPU не трогал (разумно, OOM != CPU) - ✅ Оба параметра (request & limit) увеличены пропорционально ## Рекомендации 1. **Тестирование:** Запустите нагрузочный тест годового отчёта на staging с 1Gi request. Проверьте: - Не было ли OOMKilled с новыми лимитами? - HPA реагирует корректно при targetCPUUtilizationPercentage=70? 2. **Обновите описание PR:** ``` Fix OOMKilled on yearly reports - memory request: 512Mi → 1Gi - memory limit: 2Gi → 4Gi - maxReplicas: 4 → 3 (ресурсный бюджет staging) ``` 3. **Monitoring:** Добавьте алерт на близость к лимиту: ```yaml container_memory_usage_bytes > 3.5Gi for 2m ``` 4. **Долгосрок:** Профилируйте отчёт (pprof/metrics) — возможна утечка памяти. --- **Proceed with merge** если тесты пройдены и maxReplicas=3 — осознанное решение по ресурсам. --- _Automated review by Claude Haiku | advisory, does not block merge_

claude merged commit 3dd6d4920e into main

2026-02-21 08:28:50 +01:00

claude referenced this issue from a commit

2026-02-21 08:28:50 +01:00

Merge pull request 'Staging: memory 4Gi, maxReplicas=3' (#208) from staging-memory-4gi into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: claude/k8s-apps#208