- Исправлена потеря документов при обновлении черновика (SQL объединяет вместо перезаписи) - Исправлено определение типа документа (приоритет field_label над field_name) - Исправлены дубликаты в documents_meta и documents_uploaded - Добавлена передача group_index с фронтенда для правильного field_name - Исправлены все документы в таблице clpr_claim_documents с правильными field_name - Обновлены SQL запросы: claimsave и claimsave_final для нового флоу - Добавлена поддержка multi-file upload для одного документа - Исправлены дубликаты в списке загруженных документов на фронтенде Файлы: - SQL: SQL_CLAIMSAVE_FIXED_NEW_FLOW.sql, SQL_CLAIMSAVE_FINAL_FIXED_NEW_FLOW_WITH_UPLOADED.sql - n8n: N8N_CODE_PROCESS_UPLOADED_FILES_FIXED.js (поддержка group_index) - Backend: documents.py (передача group_index в n8n) - Frontend: StepWizardPlan.tsx (передача group_index, исправление дубликатов) - Скрипты: fix_claim_documents_field_names.py, fix_documents_meta_duplicates.py Результат: документы больше не теряются, имеют правильные типы и field_name
9.4 KiB
9.4 KiB
🐛 Проблемы с памятью в n8n
🔍 Симптомы
- UI n8n не отвечает (нельзя сохранить workflow, включить/выключить)
- Workflow не обрабатывает события
- Страница зависает при попытке редактирования
- Требуется перезагрузка сервера для восстановления
💾 Возможные причины
1. Переполнение памяти (OOM)
- n8n процесс исчерпал доступную память
- Система убивает процесс (OOM Killer)
- Или процесс зависает в ожидании освобождения памяти
Диагностика:
# Проверка использования памяти n8n
docker stats n8n_container --no-stream
# Проверка логов OOM Killer
dmesg | grep -i "out of memory"
dmesg | grep -i "killed process"
# Проверка использования памяти системой
free -h
2. Утечки памяти в workflow
- Workflow накапливает данные в памяти
- Большие массивы данных не освобождаются
- Долгие операции держат данные в памяти
Диагностика:
- Проверить Execution History - сколько данных хранится
- Проверить размер данных в workflow (большие JSON объекты)
- Проверить количество активных executions
3. Слишком много активных workflows
- Много workflows работают одновременно
- Каждый workflow держит соединения и данные в памяти
- Redis Trigger для каждого workflow = отдельное соединение
Диагностика:
# Количество активных workflows (через n8n API или БД)
# Проверить количество Redis подписок
redis-cli -h crm.clientright.ru -p 6379 -a "CRM_Redis_Pass_2025_Secure!" CLIENT LIST | grep -c "SUBSCRIBE"
4. Большие данные в workflow
- Workflow обрабатывает большие файлы/JSON
- Данные хранятся в памяти между нодами
- Нет очистки промежуточных данных
Диагностика:
- Проверить размер данных в Execution History
- Проверить размер JSON payload между нодами
- Проверить использование диска для execution data
5. Проблемы с базой данных n8n
- База данных n8n переполнена старыми executions
- Медленные запросы блокируют работу
- Блокировки таблиц
Диагностика:
# Размер базы данных n8n
# Проверить количество executions
# Проверить медленные запросы
🛠️ Решения
1. Ограничить использование памяти
В docker-compose.yml для n8n:
services:
n8n:
mem_limit: 2g # Ограничить память до 2GB
mem_reservation: 1g # Резервировать минимум 1GB
oom_kill_disable: false # Разрешить OOM Killer убивать процесс
Или через переменные окружения:
NODE_OPTIONS="--max-old-space-size=1536" # Ограничить heap до 1.5GB
2. Очистить старые executions
Настроить автоматическую очистку в n8n:
- Settings → Workflows → Execution Data Retention
- Установить срок хранения (например, 7 дней)
- Включить автоматическую очистку
Или через SQL (если используете PostgreSQL):
-- Удалить executions старше 7 дней
DELETE FROM execution_entity
WHERE "stoppedAt" < NOW() - INTERVAL '7 days';
-- Удалить execution_data для удалённых executions
DELETE FROM execution_data
WHERE "executionId" NOT IN (SELECT id FROM execution_entity);
3. Оптимизировать workflow
-
Не хранить большие данные между нодами
- Использовать
Setnode для очистки ненужных полей - Не передавать большие файлы через workflow data
- Использовать
-
Использовать streaming для больших данных
- Обрабатывать данные порциями
- Не загружать всё в память сразу
-
Ограничить размер данных в Redis Trigger
- Проверять размер сообщения перед обработкой
- Отклонять слишком большие сообщения
4. Мониторинг памяти
Создать скрипт для мониторинга:
#!/bin/bash
# monitor_n8n_memory.sh
CONTAINER="n8n_container"
THRESHOLD=80 # Процент использования памяти
MEMORY_USAGE=$(docker stats $CONTAINER --no-stream --format "{{.MemPerc}}" | sed 's/%//')
if (( $(echo "$MEMORY_USAGE > $THRESHOLD" | bc -l) )); then
echo "⚠️ ВНИМАНИЕ: n8n использует ${MEMORY_USAGE}% памяти!"
# Можно добавить отправку алерта
fi
5. Настроить swap
Если сервер имеет swap, убедиться что он настроен:
# Проверить swap
swapon --show
# Если нет swap, создать (осторожно - может замедлить работу)
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
6. Ограничить количество активных workflows
- Отключить неиспользуемые workflows
- Использовать один workflow вместо нескольких для похожих задач
- Разделить сложные workflows на несколько простых
7. Оптимизировать Redis Trigger
- Использовать один Redis Trigger для нескольких каналов (если возможно)
- Ограничить количество одновременных подписок
- Использовать Redis Streams вместо Pub/Sub для больших объёмов данных
📊 Диагностика после перезагрузки
После перезагрузки сервера проверить:
# 1. Использование памяти n8n
docker stats n8n_container --no-stream
# 2. Логи n8n на ошибки памяти
docker logs n8n_container 2>&1 | grep -i "memory\|oom\|heap"
# 3. Системные логи OOM Killer
dmesg | grep -i "out of memory" | tail -20
# 4. Использование памяти системой
free -h
# 5. Топ процессов по использованию памяти
ps aux --sort=-%mem | head -10
🔄 Профилактика
-
Регулярная очистка executions
- Настроить автоматическую очистку старых данных
- Ограничить срок хранения execution data
-
Мониторинг ресурсов
- Настроить алерты при высоком использовании памяти
- Регулярно проверять использование ресурсов
-
Оптимизация workflows
- Избегать хранения больших данных в памяти
- Использовать streaming для больших файлов
- Очищать промежуточные данные
-
Ограничения ресурсов
- Установить лимиты памяти для n8n контейнера
- Настроить OOM Killer для корректной обработки
-
Резервирование
- Рассмотреть использование нескольких инстансов n8n
- Использовать load balancer для распределения нагрузки
📝 Рекомендации для продакшена
- Мониторинг: Настроить Prometheus/Grafana для мониторинга памяти
- Алерты: Настроить уведомления при превышении порога памяти
- Автоматическая очистка: Настроить cron для очистки старых executions
- Лимиты: Установить жёсткие лимиты памяти для n8n
- Логирование: Включить детальное логирование использования памяти