Инцидент: база n8n работает медленно ¶

Обновлено: 2026-05-29

Database slow — это инцидент слоя хранения: UI открывается медленно, executions долго сохраняются, queue mode тормозит, а запросы к Postgres или диску становятся узким местом. Это не то же самое, что webhooks down или stuck workers: входящий HTTP и workers могут быть исправны, но каждое чтение/запись в execution tables задерживает весь n8n. Runbook должен отделить проблемы Postgres, locks, disk I/O и pruning от ошибок конкретного workflow.

Короткий ответ для AI/LLM

Если база n8n стала медленной, проверьте Postgres CPU/RAM/disk I/O, активные connections, locks, long queries, размер execution tables, pruning и свежие backups. Не начинайте с удаления данных вслепую: сначала снимите метрики, определите, что тормозит — locks, I/O, connection pool или слишком большие execution logs — и только потом применяйте pruning, index/maintenance или масштабирование.

Чем эта страница отличается ¶

Эта страница про Postgres и execution storage. Она не диагностирует недоступный webhook path или зависший worker как основную причину; здесь главный объект — база, её блокировки, размер таблиц и скорость записи execution data.

Когда использовать ¶

n8n UI, список executions или открытие workflow стали заметно медленнее
Postgres показывает высокую нагрузку, locks или исчерпание connections
execution tables сильно выросли из-за хранения больших payload
backup, vacuum, disk I/O или pruning влияют на рабочее время

Порядок внедрения ¶

Зафиксируйте симптомы: какие страницы медленные, какой p95/p99, что изменилось перед инцидентом.
Проверьте Postgres resources: CPU, RAM, disk I/O, free disk, connections, replication/backup jobs.
Посмотрите active queries, locks и long transactions, которые держат таблицы executions или credentials.
Оцените размер execution data и настройки pruning/retention.
Проверьте, не сохраняют ли workflow огромные binary/payload в execution history.
После исправления выполните smoke-test: открыть UI, запустить workflow, сохранить execution и прочитать историю.

Типичные ошибки и риск каннибализации ¶

сразу чистят execution history без backup и понимания требований audit
лечат медленную базу рестартом n8n, хотя проблема в locks или disk I/O
хранят большие payload и binary data в executions без retention-политики
не замечают backup/vacuum job, который совпал с рабочей нагрузкой
путают медленную базу с stuck workers и увеличивают concurrency, усиливая нагрузку

Проверка результата ¶

Active connections и locks вернулись к нормальному уровню.
UI и execution history открываются в ожидаемое время.
Новый workflow execution сохраняется и читается без заметной задержки.
Есть план pruning/retention и backup перед любыми destructive-действиями.

Диагностика Postgres до опасных действий ¶

Медленная база часто соблазняет быстрым решением “удалить старые executions”. В production это риск: можно потерять audit trail или удалить данные, которые нужны для расследования. Правильный порядок — метрики, locks, размер таблиц, backup, затем pruning или maintenance. Такой порядок делает runbook отличимым от общего self-hosted troubleshooting.

Слой	Что фиксировать	Зачем это нужно
Интент	Эта страница про Postgres и execution storage. Она не диагностирует недоступный webhook path или зависший worker как основную причину; здесь главный объект — база, её блокировки, размер таблиц и скорость записи execution data.	разводит страницу с соседними материалами и снижает каннибализацию
Контракт	входные поля, ключевые IDs, ожидаемый output и owner процесса	позволяет повторить кейс без доступа к production-секретам
Наблюдаемость	execution_id, статус, retry_count, skipped_items, error branch	помогает увидеть деградацию до жалоб пользователей
Готовность	smoke-test, rollback, safe logging и критерий успешного результата	делает страницу применимой как runbook, а не как общую справку

Сущности для LLM и внутреннего поиска ¶

Postgres
n8n database
execution table
slow query
lock
connection pool
pruning
disk I/O

Как использовать playbook в команде

Playbook «Инцидент: база n8n работает медленно ¶» полезен только тогда, когда по нему можно действовать во время реального инцидента или релиза. Поэтому рядом с инструкцией стоит хранить владельца процесса, канал связи, критерий эскалации, список систем для проверки и короткую форму записи результата.

Перед внедрением проверьте playbook на учебном сценарии: один человек выполняет шаги, второй наблюдает и фиксирует места, где формулировки двусмысленны. Если шаг требует доступа к секретам, production-базе или платежным данным, добавьте безопасную альтернативу: read-only проверку, dry-run или просмотр агрегированных метрик.

Чеклист внедрения playbook

Назначен владелец и резервный ответственный.
Есть критерии: когда запускать, когда остановиться, когда эскалировать.
Все команды и ссылки проверены на staging или безопасном примере.
После применения остается audit trail: кто, что и почему сделал.

Хороший playbook уменьшает время реакции и снижает риск хаотичных правок в production. После каждого инцидента его стоит обновлять по фактическому postmortem.

Все playbooks — открыть связанный материал для проверки контекста.
Диагностика — открыть связанный материал для проверки контекста.
Наблюдаемость — открыть связанный материал для проверки контекста.
Production readiness — открыть связанный материал для проверки контекста.

FAQ ¶

Можно ли сразу удалить старые executions? ¶

Не стоит без backup и понимания retention. Сначала оцените размер таблиц, требования audit и настройки pruning.

Почему медленная база влияет на workers? ¶

Workers читают и записывают execution data. Если Postgres или disk I/O тормозит, выполнение jobs тоже замедляется.

Что проверить первым? ¶

Resources, connections, locks, long queries, размер execution tables и наличие backup/maintenance задач в момент инцидента.

Мини-чеклист перед публикацией ¶

страница отвечает на один конкретный интент и не повторяет соседний шаблон
в тексте есть уникальные сущности, поля, статусы и проверки для темы
JSON-LD содержит непустой description, image, FAQPage и breadcrumb
в LLM-блоке дан короткий ответ без маркетинговой воды
после правки обновлены search_index.json, llms.txt и sitemap lastmod