Сессия 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. Варианты решения (НЕ ВНЕСЕНЫ, ждут команды)

Поднять память инстанса: clusterConfiguration.memory 1024 → 2048 (быстрый обходной путь).
Убрать синхронный парсинг из /upload — парсинг в фон (thread / отдельный endpoint), ответ сразу; снижает пик памяти в запросе (правильный фикс).
Оба варианта.

6. Статус (следующий шаг)

Пользователь планирует редеплой на обычном облачном кластере со стандартными настройками (не на своём iot-naeel) — проверить, как ведёт себя парсинг 19 МБ при стандартных лимитах. Результат сравнить с данным диагностикой.

3.7 KiB Raw Permalink Blame History Unescape Escape