NiceGUI uses 100% of a CPU core when running inside a container

[pwt]

Question

Hi folks:

I'm making productive use of NiceGUI and finding it very elegant to use. However, I've run into an issue when trying to deploy an app within a container.

I'm sure I'm doing something dumb here, and I'm hoping someone can point out what. Ideas welcome!

Problem

When I start a NiceGUI app within a container, it will use 100% of a CPU core. I've simplified my setup as far as I can in an attempt to narrow down what the issue could be, as follows:

Dockerfile

FROM python:3.12-slim
RUN pip install --root-user-action=ignore --disable-pip-version-check --no-cache-dir nicegui
COPY nicegui-test.py nicegui-test.py
CMD python nicegui-test.py

NiceGUI App: nicegui-test.py

from nicegui import ui
ui.label('Hello NiceGUI!')
ui.run()

Build the Container Image

docker build -t nicegui-test .

Run the Container

% docker run --rm -p 8080:8080 --name nicegui-run nicegui-test
NiceGUI ready to go on http://localhost:8080, and http://172.17.0.2:8080

This works, but uses a continuous 100% of a CPU core.

Run the NiceGUI App from Bash within a Container

I see the same issue if I start the NiceGUI app from a Bash shell within the container:

% docker run -it --rm -p 8080:8080 --name nicegui-run nicegui-test bash
root@d589ccb0d5d3:/# python nicegui-test.py
NiceGUI ready to go on http://localhost:8080, and http://172.17.0.2:8080

The CPU will latch at 100% once the app is started.

Thanks for any pointers, folks.

Stack Trace

Edit: added stack trace when the app is interrupted:

NiceGUI ready to go on http://localhost:8080, and http://172.17.0.2:8080
^CProcess SpawnProcess-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "uvloop/loop.pyx", line 1517, in uvloop.loop.Loop.run_until_complete
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.12/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.12/site-packages/uvicorn/_subprocess.py", line 78, in subprocess_started
    target(sockets=sockets)
  File "/usr/local/lib/python3.12/site-packages/nicegui/server.py", line 36, in run
    super().run(sockets=sockets)
  File "/usr/local/lib/python3.12/site-packages/uvicorn/server.py", line 65, in run
    return asyncio.run(self.serve(sockets=sockets))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 123, in run
    raise KeyboardInterrupt()
KeyboardInterrupt

[rodja]

I briefly looked at it and could reproduce the behaviour. Strangely when I use the zauberzeug/nicegui docker image the cpu utilization was ok. Has anyone an idea what is going on?

[rodja]

I transferred it into an issue: #3066

[pwt]

Thanks for converting this into an issue.

It looks like using ui.run(reload=False) fixes the issue, which is actually fine for my purposes.

[thiagomoretto]

Do you have a venv or deps in the same path level as the app?

I had similar issue but it was related to uvicorn, not specific to Nicegui or even Fastapi

Anyway, If someone steps by here what I have found is that using just --reload and on the same path having a venv or hundreds of python packages (the deps), uvicorn would end up watching for modification of these thousands of files. The alternative is to provide a directory to watch using --reload-dir [your-source-path] to narrow its scope.

As you have mentioned that you're using ui.run instead, if that's the same case you can use uvicorn_reload_dirs param on ui.run.