# Сессия 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 МБ при стандартных лимитах.
Результат сравнить с данным диагностикой.