When rechecking multiple records, the page refresh has no effect.

[liujc-creator]

When multiple watch items are rechecked simultaneously via the web UI, the container's CPU usage spikes to 100%. During this period, new browser tabs fail to load the web interface, and all API endpoints become unresponsive—requests only complete after the background recheck tasks finish or enter an idle gap.

The machine is configured with 16 cores and 32GB of RAM.

[root@ucpchangedct01v changedetection.io-master]# cat docker-compose.yml
services:
changedetection:
image: ghcr.io/dgtlmoon/changedetection.io:0.52.4
container_name: changedetection
hostname: changedetection
volumes:
- changedetection-data:/datastore
environment:
- PLAYWRIGHT_DRIVER_URL=ws://browser-sockpuppet-chrome:3000
- FETCH_WORKERS=6
- TZ=Asia/Shanghai
ports:
- 0.0.0.0:5000:5000
restart: unless-stopped
mem_limit: 4g
cpus: 4.0
depends_on:
browser-sockpuppet-chrome:
condition: service_started

browser-sockpuppet-chrome:
hostname: browser-sockpuppet-chrome
image: dgtlmoon/sockpuppetbrowser:latest
cap_add:
- SYS_ADMIN
restart: unless-stopped
environment:
- TZ=Asia/Shanghai
- SCREEN_WIDTH=1920
- SCREEN_HEIGHT=1024
- SCREEN_DEPTH=16
- MAX_CONCURRENT_CHROME_PROCESSES=10
mem_limit: 24g
cpus: 10.0

volumes:
changedetection-data:

[dgtlmoon]

[dgtlmoon]

When multiple watch items are rechecked simultaneously

honestly, how many watches are you checking? it must be extreme number?

[dgtlmoon]

The solution is to change the FETCH_WORKERS to something your computer can support, if you have 10 CPU cores, then probably 8 is enough.

[liujc-creator]

FETCH_WORKERS=6 has been set to 6, but judging from the CPU load, it seems that only one core is being utilized, and the multi-core capability is not being fully leveraged.

[dgtlmoon]

Hmm yeah that change was very inefficient, i'll fix it with #3747

[dgtlmoon]

check latest version and let me know if its solved! 0.52.5 out in a few minutes

[dgtlmoon]

are you using selenium, playwright etc? or just plain requests?

[liujc-creator]

The URL is configured with "fetch_backend": "system", meaning Selenium or Playwright is not in use.
In the global Fetch Method settings, the following option is currently selected:

• ✅ Basic fast Plaintext/HTTP Client
• Playwright Chromium/JavaScript via ws://browser-sockpuppet-chrome:3000

The currently running Docker containers are:

bash
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
38406338bf3e ghcr.io/dgtlmoon/changedetection.io:0.52.6 "python ./changedete…" 2 hours ago Up 2 hours 0.0.0.0:5000->5000/tcp changedetection
59982eef46fa dgtlmoon/sockpuppetbrowser:latest "tini -- /usr/local/…" 6 hours ago Up 6 hours changedetectionio-master-browser-sockpuppet-chrome-1

Although the main changedetection container has FETCH_WORKERS=6 configured, the observed CPU usage (~120%) suggests that only a single CPU core is being utilized, indicating that multi-core parallelism is not effectively leveraged.

Question: Does changedetection.io support true multi-core parallel processing? Are there additional configurations available to enable it to fully utilize multiple CPU cores?

Additionally, is there a way—either through built-in settings or external mechanisms—to limit the resource consumption (e.g., CPU or I/O) of fetch workers so they don’t interfere with the main web interface thread? Currently, during intensive checks, the API and UI become unresponsive or hang, suggesting that background workers may be starving the main request-handling thread.

[dgtlmoon]

Can the service be configured to utilize multiple cores?

everything 100% happens already in parallel with multiple core workers so hmmm

[liujc-creator]

Image upload failed. The following is htop's display.

1 [ 0.7%] 5 [ 0.0%] 9 [ 0.7%] 13 [|||||||||||100.0%]
2 [ 0.0%] 6 [ 0.0%] 10 [ 0.7%] 14 [ 0.7%]
3 [ 0.0%] 7 [ 1.3%] 11 [ 3.3%] 15 [ 1.3%]
4 [ 0.0%] 8 [ 1.3%] 12 [ 0.0%] 16 [ 0.7%]

Mem: ||||||||||||| 1.85G/31.3G
Swap:

Tasks: 86 total, 254 threads, 2 running
Load average: 0.68, 0.37, 0.48
Uptime: 2 days, 02:59:55

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
30549 root 20 0 2744M 307M 1368K S 114. 1.0 18:37.48 python ./changedetection.py -d /datastor

Note: Only CPU core 13 is fully utilized (100%); all other cores are under low load.

[dgtlmoon]

Any chance you can send me your url-watches.json ?

[dgtlmoon]

I found this little bug #3762 but it's not related, although it will help for people importing lists of page watches.

[ta7tUHIJHx4RwR21]

What does it look like if you remove the resource constraints on CPU and memory?

[dgtlmoon]

Sorry I dont understand at all, I need to see the url-watches.json backup export, you can send it to my gmail if you like

[ta7tUHIJHx4RwR21]

Sorry, im not the one with the problem.

I just noticed they have two different resource restrictions in their compose file.
“mem_limit: 4g
cpus: 4.0”

and
mem_limit: 24g
cpus: 10.0

My thinking was if they removed those statements does multithread work correctly. Is the issue the compose file or the program. Maybe I’m wrong.