github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-07 03:18:23 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #20520] issue: Getting insane loading times on certain pages after updating to 0.7.0 #57876

New Issue
Closed
opened 2026-05-05 21:47:51 -05:00 by GiteaMirror · 30 comments
GiteaMirror commented 2026-05-05 21:47:51 -05:00
Owner
Copy Link

Originally created by @Moicky on GitHub (Jan 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20520

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.7.0

Ollama Version (if applicable)

0.6.8

Operating System

Linux rpi4-20231108 6.1.0-34-arm64 #1 SMP Debian 6.1.135-1 (2025-04-25) aarch64 GNU/Linux

Browser (if applicable)

Brave v1.85.120

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Opening certain pages like the Admin Settings in a reasonable time

Actual Behavior

Before the update, the page (especially the Admin settings) loaded within ~1-2 sec. This is no longer the case.
Most requests result in a timeout after 2 minutes.

Steps to Reproduce

Updated from 0.6.41 -> 0.7.0

Logs & Screenshots

Image

Additional Information

My envs in docker-compose.yaml:

    environment:
      - OLLAMA_BASE_URL=http://192.168.x.y:11434
      - CHAT_STREAM_RESPONSE_CHUNK_MAX_BUFFER_SIZE=20971520

I'm using a somewhat cumbersome setup using an nginx proxy with a self generated certificate which then gets tunneled through a cloudflare tunnel and is mapped to my domain.

This should not cause this issue as I've not changed anything about this setup, and also connecting to the instance via the direct local IP causes the same delays

The logs in docker do not show any errors. They just list requests for JS files or api calls which went through, but not list the ones which timeout

Originally created by @Moicky on GitHub (Jan 9, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20520 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.7.0 ### Ollama Version (if applicable) 0.6.8 ### Operating System Linux rpi4-20231108 6.1.0-34-arm64 #1 SMP Debian 6.1.135-1 (2025-04-25) aarch64 GNU/Linux ### Browser (if applicable) Brave v1.85.120 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Opening certain pages like the Admin Settings in a reasonable time ### Actual Behavior Before the update, the page (especially the Admin settings) loaded within ~1-2 sec. This is no longer the case. Most requests result in a timeout after 2 minutes. ### Steps to Reproduce Updated from 0.6.41 -> 0.7.0 ### Logs & Screenshots <img width="1275" height="1048" alt="Image" src="https://github.com/user-attachments/assets/aafcbe31-f28f-4748-b059-5c4fa8ad4cae" /> ### Additional Information My envs in docker-compose.yaml: ```yaml environment: - OLLAMA_BASE_URL=http://192.168.x.y:11434 - CHAT_STREAM_RESPONSE_CHUNK_MAX_BUFFER_SIZE=20971520 ``` I'm using a somewhat cumbersome setup using an nginx proxy with a self generated certificate which then gets tunneled through a cloudflare tunnel and is mapped to my domain. This should not cause this issue as I've not changed anything about this setup, and also connecting to the instance via the direct local IP causes the same delays The logs in docker do not show any errors. They just list requests for JS files or api calls which went through, but not list the ones which timeout
GiteaMirror added the bug label 2026-05-05 21:47:51 -05:00
GiteaMirror commented 2026-05-05 21:47:54 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (Jan 9, 2026):

🔍 Similar Issues Found

I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:

  1. #19976 issue: Performance Degradation after updating to v0.6.41
    by mthreet • Dec 15, 2025 • bug

  2. #20327 issue: Unable to use any Open WebUI version newer than 0.6.25 due to hybrid search performance
    by galvanoid • Jan 02, 2026 • bug

  3. #19082 issue: Very long restart time after update to version 0.6.3x – takes several hours, no visible errors in logs
    by Schwenn2002 • Nov 10, 2025 • bug

  4. #19438 issue: Icon loading regression
    by JoelShepard • Nov 24, 2025 • bug

  5. #20207 issue: Infinite loading screen when MCP tool is enabled.
    by ppeterka • Dec 27, 2025 • bug

Show 1 more related issues
  1. #19496 issue: 500 internal server error appears in v0.6.40
    by cloudtuotuo • Nov 26, 2025 • bug

💡 Tips:

  • If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
  • If you found a solution in any of these issues, please share it here to help others

This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.

<!-- gh-comment-id:3730358617 --> @owui-terminator[bot] commented on GitHub (Jan 9, 2026): 🔍 **Similar Issues Found** I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions: 1. [#19976](https://github.com/open-webui/open-webui/issues/19976) **issue: Performance Degradation after updating to v0.6.41** *by mthreet • Dec 15, 2025 • `bug`* 2. [#20327](https://github.com/open-webui/open-webui/issues/20327) **issue: Unable to use any Open WebUI version newer than 0.6.25 due to hybrid search performance** *by galvanoid • Jan 02, 2026 • `bug`* 3. [#19082](https://github.com/open-webui/open-webui/issues/19082) **issue: Very long restart time after update to version 0.6.3x – takes several hours, no visible errors in logs** *by Schwenn2002 • Nov 10, 2025 • `bug`* 4. [#19438](https://github.com/open-webui/open-webui/issues/19438) **issue: Icon loading regression** *by JoelShepard • Nov 24, 2025 • `bug`* 5. [#20207](https://github.com/open-webui/open-webui/issues/20207) **issue: Infinite loading screen when MCP tool is enabled.** *by ppeterka • Dec 27, 2025 • `bug`* <details> <summary>Show 1 more related issues</summary> 6. [#19496](https://github.com/open-webui/open-webui/issues/19496) **issue: 500 internal server error appears in v0.6.40** *by cloudtuotuo • Nov 26, 2025 • `bug`* </details> --- 💡 **Tips:** - If this is a duplicate, please consider closing this issue and adding any additional details to the existing one - If you found a solution in any of these issues, please share it here to help others *This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
GiteaMirror commented 2026-05-05 21:47:58 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

Cannot reproduce on my end

<!-- gh-comment-id:3730381856 --> @Classic298 commented on GitHub (Jan 9, 2026): Cannot reproduce on my end
GiteaMirror commented 2026-05-05 21:48:01 -05:00
Author
Owner
Copy Link

@sstiglitz commented on GitHub (Jan 9, 2026):

I run into a similar issue, sorting the users list by last active date causes the server to crash.

Steps to recreate:

  1. Go to user admin /admin/users/overview
  2. Click the Last Active header

Expected: Page refreshes with sorted results timely.

Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes.

Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43.

<!-- gh-comment-id:3730386758 --> @sstiglitz commented on GitHub (Jan 9, 2026): I run into a similar issue, sorting the users list by last active date causes the server to crash. Steps to recreate: 1. Go to user admin /`admin/users/overview` 2. Click the `Last Active` header Expected: Page refreshes with sorted results timely. Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes. Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43.
GiteaMirror commented 2026-05-05 21:48:08 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Jan 9, 2026):

Same issue for me.

most of admin pages doesn't load.

example of 1 page loading longer than 60 seconds:

Image

No errors in the server log

INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
<!-- gh-comment-id:3730388435 --> @SlavikCA commented on GitHub (Jan 9, 2026): Same issue for me. most of admin pages doesn't load. example of 1 page loading longer than 60 seconds: <img width="1296" height="502" alt="Image" src="https://github.com/user-attachments/assets/4ff5b0d4-1f79-439e-be3c-9cde878b20a4" /> No errors in the server log ``` INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. ```
GiteaMirror commented 2026-05-05 21:48:12 -05:00
Author
Owner
Copy Link

@robertbeckey commented on GitHub (Jan 9, 2026):

Same issue here.

<!-- gh-comment-id:3730390249 --> @robertbeckey commented on GitHub (Jan 9, 2026): Same issue here.
GiteaMirror commented 2026-05-05 21:48:14 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jan 9, 2026):

Postgres or Sqlite?

<!-- gh-comment-id:3730392451 --> @tjbck commented on GitHub (Jan 9, 2026): Postgres or Sqlite?
GiteaMirror commented 2026-05-05 21:48:15 -05:00
Author
Owner
Copy Link

@sstiglitz commented on GitHub (Jan 9, 2026):

Postgres or Sqlite?

For me, SQLite.

<!-- gh-comment-id:3730393480 --> @sstiglitz commented on GitHub (Jan 9, 2026): > Postgres or Sqlite? For me, SQLite.
GiteaMirror commented 2026-05-05 21:48:16 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

Also SQLite with some custom tables ontop

<!-- gh-comment-id:3730395603 --> @Moicky commented on GitHub (Jan 9, 2026): Also SQLite with some custom tables ontop
GiteaMirror commented 2026-05-05 21:48:17 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

Done some more tests, and visiting all admin & config pages through the local IP seems to somewhat work, but as soon as I open a single one via my domain (with the nginx & cloudflare proxy), it freezes which also freezes the connections via local IP

<!-- gh-comment-id:3730399584 --> @Moicky commented on GitHub (Jan 9, 2026): Done some more tests, and visiting all admin & config pages through the local IP seems to somewhat work, but as soon as I open a single one via my domain (with the nginx & cloudflare proxy), it freezes which also freezes the connections via local IP
GiteaMirror commented 2026-05-05 21:48:18 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

You are not running multi-worker/HA setups by any chance which you didn't upgrade all at once?

I am running 0.7 locally with sqlite no issues. Can't reproduce any of the reported here.

<!-- gh-comment-id:3730399636 --> @Classic298 commented on GitHub (Jan 9, 2026): You are not running multi-worker/HA setups by any chance which you didn't upgrade all at once? I am running 0.7 locally with sqlite no issues. Can't reproduce any of the reported here.
GiteaMirror commented 2026-05-05 21:48:21 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Jan 9, 2026):

I run into a similar issue, sorting the users list by last active date causes the server to crash.

Steps to recreate:

1. Go to user admin /`admin/users/overview`

2. Click the `Last Active` header

Expected: Page refreshes with sorted results timely.

Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes.

Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43.

I'm unable to reproduce using Postgres with 54 total users added (imported 50 random users from a CSV fille; 4 users are legitimate).

<!-- gh-comment-id:3730401623 --> @silentoplayz commented on GitHub (Jan 9, 2026): > I run into a similar issue, sorting the users list by last active date causes the server to crash. > > Steps to recreate: > > 1. Go to user admin /`admin/users/overview` > > 2. Click the `Last Active` header > > > Expected: Page refreshes with sorted results timely. > > Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes. > > Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43. I'm unable to reproduce using Postgres with 54 total users added (imported 50 random users from a CSV fille; 4 users are legitimate).
GiteaMirror commented 2026-05-05 21:48:24 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

You are not running multi-worker/HA setups by any chance which you didn't upgrade all at once?

I am running 0.7 locally with sqlite no issues. Can't reproduce any of the reported here.

I've not configured anything in this regard on my end. If this is not enabled by default, then no

<!-- gh-comment-id:3730403529 --> @Moicky commented on GitHub (Jan 9, 2026): > You are not running multi-worker/HA setups by any chance which you didn't upgrade all at once? > > I am running 0.7 locally with sqlite no issues. Can't reproduce any of the reported here. I've not configured anything in this regard on my end. If this is not enabled by default, then no
GiteaMirror commented 2026-05-05 21:48:25 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jan 9, 2026):

Single instance, Sqlite setup with ~50 users?

<!-- gh-comment-id:3730408393 --> @tjbck commented on GitHub (Jan 9, 2026): Single instance, Sqlite setup with ~50 users?
GiteaMirror commented 2026-05-05 21:48:26 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

Single instance, Sqlite setup with ~50 users?

Single instance, SQLite with 9 registered users, 3 active ones. (in total ~2.3k messages)

<!-- gh-comment-id:3730410960 --> @Moicky commented on GitHub (Jan 9, 2026): > Single instance, Sqlite setup with ~50 users? Single instance, SQLite with 9 registered users, 3 active ones. (in total ~2.3k messages)
GiteaMirror commented 2026-05-05 21:48:26 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

Seems to be improving randomly and letting me visit certain pages in the Admin-Panel, but the spam of Model Images is definitely causing a huge delay / freeze

Image
<!-- gh-comment-id:3730435340 --> @Moicky commented on GitHub (Jan 9, 2026): Seems to be improving randomly and letting me visit certain pages in the Admin-Panel, but the spam of Model Images is definitely causing a huge delay / freeze <img width="1290" height="1049" alt="Image" src="https://github.com/user-attachments/assets/485098c3-9e5e-4630-9593-0c862d234f54" />
GiteaMirror commented 2026-05-05 21:48:26 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jan 9, 2026):

@Moicky Could you try setting up the latest dev and if 8646aebaab has resolved the issue for you?

<!-- gh-comment-id:3730439905 --> @tjbck commented on GitHub (Jan 9, 2026): @Moicky Could you try setting up the latest dev and if 8646aebaab3440f4b1bbfb07a8366d00bced6bf1 has resolved the issue for you?
GiteaMirror commented 2026-05-05 21:48:27 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jan 9, 2026):

@Moicky also could you share your hardware specs for your Open WebUI deployment?

<!-- gh-comment-id:3730442992 --> @tjbck commented on GitHub (Jan 9, 2026): @Moicky also could you share your hardware specs for your Open WebUI deployment?
GiteaMirror commented 2026-05-05 21:48:27 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

@Moicky Could you try setting up the latest dev and if 8646aebaab has resolved the issue for you?

Currently setting that up ✅

@Moicky also could you share your hardware specs for your Open WebUI deployment?

My specs:

  • Hardware: Raspberry Pi 4 Model B (4GB RAM version)
  • OS: Debian GNU/Linux 12 (Bookworm) - 64-bit (aarch64)
  • Storage: 128GB (Total 117G / Used 47%)
  • Memory Status: 3.7GB Total / 1.5GB Currently Used
<!-- gh-comment-id:3730455251 --> @Moicky commented on GitHub (Jan 9, 2026): > [@Moicky](https://github.com/Moicky) Could you try setting up the latest dev and if https://github.com/open-webui/open-webui/commit/8646aebaab3440f4b1bbfb07a8366d00bced6bf1 has resolved the issue for you? Currently setting that up ✅ > [@Moicky](https://github.com/Moicky) also could you share your hardware specs for your Open WebUI deployment? My specs: - Hardware: Raspberry Pi 4 Model B (4GB RAM version) - OS: Debian GNU/Linux 12 (Bookworm) - 64-bit (aarch64) - Storage: 128GB (Total 117G / Used 47%) - Memory Status: 3.7GB Total / 1.5GB Currently Used
GiteaMirror commented 2026-05-05 21:48:28 -05:00
Author
Owner
Copy Link

@sstiglitz commented on GitHub (Jan 9, 2026):

I run into a similar issue, sorting the users list by last active date causes the server to crash.
Steps to recreate:

1. Go to user admin /`admin/users/overview`

2. Click the `Last Active` header

Expected: Page refreshes with sorted results timely.
Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes.
Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43.

I'm unable to reproduce using Postgres with 54 total users added (imported 50 random users from a CSV fille; 4 users are legitimate).

Thank you for checking. Maybe just environment/config differences then? I'm not sure.

I'll try updating to a dev image per @tjbck 's comments and report back.

<!-- gh-comment-id:3730462257 --> @sstiglitz commented on GitHub (Jan 9, 2026): > > I run into a similar issue, sorting the users list by last active date causes the server to crash. > > Steps to recreate: > > ``` > > 1. Go to user admin /`admin/users/overview` > > > > 2. Click the `Last Active` header > > ``` > > Expected: Page refreshes with sorted results timely. > > Actual: Server takes extremely long (minutes) to respond, or never responds. Eventually the instance crashes. > > Note, we have about 50 total users, so it is not like it is sorting a bunch of records. Worked just fine on 0.6.43. > > I'm unable to reproduce using Postgres with 54 total users added (imported 50 random users from a CSV fille; 4 users are legitimate). Thank you for checking. Maybe just environment/config differences then? I'm not sure. I'll try updating to a dev image per @tjbck 's comments and report back.
GiteaMirror commented 2026-05-05 21:48:28 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Jan 9, 2026):

8646aebaab fixes the issue for me

<!-- gh-comment-id:3730465871 --> @SlavikCA commented on GitHub (Jan 9, 2026): https://github.com/open-webui/open-webui/commit/8646aebaab3440f4b1bbfb07a8366d00bced6bf1 fixes the issue for me
GiteaMirror commented 2026-05-05 21:48:29 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

A raspberry pi for 9 (possible concurrent) users is maybe not a good idea just saying in general here

<!-- gh-comment-id:3730469311 --> @Classic298 commented on GitHub (Jan 9, 2026): A raspberry pi for 9 (possible concurrent) users is maybe not a good idea just saying in general here
GiteaMirror commented 2026-05-05 21:48:29 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

A raspberry pi for 9 (possible concurrent) users is maybe not a good idea just saying in general here

Yes, totally understandable. I was looking for an easy way to host it for the few users we have, while not having to rent a server that is running 24/7.

Can you recommend an alternative service to host it on?

<!-- gh-comment-id:3730473006 --> @Moicky commented on GitHub (Jan 9, 2026): > A raspberry pi for 9 (possible concurrent) users is maybe not a good idea just saying in general here Yes, totally understandable. I was looking for an easy way to host it for the few users we have, while not having to rent a server that is running 24/7. Can you recommend an alternative service to host it on?
GiteaMirror commented 2026-05-05 21:48:30 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

Any vServer / VPS for a few dollars a month with an SSD and multiple vCPUs and upwards of 4gb ram should be sufficient for such small(er) scale setups

<!-- gh-comment-id:3730480727 --> @Classic298 commented on GitHub (Jan 9, 2026): Any vServer / VPS for a few dollars a month with an SSD and multiple vCPUs and upwards of 4gb ram should be sufficient for such small(er) scale setups
GiteaMirror commented 2026-05-05 21:48:30 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

Can anyone else here confirm they are running open webui on weaker/weak-ish hardware?

The new db session sharing, while improving performance and scalability, can also increase the resources used and I think this is why it hammers your setups - because the hardware is on the weaker end.

<!-- gh-comment-id:3730487885 --> @Classic298 commented on GitHub (Jan 9, 2026): Can anyone else here confirm they are running open webui on weaker/weak-ish hardware? The new db session sharing, while improving performance and scalability, can also increase the resources used and I think this is why it hammers your setups - because the hardware is on the weaker end.
GiteaMirror commented 2026-05-05 21:48:31 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

@Moicky Could you try setting up the latest dev and if 8646aeb has resolved the issue for you?

Can confirm, that this seems to have fixed the issue

<!-- gh-comment-id:3730491318 --> @Moicky commented on GitHub (Jan 9, 2026): > [@Moicky](https://github.com/Moicky) Could you try setting up the latest dev and if [8646aeb](https://github.com/open-webui/open-webui/commit/8646aebaab3440f4b1bbfb07a8366d00bced6bf1) has resolved the issue for you? Can confirm, that this seems to have fixed the issue
GiteaMirror commented 2026-05-05 21:48:31 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Jan 9, 2026):

My system:

  • Intel Xeon W5-3425
  • 256GB RAM DDR5

Running in k3s with these resources:

          resources:
            requests:
              cpu: 50m
              memory: 300Mi
            limits:
              memory: 2Gi

v0.7 was extremely slow.
last DEV commit fixed it.

<!-- gh-comment-id:3730493639 --> @SlavikCA commented on GitHub (Jan 9, 2026): My system: - Intel Xeon W5-3425 - 256GB RAM DDR5 Running in k3s with these resources: ``` resources: requests: cpu: 50m memory: 300Mi limits: memory: 2Gi ``` v0.7 was extremely slow. last DEV commit fixed it.
GiteaMirror commented 2026-05-05 21:48:32 -05:00
Author
Owner
Copy Link

@sstiglitz commented on GitHub (Jan 9, 2026):

I'll try updating to a dev image per @tjbck 's comments and report back.

Confirmed updating to the dev image fixes my issue.

Since there are some resource questions going around, I run my instance in k8s with the following. I run on GKE using standard/autopilot servers

        - name: open-webui
          image: ghcr.io/open-webui/open-webui:git-8646aeb
          resources:
            requests:
              memory: 1024M
              cpu: 250m
            limits:
              memory: 2048M
              cpu: 500m
<!-- gh-comment-id:3730494605 --> @sstiglitz commented on GitHub (Jan 9, 2026): > I'll try updating to a dev image per [@tjbck](https://github.com/tjbck) 's comments and report back. Confirmed updating to the dev image fixes my issue. Since there are some resource questions going around, I run my instance in k8s with the following. I run on GKE using standard/autopilot servers ``` - name: open-webui image: ghcr.io/open-webui/open-webui:git-8646aeb resources: requests: memory: 1024M cpu: 250m limits: memory: 2048M cpu: 500m ```
GiteaMirror commented 2026-05-05 21:48:33 -05:00
Author
Owner
Copy Link

@Moicky commented on GitHub (Jan 9, 2026):

Thanks for responding on such short notice and having a fix ready in minutes! 👍 ❤️

<!-- gh-comment-id:3730513807 --> @Moicky commented on GitHub (Jan 9, 2026): Thanks for responding on such short notice and having a fix ready in minutes! 👍 ❤️
GiteaMirror commented 2026-05-05 21:48:33 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

A quarter of a CPU core for a whole open webui instance is... Interesting to say the least.

Yeah so effectively this issue only affects super low spec setups.

Everyone else can and should enable the new db performance feature

<!-- gh-comment-id:3730535823 --> @Classic298 commented on GitHub (Jan 9, 2026): A quarter of a CPU core for a whole open webui instance is... Interesting to say the least. Yeah so effectively this issue only affects super low spec setups. Everyone else can and should enable the new db performance feature
GiteaMirror commented 2026-05-05 21:48:35 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 9, 2026):

For anyone landing here from search: the fix in 0.7.1 (disabling session sharing by default) resolved this, but it's worth noting that several reports here involved extremely constrained resource allocations (50-250 millicpu) or low spec machines.

Session sharing reduces overhead but increases contention. When you're reusing sessions across requests, you're saving the cost of creating/destroying connections. That's a win on decent hardware. But on a Raspberry Pi or a constrained setup with just 50 millicpu allocated to Open WebUI, the problem flips: now multiple requests are waiting on each other through the shared session rather than each getting their own session and proceeding independently.

If you're running Open WebUI in k8s/k3s, it would be recommendable to allocate at minimum 1 full CPU core and 2GB RAM for acceptable performance. With adequate resources, DATABASE_ENABLE_SESSION_SHARING=true will actually improve performance, especially with Postgres.

On very low spec machines or low spec setups, this env var needs to be turned off.

For setups with adequate resources: consider enabling it (especially with PostgreSQL).

<!-- gh-comment-id:3730784379 --> @Classic298 commented on GitHub (Jan 9, 2026): For anyone landing here from search: the fix in 0.7.1 (disabling session sharing by default) resolved this, but it's worth noting that several reports here involved extremely constrained resource allocations (50-250 millicpu) or low spec machines. Session sharing reduces overhead but increases contention. When you're reusing sessions across requests, you're saving the cost of creating/destroying connections. That's a win on decent hardware. But on a Raspberry Pi or a constrained setup with just 50 millicpu allocated to Open WebUI, the problem flips: now multiple requests are waiting on each other through the shared session rather than each getting their own session and proceeding independently. If you're running Open WebUI in k8s/k3s, it would be recommendable to allocate **at minimum** 1 full CPU core and 2GB RAM for acceptable performance. With adequate resources, DATABASE_ENABLE_SESSION_SHARING=true will actually improve performance, especially with Postgres. On very low spec machines or low spec setups, this env var needs to be turned off. **For setups with adequate resources: consider enabling it (especially with PostgreSQL).**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#57876
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?