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