Бинарные данные: Filesystem/S3 вместо базы данных
Бинарные данные в оперативной памяти или в базе данных замедляют n8n. Режимы filesystem и S3 решают эту проблему с помощью подходящих переменных.
n8n хранит бинарные данные в оперативной памяти: 100 PDF-файлов могут привести к сбою сервера. Как режим Filesystem или S3 помогает справиться со взрывным ростом потребления памяти.
Когда workflow вдруг должен обработать сразу 100 PDF-файлов, на бумаге это выглядит как простая задача: прочитать файлы, извлечь текст, передать дальше. На практике именно такой workflow часто падает прямо посреди выполнения, контейнер n8n перезапускается, а в логе остается лишь сухая запись "Out of memory". Причина почти всегда одна и та же: n8n по умолчанию хранит бинарные данные в оперативной памяти, а не на диске.
При обработке отдельных файлов или небольших изображений это почти незаметно. Но как только вы обрабатываете за один запуск десятки или сотни PDF-файлов, сканов или вложений, каждый отдельный файл добавляется к потреблению оперативной памяти процессом, пока сервер или контейнер не достигнет своего предела. Этого можно стабильно избежать, не перестраивая сам workflow, если вы знаете, за какой рычаг нужно потянуть. Эта статья показывает, почему возникает взрывной рост потребления памяти и как взять его под контроль с помощью правильного режима бинарных данных.
Технически n8n различает собственно поток данных workflow и так называемые бинарные данные, то есть файлы вроде PDF, изображений или вложений Excel, проходящие через workflow. Согласно официальной документации по бинарным данным n8n по умолчанию хранит эти данные в оперативной памяти, что не создает проблем при небольших объемах данных, но при больших файлах или большом количестве файлов одновременно быстро приводит к проблемам производительности. При этом встроенного ограничителя нет: n8n не ограничивает ни то, сколько файлов workflow держит одновременно, ни автоматически не резервирует память для узла. Workflow, который считывает 100 PDF-файлов из почтового ящика или папки и обрабатывает их с помощью узла Extract from File, может из-за этого файл за файлом занимать все больше оперативной памяти, пока контейнер не достигнет своего лимита и не аварийно завершится.
Именно такую картину описывает и один пользователь на форуме сообщества n8n: при миграции около 2000 записей, у каждой из которых было от 150 до 200 вложений, workflow на VPS с 8 ГБ памяти регулярно завершался аварийно примерно после 50 обработанных файлов, потому что режим по умолчанию хранил все бинарные данные в оперативной памяти. При 100 PDF-файлах эффект тот же, что и при 2000 вложениях, просто он проявляется быстрее, если ваш сервер и без того рассчитан впритык.
n8n предлагает несколько режимов хранения бинарных данных, которые управляются переменной окружения `N8N_DEFAULT_BINARY_DATA_MODE`:
Важно для конфигураций с несколькими воркерами: согласно документации, n8n не поддерживает режим Filesystem в режиме очереди, там вместо этого нужно использовать режим базы данных, если только не доступно общее хранилище.
Для большинства конфигураций с одним инстансом достаточно переключить режим на Filesystem:
Пользователь сообщества из упомянутой выше темы описывает эффект так: после перехода кривая потребления памяти стабильно оставалась низкой, а прежний всплеск полностью исчез. Для workflow, обрабатывающего 100 PDF-файлов подряд, этого обычно уже достаточно как полного решения, причем без каких-либо изменений кода в самом workflow.
Если ваш инстанс n8n работает в режиме очереди с несколькими воркерами на отдельных машинах, локальное дисковое хранилище помогает лишь отчасти, поскольку не каждый воркер автоматически имеет доступ к одним и тем же файлам. Для этого случая документация по внешнему хранилищу описывает подключение S3. Настраивается оно через несколько переменных окружения:
Важно знать: согласно документации, подключение S3 требует действующей лицензии Enterprise, без которой n8n не запускается в этом режиме. Кроме того, вам стоит настроить в bucket политику жизненного цикла, которая автоматически удаляет старые бинарные данные, поскольку сам n8n там не выполняет очистку.
Даже с режимом Filesystem или S3 ваша потребность в хранилище продолжит расти, если старые выполнения никогда не удаляются. Документация по управлению данными выполнений описывает для этого следующие переменные:
Деталь, которую легко упустить: согласно документации, очистка всегда действует только на текущий активный режим бинарных данных. Если вы переключитесь с Filesystem на S3, старые файлы могут остаться на локальном диске, и их придется удалять вручную.
Если вы не уверены, какой режим подходит вашей конфигурации, или существующий workflow n8n регулярно падает при больших объемах PDF-файлов, мы с удовольствием разберем это вместе в рамках нашей автоматизации n8n. Как цифровые сотрудники, мы один раз аккуратно настроим конфигурацию, задокументируем ее и передадим вам так, чтобы вы сохраняли контроль над ресурсами вашего сервера.
Потому что в режиме по умолчанию каждый отдельный файл занимает дополнительную оперативную память. При небольшом количестве маленьких файлов остается достаточно запаса, но с каждым следующим PDF в том же запуске потребление оперативной памяти продолжает расти, пока доступная память контейнера или сервера не исчерпается и процесс не завершится аварийно.
В большинстве конфигураций с одним инстансом — да, поскольку в этом случае файлы хранятся на диске, а не в оперативной памяти, и потребление RAM на одно выполнение существенно снижается. Если вы работаете в режиме очереди с несколькими отдельными воркерами, вам дополнительно понадобится либо общее хранилище, либо режим S3, поскольку там n8n не поддерживает режим Filesystem.
Да. Согласно официальной документации, подключение S3 для бинарных данных привязано к действующей лицензии Enterprise, без которой инстанс не запускается в режиме S3. Для небольших конфигураций без нескольких машин-воркеров бесплатный режим Filesystem, как правило, является более простым и достаточным решением.
n8n не очищает папку автоматически, а связывает очистку с настройками pruning данных выполнений, такими как `EXECUTIONS_DATA_PRUNE` и `EXECUTIONS_DATA_MAX_AGE`. Если pruning включен, старые выполнения вместе с их бинарными данными в активном режиме регулярно удаляются, а при отключенном pruning папка растет неограниченно.
NordFlux создаёт цифровых сотрудников для организаций: автоматизации и КИ-агентов, которые берут на себя повторяющуюся работу. Вы сохраняете контроль.
Бинарные данные в оперативной памяти или в базе данных замедляют n8n. Режимы filesystem и S3 решают эту проблему с помощью подходящих переменных.
Как n8n с помощью MCP Server Trigger и MCP Client предоставляет workflow в качестве инструментов для Claude или использует внешние MCP-серверы.
Как установить n8n с помощью Docker Compose: Postgres вместо SQLite, .env, тома и обновления шаг за шагом.
Режим Filesystem или S3 для двоичных данных настраивается быстро, но кто-то должен постоянно следить за расходом памяти и данными выполнения, чтобы следующая партия PDF снова всё не заблокировала. NordFlux берёт на себя управляемую эксплуатацию вашего n8n на вашей инфраструктуре или в нашем хостинге, включая мониторинг памяти и автоматическую очистку старых данных выполнения. На первой встрече мы рассмотрим вашу текущую конфигурацию двоичных данных.