--- title: "Инцидент: база n8n работает медленно — Nodbot" source_url: "https://nodbot.ru/playbooks/incident-triage-database-slow/" canonical_url: "https://nodbot.ru/playbooks/incident-triage-database-slow/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 854 --- # Инцидент: база n8n работает медленно ## AI summary Runbook для slow database в n8n: Postgres connections, locks, slow queries, execution table, pruning, disk I/O, backups, pool и безопасное восстановление. ## Best used for Страница объясняет «Инцидент: база n8n работает медленно — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Чем эта страница отличается - Когда использовать - Порядок внедрения - Типичные ошибки и риск каннибализации - Проверка результата - Диагностика Postgres до опасных действий - Сущности для LLM и внутреннего поиска - Как использовать playbook в команде ## Source outline # Инцидент: база 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 ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.