Docs: диагностика HTTP 502 на 19МБ PDF — OOMKill пода (лимит 1Gi)

2026-08-17 18:32:06 +04:00
parent 956aed0971
commit 4653aa5e8e
1 changed files with 71 additions and 0 deletions
@@ -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 МБ при стандартных лимитах.
+Результат сравнить с данным диагностикой.