High Idle CPU usage

[Salvora]

Describe the bug
This is something I've noticed recently. It seems that bazarr when idling causes my CPU to spike constantly.
I've checked the logs and noticed some ffprobe errors for a bluray video file. I've switched to mediainfo after that and these errors are gone now but the CPU usage is still abnormal for an idling app.

name: downloaders

x-common-labels: &common-labels
  com.centurylinklabs.watchtower.enable: "true"

x-cert-label: &cert-label
  server.custom.cert: "true"

x-common: &common
  labels: *common-labels
  extra_hosts:
    - "host.docker.internal:host-gateway"
    - "${LAXSS_PLEX_DOMAIN}:host-gateway"
    - "${LAXSS_DOMAIN}:host-gateway"
    - "${LAXSS_DOWNLOAD_STATION_DOMAIN}:host-gateway"
  restart: unless-stopped
  networks:
    - downloaders_network

x-common-env: &common-env
  TZ: ${TZ}

x-linuxserver-arr-mods-env: &linuxserver-arr-mods-env
  DOCKER_MODS: linuxserver/mods:universal-package-install
  INSTALL_PACKAGES: openssl

x-media-volume: &media-volume ${LAXSS_MEDIA_PATH}:/media
x-modcache: &modcache ${LAXSS_MODCACHE_PATH}:/modcache

x-ssl-pfx: &ssl-pfx ${LAXSS_PFX_CERT_PATH}:${CONTAINER_PFX_PATH}:ro
x-ssl-cert: &ssl-cert ${LAXSS_SSL_CERT_PATH}:${CONTAINER_SSL_CERT_PATH}:ro
x-ssl-key: &ssl-key ${LAXSS_PRIVATE_KEY_PATH}:${CONTAINER_PRIVATE_KEY_PATH}:ro

services:
  postgres:
    <<: *common
    image: postgres:17
    container_name: downloaders_postgres
    command: postgres -c 'max_connections=200'
    shm_size: 512m
    labels:
      - wud.watch=false
      - com.centurylinklabs.watchtower.enable=false
    healthcheck:
      test: ["CMD-SHELL", "/pg_healthcheck.sh"]
      start_period: 10s
      interval: 30s
      timeout: 20s
      retries: 3
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - /volume1/docker/docker-scripts/init-multiple-databases.sh:/docker-entrypoint-initdb.d/init-multiple-databases.sh:ro
      - /volume1/docker/docker-scripts/pg_healthcheck.sh:/pg_healthcheck.sh:ro
    environment:
      POSTGRES_MULTIPLE_DATABASES: ${POSTGRES_MULTIPLE_DATABASES}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      <<: *common-env

  bazarr:
    <<: *common
    image: lscr.io/linuxserver/bazarr:latest
    container_name: bazarr
    healthcheck:
      test: |
        curl -ILfs --max-time 3 http://localhost:${BAZARR_PORT}/system/ping > /dev/null \
          || exit 1
      start_period: 10s
      interval: 30s
      timeout: 20s
      retries: 3
    depends_on:
      postgres:
        condition: service_healthy
      radarr:
        condition: service_healthy
      sonarr:
        condition: service_healthy
    environment:
      PUID: ${BAZARR_PUID}
      PGID: ${DOWNLOADERS_PGID}
      POSTGRES_ENABLED: true
      POSTGRES_HOST: ${POSTGRES_HOST}
      POSTGRES_PORT: ${POSTGRES_PORT}
      POSTGRES_DATABASE: ${BAZARR_MAINDB_NAME}
      POSTGRES_USERNAME: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      WEBUI_PORTS: ${BAZARR_PORT}/tcp,${BAZARR_PORT}/udp
      <<: *common-env
    volumes:
      - ${CONFIG_BASE_FOLDER}/bazarr/config:/config
      - *media-volume
      - *modcache
    ports:
      - ${BAZARR_PORT}:${BAZARR_PORT}

To Reproduce
Steps to reproduce the behavior:

1. Deploy the bazarr with a similar compose
2. Track the CPU usage

Expected behavior
When idling, bazarr should not consume too much system resources.

Screenshots

Software (please complete the following information):

• Bazarr: 1.5.2
• Radarr version 5.26.2.10099
• Sonarr version 4.0.15.2941
• OS: DSM 7.2.2

Additional context
Add any other context about the problem here.

[morpheus65535]

We'll need a debug log to see what's happening during the high CPU usage period.

[Salvora]

I've restarted the container and let it run for about half an hour. During that time, the CPU usage was high all the time. The debug logs are attached.

bazarr_logs(1).txt

[morpheus65535]

There's absolutely nothing happening within Bazarr itself (except from logging some websocket messages from Sonarr/Radarr).

Can you verify if you're able to reproduce with lscr.io/linuxserver/bazarr:development ?

[Salvora]

Tried the development image, it is still high.

[morpheus65535]

Have you confirmed that the Bazarr python process is responsible for this high cpu usage?

I'll go over your log again but I haven't see anything suspicious.

[morpheus65535]

Could it be because of mediainfo? Could you try with ffprobe instead?

[Salvora]

I was using ffprobe initially but had to switch to mediainfo, it was failing to read a couple of Blu-ray releases. But I remember the cpu was even higher with ffprobe.

[Preclowski]

I dont have much worth to add here. Issue persists for me as well. Running linuxserver images on ubuntu server 24.04. High CPU usage in idle is constant.

For me thats super critical issue, running Bazarr increase my server temperature by 30C. Under normal load its avg 70C, with Bazarr running its core reaches 100*C. I would love to help debug this if possible, but I dont see anything except weird SignalR behaviour while exiting Bazarr. Like its blocking Bazarr process all the time.

Maybe those sleeps in signalR queues too many CPU tasks and instead of constant 2% cpu utilization it peaks after every sleep for 100%?

[morpheus65535]

Other than checking your config.yaml for something that could be causing this, there's not much I can do. I'm unable to reproduce this issue and Bazarr is averaging to 00.1% CPU usage for years now.

WEBUI_PORTS in your environment variable isn't a thing. LSIO doesn't document this variable and we don't use it anyway. Is there other stuff like that that you've been adding?

Are you both using postgres database?

[Preclowski]

Nothing uncommon except postgres - yes, im using it for bazarr (and other arrs too).

Now when looking at compose, I needed to add mem_limit: 4g because of memory leak consuming 64GB of ram by Bazarr after a while. 1.5.3-development is just try to fix it, originally it happened on 1.5.2.

  bazarr:
    image: lscr.io/linuxserver/bazarr:1.5.3-development
    container_name: bazarr
    mem_limit: 4g
    logging:
      driver: loki
      options:
        loki-url: http://xxx:3100/loki/api/v1/push
        mode: non-blocking
        max-buffer-size: 4m
        loki-retries: "3"
    volumes:
      - /var/lib/bazarr:/config
      - xxx:/data/media/movies
      - xxxs:/data/media/tv
    environment:
      - TZ=Europe/xxx
      - PUID=123
      - PGID=456
    networks:
      - traefik_default
      - default

[morpheus65535]

Now when looking at compose, I needed to add mem_limit: 4g because of memory leak consuming 64GB of ram by Bazarr after a while.

Let me guess: you're using the subtitles synchronization feature? I've seen really strange issues when container memory is limited and ffsubsync must load the whole audio track in memory to align speech segments with subtitles track. Often the audio track of BR RIP take memory that what's available and the process just crash.

Subtitles synchronization and embedded subtitles extraction are ressources intensive tasks. Try to disable that if you're facing recurring CPU and memory issues.

[Preclowski]

It was short, 20 minute test, but everything seems fine.

If that really helped - its bit weird. It was the python bazarr process that caused cpu peaks, not ffmpeg. When bazarr runs something external it runs another process with different cmd, but peaking process was main one without any additional params in cmd during idle.

Anyway - I will test this for longer period and thank you so much for tip. I can barely notice idle bazarr activity with sub sync disabled.

[morpheus65535]

@Preclowski let see if it's really fixed and we'll see if we can catch it somehow. Let me know.

[Preclowski]

@Preclowski let see if it's really fixed and we'll see if we can catch it somehow. Let me know.

It helped. Previously it was high cpu since bootstrap, now its over 3h and everything is perfectly calm.

@Salvora are you using subtitle sync?