[BUG] New Install - Incredibly Slow in all aspects

[QGtKMlLz]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I am coming from Jacoberty's Unifi docker container, so I had to setup Mongodb (tried 4.4.6 & 4.4.29-focal which gives the AVX warning). I've done a fresh install after having trouble installing it, but since I got it running it has been incredibly slow to utilize the Unifi WebUI, around 1 minute to go from page-to-page. That is as soon as the very first Setup page and in the fully running environment.

Expected Behavior

No response

Steps To Reproduce

Up to 1+ Minute to browse page-to-page:
Initial Setup pages (and attempt to restore) - Large delays in each page change
Login & page changes in running Unifi environment.

Docker Compose Configs: Attached
Unifi-LinuxServer-Configs.txt
_UniFi-Network-App_logs.txt
_Unifi_Netw_MongoDB_logs.txt

Environment

- OS:
- How docker service was installed:

Synology DS1815+ DSM 7.1.1-42962 Update 6
Intel Atom C2538  	RAM:8GB
Docker version via Portainer = 20.10.3 (latest Synology Package version available)
Filesystem: BTRFS

Running Jacobalberty UniFi (migrating from & side-by-side) and it just fine for speed https://github.com/jacobalberty/unifi-docker ?

CPU architecture

x86-64

Docker creation

Started with Synology Docker UI or Portainer UI

Docker Compose Configs: Attached
[Unifi-LinuxServer-Configs.txt](https://github.com/user-attachments/files/16041989/Unifi-LinuxServer-Configs.txt)

Container logs

Logs Attached

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[XxROBOTICSxX]

I've been experiencing similar behavior on a newly migrated unifi-network deployment, migrated from a unifi-controller container following the recommended steps, exporting the controller (settings only) and restoring on a fresh deployment of the latest unifi-network-application, and mongo 7.0 container. Our deployment had a little over 100 sites, and performed without issue on the deprecated unifi-controller container, however after migrating some api actions, such as creating new sites, or deleting sites hang for multiple minutes before completing, this occurs both through the web ui or performing the calls to the API directly using curl or postman. I have not experienced slowness in the UI outside of these actions.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[johnseth97]

Same issue here, getting some console output that other users on reddit are reporting with slow behavior as well:

2024-11-15 00:18:21 :0 Permanent error code on channel bind request: 400 - Empty port number in channel bind request
2024-11-15 00:18:21 :0 All TURN channel bindings failed

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[drizuid]

Started with Synology Docker UI or Portainer UI

We do not support or recommend deploying containers with the synology ui nor portainer as they cause issues for non-experts. Our supported deployment methods are listed in the container readme.

Filesystem: BTRFS

this filesystem is not supported by the default docker storage driver, you didnt provide any input on your docker storage driver, so i will assume they are incompatible with each other. I have been told synology handles this automatically, so we can ignore this bit.

your docker version is extremely old and your kernel has been end of life for years. I would recommend at this point, that if you're unwilling to redeploy using a supported method and confirm a compatible docker storage driver, that you leverage the container you indicated works fine.
Unfortunately, we cannot put a lot of effort into NAS units with wildly out of date kernels and docker versions, and while this may not be the specific issue the container you compared to is using debian bullseye which went end of life on August 14th 2024 and is NOT something we would run in our containers. It is likely why your system runs better on it than ours.

as for the other users with "same issue here" these statements are never useful or helpful, you provide no detail on your cpu, kernel, docker version, deployment method, or any logging, so we must subsequently ignore these statements.