Databáze řešení

После нескольких поисков или загрузки PDF Open WebUI занимает почти всю оперативную память, а перезапуск помогает ненадолго? Сначала выясните, какой компонент растёт: сам Open WebUI, модель в Ollama, обработчик документов или векторная база. Для веб-поиска можно проверить обход индексации результатов; для загрузки файлов нужно отдельно проверить извлечение текста, эмбеддинги и хранение индекса.

Ниже — порядок диагностики для самостоятельной установки Open WebUI в Docker на Linux. Потребуются доступ по SSH и права администратора Open WebUI. Названия полей могут различаться между версиями; рядом с ними приведены имена параметров. Для собственной функции, инструмента или Pipeline дополнительно проверяйте её процесс и зависимости.

1. Найдите процесс, который занимает память

Облачная языковая модель не означает, что вся обработка вынесена с сервера. При работе с документами Open WebUI извлекает текст, делит его на фрагменты, создаёт эмбеддинги — числовые представления текста — и записывает их в векторную базу. Затем RAG, то есть поиск подходящих фрагментов для ответа модели, использует этот индекс.

Если выбран локальный SentenceTransformers, модель эмбеддингов работает внутри Open WebUI. Ollama и внешний обработчик документов могут работать в отдельных контейнерах на том же VPS. Поэтому смотрите потребление всех компонентов:

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
free -h
docker stats --no-stream

Выполняйте команды на сервере, а не внутри контейнера. Запишите версию Open WebUI из интерфейса и образ из вывода Docker. Ниже имя контейнера — open-webui; замените его своим.

Для сравнения используйте один и тот же показатель: в Linux docker stats вычитает часть файлового кеша, поэтому его цифры могут отличаться от панели мониторинга. Если серверные показатели стабильны, а память растёт только у вкладки браузера, исследовать нужно клиентскую часть.

2. Подтвердите нехватку памяти и сохраните следы сбоя

docker inspect open-webui --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}} Restarts={{.RestartCount}} MemoryLimit={{.HostConfig.Memory}}'
docker logs --since 30m --timestamps --tail 200 open-webui
sudo journalctl -k --since "30 minutes ago" --no-pager | grep -Ei 'out of memory|oom-kill|killed process'

Последняя команда рассчитана на Linux с systemd и доступом к журналу ядра. OOMKilled=true указывает на завершение из-за нехватки памяти; сопоставьте время с загрузкой файла и сообщениями ядра. После перезапусков одного текущего состояния контейнера может быть недостаточно — сохраните журнал.

MemoryLimit указан в байтах. Значение 0 означает отсутствие установленного жёсткого лимита Docker. При ненулевом лимите контейнер может столкнуться с OOM, даже когда на VPS ещё есть свободная память.

Код завершения 137 сам по себе не доказывает OOM: процесс могли принудительно остановить. Сообщение Child process died тоже требует проверки. Документация Open WebUI отдельно разбирает сбои при нескольких рабочих процессах и локальной ChromaDB. Если вы увеличивали UVICORN_WORKERS с этой базой, вернитесь к одному процессу для диагностики; изменение применяйте в окно обслуживания.

Если сервер уже теряет доступность, остановите новые загрузки, сохраните доступные логи и только затем перезапускайте сервис. Незавершённую обработку файлов после восстановления проверьте повторно. Перезапуск освобождает память процесса, но не устанавливает причину сбоя.

3. Отличите разовый пик от непрерывного роста

Первый запрос может загрузить модель и прогреть кеш. После него память не обязана вернуться к значению сразу после запуска. Более полезный признак проблемы — продолжающийся рост при сопоставимой нагрузке, который приближает сервис к OOM.

1. Выберите спокойное время или тестовую копию. Зафиксируйте RAM после запуска и после первого завершённого запроса.
2. Раздельно проверьте обычный чат без поиска, веб-поиск, небольшой TXT и проблемный PDF. Запускайте по одной операции, дожидаясь завершения.
3. Для каждого шага запишите память до операции, максимальное значение и показатель через несколько минут простоя. Во время обработки наблюдайте docker stats; остановка просмотра — Ctrl+C.
4. Повторите короткую серию, например пять сопоставимых запросов. Прервите проверку при приближении к лимиту памяти, не доводя рабочий сервер до падения.

Если потребление выходит на плато и повторные операции укладываются в запас RAM, вероятны рабочие буферы, загруженная модель или кеш. Если после каждой завершённой операции остаётся новая прибавка, есть повод исследовать удержание памяти. Это диагностический признак, а не доказательство конкретной утечки.

При постоянном добавлении новых документов растёт и сам индекс. Для сравнения конфигураций используйте одинаковый набор документов на отдельных тестовых копиях. Повторная загрузка уже известного файла может попасть под проверку дубликатов и не повторить весь путь обработки.

4. Если RAM растёт после веб-поиска

В обсуждении №29899 для Open WebUI 0.11.3 автор связал рост RAM с поиском через DDGS. В продолжении участник проекта сообщил, что отдельные обращения к DDGS у него не вызывали роста, а повторные записи во встроенную ChromaDB вызывали. Принудительная сборка мусора и замена распределителя памяти в его проверке не помогли. Это результат конкретного воспроизведения, а не диагноз для любой установки.

Для проверки такого сценария откройте Admin Panel → Settings → Web Search и включите обход эмбеддингов и поиска по индексу: BYPASS_WEB_SEARCH_EMBEDDING_AND_RETRIEVAL=true. Сохраните настройку и повторите ту же серию поисков.

В стандартном пути веб-поиска этот режим пропускает создание векторного индекса найденных страниц и передаёт извлечённый текст дальше для ответа модели. Если ступенчатый рост существенно уменьшился, направление дальнейшей проверки — обработка эмбеддингов и векторное хранилище. На индексацию загружаемых документов эта настройка не распространяется.

Компромисс — больший объём текста в контексте модели: возможны дополнительные расходы API, достижение лимита контекста и изменение качества ответа. Проверьте несколько вопросов с известными ответами и ссылки на источники. При ухудшении верните переключатель в прежнее положение.

Если основной симптом — высокий пик во время загрузки страниц, отдельно уменьшите нагрузку в том же разделе:

• WEB_SEARCH_RESULT_COUNT=3 — пример небольшого числа результатов для диагностической проверки.
• WEB_LOADER_CONCURRENT_REQUESTS=1 — последовательная загрузка страниц вместо нескольких одновременных.

Меняйте один параметр за раз. Если пик снизился, а время ответа приемлемо, увеличивайте параллельность постепенно. Эти числа — старт для проверки, не универсальная настройка. В актуальной конфигурации WEB_SEARCH_CONCURRENT_REQUESTS управляет запросами к поисковику, а WEB_LOADER_CONCURRENT_REQUESTS — загрузкой страниц; старые инструкции могут смешивать эти параметры. Их назначение приведено в официальном справочнике настроек.

5. Если память заканчивается при загрузке документов

Начните с одного файла. Сравните небольшой TXT и документ, который вызывает сбой. Если проблема возникает именно с PDF, сканами или сложной разметкой, проверьте извлечение текста и OCR — распознавание текста на изображениях. Размер файла на диске не показывает, сколько памяти потребуется для его обработки.

Извлечение текста. Официальное руководство по производительности предупреждает о росте памяти при встроенной обработке документов и предлагает внешние обработчики. Если Tika уже развёрнута и доступна из контейнера Open WebUI, в Admin Panel → Settings → Documents можно выбрать CONTENT_EXTRACTION_ENGINE=tika и указать TIKA_SERVER_URL.

Например, http://tika:9998 подходит только для сервиса с именем tika в общей Docker-сети. Само заполнение URL сервис не устанавливает. Проверьте один документ: обработка завершилась, текст извлечён, ответ содержит сведения из него. Следите за памятью обоих контейнеров. Перенос обработчика в соседний контейнер изолирует его, но оставляет расход RAM на том же сервере.

Эмбеддинги. В разделе Documents проверьте выбранный движок и модель. Если большой пакет фрагментов вызывает пик, уменьшите RAG_EMBEDDING_BATCH_SIZE: например, с 32 до 8, а при необходимости — до 1. Значение 1 дальше уменьшать не нужно. Сравните максимальную память и время обработки одного и того же документа. Маленький пакет может снизить пик, но не ограничивает весь объём памяти, нужный для файла. В коде версии 0.11.3 размер пакета используется и для локальных эмбеддингов SentenceTransformers.

При эмбеддингах через OpenAI, Azure OpenAI или Ollama с включённой асинхронной обработкой отдельно проверьте RAG_EMBEDDING_CONCURRENT_REQUESTS=1. Это ограничивает параллельные запросы эмбеддингов внутри обработки; общей очереди всех пользователей такая настройка не создаёт. Меньший пакет без ограничения параллельности может лишь увеличить число одновременных запросов.

Внешний API эмбеддингов снимает соответствующие вычисления с Open WebUI, но добавляет расходы и передачу текста провайдеру. Ollama на том же VPS продолжит использовать его ресурсы. Если меняете модель эмбеддингов, существующий индекс потребуется перестроить: даже одинаковая размерность векторов не делает разные модели взаимозаменяемыми.

Число фрагментов и файлов. Не уменьшайте CHUNK_SIZE наугад: более мелкие фрагменты обычно означают больше векторов. Большой CHUNK_OVERLAP, то есть перекрытие соседних фрагментов, тоже увеличивает объём обработки. А RAG_TOP_K задаёт число извлекаемых фрагментов при ответе и не ограничивает индексацию файла.

Для защиты от случайных тяжёлых загрузок задайте в Documents допустимый размер файла в мегабайтах — RAG_FILE_MAX_SIZE. Проверьте отказ на файле выше выбранной границы. На RAG_FILE_MAX_COUNT нельзя полагаться как на общий предел загрузок: по документации, ограничение количества для чата не распространяется на Knowledge Base. Массовую индексацию базы знаний запускайте небольшими порциями, отдельно от активной работы пользователей.

6. Почему изменение .env может ничего не дать

Часть параметров Open WebUI сохраняется в базе настроек. Для таких значений, обозначенных в документации как ConfigVar или PersistentConfig, сохранённая настройка может иметь приоритет над переменной окружения.

При диагностике удобнее изменить соответствующее поле в панели администратора, сохранить и снова открыть раздел: нужное значение должно остаться. Если управляете конфигурацией через Compose, убедитесь, что переменная передана в контейнер; один файл .env сам по себе этого не гарантирует. После изменения окружения контейнер нужно пересоздать. Обычный docker restart не загружает новые параметры Compose.

Не отключайте сохранение всей конфигурации ради одного эксперимента: это может изменить поведение других настроек. Сначала зафиксируйте прежние значения и предусмотрите возврат.

7. Когда имеет смысл заменить ChromaDB

Замена векторной базы оправдана, когда проверка указывает на запись или обслуживание индекса. В обсуждении №8598 один участник сообщил, что смена движка эмбеддингов не помогла, а переход на Qdrant остановил рост после первоначальной загрузки. Позднее другие участники описывали высокое потребление памяти и с внешними базами. Такой переход стоит проверять на своём наборе данных.

В Open WebUI DATABASE_URL отвечает за основную базу приложения, а VECTOR_DB — за векторное хранилище. Перенос чатов и пользователей в PostgreSQL сам по себе не заменяет ChromaDB. Для векторов можно рассматривать, например, PGVector или сервер Qdrant, учитывая дополнительные ресурсы и обслуживание.

Не переключайте VECTOR_DB в рабочей установке без подготовки: существующие векторы автоматически в новую базу не переедут.

1. Сохраните версию образа, Compose, настройки и секреты. Сделайте согласованную резервную копию данных Open WebUI, исходных загруженных файлов, основной и векторной баз. Для файловой копии SQLite и локальной Chroma остановите запись и сервис; для внешних БД используйте их штатные средства резервного копирования.
2. Проверьте восстановление на изолированной копии с отдельными томами. Тестовый экземпляр не должен записывать в рабочие базы.
3. Подключите новое векторное хранилище сначала на этой копии. Сохраните ту же модель эмбеддингов, чтобы одновременно не менять ещё одну причину поведения.
4. В Documents запустите Reindex Knowledge Base Vectors. Эта операция заново создаёт индексы баз знаний; согласно руководству по RAG, файлы вне них потребуется загрузить повторно. Заложите время и стоимость повторных эмбеддингов.
5. Проверьте ответы по нескольким базам знаний и отдельным файлам, доступ пользователей и память при сопоставимой нагрузке. Затем назначьте окно переноса с остановкой новых загрузок.

Для отката сохраните прежнее хранилище и копию состояния до переключения. При проблеме остановите новую установку и восстановите прежние настройки и согласованные данные. Не запускайте две версии на одном томе. Не удаляйте коллекции и тома Docker как способ «почистить RAM»: можно потерять поиск по документам.

Обновление Open WebUI тоже сначала проверяйте на копии. Используйте конкретный релиз и резервную копию до обновления; не заменяйте ChromaDB через pip внутри рабочего контейнера на произвольную версию. Откат одного образа без восстановления данных может оказаться недостаточным после миграций базы.

8. Как ограничить ущерб и понять, нужен ли VPS с большей RAM

Лимит контейнера помогает оставить память другим сервисам, но при его достижении Open WebUI может быть остановлен, а текущая загрузка — прервана. Выбирайте ограничение после измерения рабочего пика, оставляя память ОС и остальным компонентам.

Условный пример: на сервере с 16 ГБ RAM после измерений для Open WebUI выделен бюджет 6 ГБ. В существующий раздел этого сервиса в Compose добавляют лимит памяти:

mem_limit: 6g

Это отдельное поле рядом с image и volumes, а не переменная в environment. Число 6 ГБ здесь иллюстрирует синтаксис; для вашей нагрузки оно может быть недостаточным. Перед пересозданием убедитесь, что данные вынесены в постоянный том и резервная копия доступна.

В каталоге Compose, в согласованное окно обслуживания, проверьте файл и примените изменение. Здесь open-webui — имя сервиса Compose:

docker compose config --quiet
docker compose up -d --no-deps open-webui
docker inspect open-webui --format '{{.HostConfig.Memory}}'

Выполняйте команды по очереди и при ошибке остановитесь. После первой команды не должно быть ошибок, после последней должен отображаться установленный лимит в байтах: для 6g — 6442450944. Проверьте вход в интерфейс и загрузку тестового документа. Если рабочая обработка стала упираться в ограничение, остановите новые задания и верните прежнее значение с повторным применением Compose. Не используйте down -v: эта команда может удалить тома с данными.

Больше RAM нужно, когда после устранения непрерывного роста рабочий пик всё ещё превышает доступный бюджет при необходимом количестве пользователей. Считайте суммарное потребление Open WebUI, модели, обработчика документов и базы в момент совместной нагрузки. Перенос компонента на другой сервер разгружает текущий VPS, но добавляет стоимость, сеть и отдельное резервное копирование.

Для Open WebUI с внешней моделью или отдельного узла обработки можно рассмотреть NVMe VDS QCKL. Для подбора передайте измеренный пик RAM, число одновременных задач и объём базы знаний. Настройка приложения и администрирование согласуются отдельно. Если требуется локальная модель с GPU, сначала проверьте требования к видеопамяти и доступность подходящей конфигурации.

9. Как проверить результат и что собрать, если рост остался

Повторите исходный сценарий сначала последовательно, затем с обычным для проекта количеством одновременных задач. Исправление должно сохранить работоспособность поиска:

• Документы проходят обработку, а ответы содержат проверяемые сведения и правильные источники.
• Память укладывается в выбранный бюджет; повторные операции на сопоставимых данных не дают прежнего непрерывного роста.
• В журналах нет новых OOM, сбоев записи индекса и незавершённых загрузок.
• Время обработки и стоимость API после изменений приемлемы.

Если раньше сбой появлялся через сутки, короткой проверки недостаточно: наблюдайте сервис как минимум в сопоставимый период и при похожей нагрузке. При повторении соберите версию и образ Open WebUI, тип векторной базы, движок обработки и эмбеддингов, ограничения контейнера, график памяти и минимальный пример файла или запроса. Приложите логи с временем ошибки, удалив ключи API, токены и содержимое частных документов. Эти данные позволяют обсуждать конкретный дефект, а не только сообщение «Open WebUI использует много памяти».