Docs: диагностика HTTP 502 на 19МБ PDF — OOMKill пода (лимит 1Gi)
Deploy contracts-flask / validate (push) Canceled after 0s
Deploy contracts-flask / validate (push) Canceled after 0s
This commit is contained in:
@@ -0,0 +1,71 @@
|
|||||||
|
# Сессия 2026-08-17 — HTTP 502 при парсинге 19 МБ PDF = OOMKill пода
|
||||||
|
|
||||||
|
_Стенд: ТЕСТ, `contractor.pythonk8s.dev.nubes.ru` (приставка `dev.nubes.ru` общая для dev+test).
|
||||||
|
instanceUid: `b4523aba-b5e6-40f1-be56-bb4d2509357c`, realm `iot-naeel`, domain `contractor`._
|
||||||
|
|
||||||
|
## 1. Симптом (из UI, колонка «Парсинг»)
|
||||||
|
|
||||||
|
Файл `0144-03-2023_отчет об оценке.pdf` (19.0 МБ) в списке **дважды**:
|
||||||
|
- первый проход: **✗ HTTP 502**;
|
||||||
|
- повторный: **✓ 4083 эл. (0.0с)**.
|
||||||
|
|
||||||
|
Остальные файлы (623 КБ, 473 КБ, 596 КБ) парсились нормально.
|
||||||
|
Вывод: загрузка файла проходит, падает **парсинг** (тяжёлая операция в запросе).
|
||||||
|
|
||||||
|
## 2. Диагностика kubectl (с ВМ remote-dev = 5.172.178.213)
|
||||||
|
|
||||||
|
```
|
||||||
|
kubectl get pods -n b4523aba-...
|
||||||
|
pythonk8s-589db8db9c-qjjnc 1/1 Running 1 (5m18s ago) 17m
|
||||||
|
```
|
||||||
|
|
||||||
|
`kubectl describe pod`:
|
||||||
|
```
|
||||||
|
Last State: Terminated
|
||||||
|
Reason: OOMKilled
|
||||||
|
Exit Code: 137
|
||||||
|
Restart Count: 1
|
||||||
|
Limits: cpu: 1, memory: 1Gi
|
||||||
|
Requests: cpu: 1, memory: 1Gi
|
||||||
|
```
|
||||||
|
|
||||||
|
`kubectl top pod` (текущий под, простое): **727Mi из 1Gi (~71%)**.
|
||||||
|
|
||||||
|
События:
|
||||||
|
```
|
||||||
|
17m Killing pod/pythonk8s-5895c478b5-7dcqq — Stopping container app
|
||||||
|
```
|
||||||
|
(убитый OOM-ом под; текущий `pythonk8s-589db8db9c-qjjnc` — новый).
|
||||||
|
|
||||||
|
Логи прежнего контейнера (`--previous`): обычные запросы (health, batch-progress,
|
||||||
|
apply-groups, process-v2, cleanup), обрыв на 14:13:14 → OOM.
|
||||||
|
|
||||||
|
## 3. Вывод (по фактам)
|
||||||
|
|
||||||
|
**HTTP 502 = OOMKill пода (exit 137).** Синхронный парсинг 19 МБ PDF
|
||||||
|
(`site/routes/upload_bp.py`: `parse_file` → `set_parsed` в том же запросе,
|
||||||
|
pdfplumber → 4083 элемента) превышает лимит памяти **1Gi** → kubelet убивает под →
|
||||||
|
шлюз не получает ответ → 502. После рестарта повторный парсинг проходит.
|
||||||
|
|
||||||
|
- **Это НЕ** проблема сети/размера тела (как 64KB на `services`), а **нехватка памяти**.
|
||||||
|
- Базовое потребление уже ~71% лимита, парсинг большого PDF добивает под.
|
||||||
|
|
||||||
|
## 4. Связь с прежними находками
|
||||||
|
|
||||||
|
| Симптом | Причина | Платформа |
|
||||||
|
|---|---|---|
|
||||||
|
| «64KB / HTTP 000, Сеть» (исторически) | ddos-guard + таймауты Ingress + медленная обработка | `pythonk8s.services.ngcloud.ru` |
|
||||||
|
| HTTP 502 на 19 МБ PDF (сейчас) | OOMKill: лимит 1Gi, синхронный парсинг | `pythonk8s.dev.nubes.ru` (ТЕСТ) |
|
||||||
|
|
||||||
|
## 5. Варианты решения (НЕ ВНЕСЕНЫ, ждут команды)
|
||||||
|
|
||||||
|
1. Поднять память инстанса: `clusterConfiguration.memory` 1024 → 2048 (быстрый обходной путь).
|
||||||
|
2. Убрать синхронный парсинг из `/upload` — парсинг в фон (thread / отдельный endpoint),
|
||||||
|
ответ сразу; снижает пик памяти в запросе (правильный фикс).
|
||||||
|
3. Оба варианта.
|
||||||
|
|
||||||
|
## 6. Статус (следующий шаг)
|
||||||
|
|
||||||
|
Пользователь планирует **редеплой на обычном облачном кластере со стандартными настройками**
|
||||||
|
(не на своём `iot-naeel`) — проверить, как ведёт себя парсинг 19 МБ при стандартных лимитах.
|
||||||
|
Результат сравнить с данным диагностикой.
|
||||||
Reference in New Issue
Block a user