[BUG] Album Page takes way to long to load #714

Closed
opened 2026-02-04 22:06:05 +03:00 by OVERLORD · 9 comments
Owner

Originally created by @akoyaxd on GitHub (Feb 25, 2023).

The bug

If I open the Albumlist with currently about 7 Albums it takes about 6 seconds to load each time I open the Album overview or return from an Album. It looks like it takes so long to generate the json with with Album Info.

Maybe there could be some caching or optimization on how the Album Page is rendered.

The OS that Immich Server is running on

Debian 11 with Docker

Version of Immich Server

v1.49.0

Version of Immich Mobile App

v1.49.0

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

version: "3.3"

volumes:
  immich_data:
    external: true

services:
  server:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-server.sh"]
    volumes:
      - immich_data:/usr/src/app/upload
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    hostname: immich-server
    depends_on:
      - redis
      - postgres
    restart: unless-stopped

  microservices:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-microservices.sh"]
    volumes:
      - immich_data:/usr/src/app/upload
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    depends_on:
      - redis
      - postgres
    restart: unless-stopped
    hostname: immich-microservices
    deploy:
      resources:
        limits:
          cpus: '4.0'
          memory: 4G

  machine-learning:
    image: altran1502/immich-machine-learning:release
    command: [ "python", "src/main.py" ]
    volumes:
      - immich_data:/usr/src/app/upload
      - /opt/immich-ml/cache:/cache
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
    env_file:
      - env
    depends_on:
      - postgres
    restart: unless-stopped
    hostname: immich-machine-learning

  web:
    image: altran1502/immich-web:release
    entrypoint: ["/bin/sh", "./entrypoint.sh"]
    environment:
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    restart: unless-stopped
    hostname: immich-web

  redis:
    image: redis:6
    restart: unless-stopped
    hostname: immich_redis

  postgres:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      PG_DATA: /var/lib/postgresql/data
    env_file:
      - env
    volumes:
      - /opt/immich-postgres:/var/lib/postgresql/data
    restart: unless-stopped
    hostname: immich_postgres

  proxy:
    image: altran1502/immich-proxy:release
    ports:
      - 2283:8080
    depends_on:
      - server
    restart: unless-stopped

Your .env content

only secrets

Reproduction steps

1. Install Immich
2. Create Albums
3. Open Albums Page
...

Additional information

No response

Originally created by @akoyaxd on GitHub (Feb 25, 2023). ### The bug If I open the Albumlist with currently about 7 Albums it takes about 6 seconds to load each time I open the Album overview or return from an Album. It looks like it takes so long to generate the json with with Album Info. Maybe there could be some caching or optimization on how the Album Page is rendered. ### The OS that Immich Server is running on Debian 11 with Docker ### Version of Immich Server v1.49.0 ### Version of Immich Mobile App v1.49.0 ### Platform with the issue - [X] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML version: "3.3" volumes: immich_data: external: true services: server: image: altran1502/immich-server:release entrypoint: ["/bin/sh", "./start-server.sh"] volumes: - immich_data:/usr/src/app/upload environment: - NODE_ENV=production - DB_HOSTNAME=postgres - DB_USERNAME=postgres - DB_PASSWORD=${DB_PASSWORD} - DB_DATABASE_NAME=immichdb - REDIS_HOSTNAME=redis - JWT_SECRET=${JWT_SECRET} - ENABLE_MAPBOX=false - MAPBOX_KEY=${MAPBOX_KEY} - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project" - ENABLE_MAPBOX=true env_file: - env hostname: immich-server depends_on: - redis - postgres restart: unless-stopped microservices: image: altran1502/immich-server:release entrypoint: ["/bin/sh", "./start-microservices.sh"] volumes: - immich_data:/usr/src/app/upload environment: - NODE_ENV=production - DB_HOSTNAME=postgres - DB_USERNAME=postgres - DB_PASSWORD=${DB_PASSWORD} - DB_DATABASE_NAME=immichdb - REDIS_HOSTNAME=redis - JWT_SECRET=${JWT_SECRET} - ENABLE_MAPBOX=false - MAPBOX_KEY=${MAPBOX_KEY} - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project" - ENABLE_MAPBOX=true env_file: - env depends_on: - redis - postgres restart: unless-stopped hostname: immich-microservices deploy: resources: limits: cpus: '4.0' memory: 4G machine-learning: image: altran1502/immich-machine-learning:release command: [ "python", "src/main.py" ] volumes: - immich_data:/usr/src/app/upload - /opt/immich-ml/cache:/cache environment: - NODE_ENV=production - DB_HOSTNAME=postgres - DB_USERNAME=postgres - DB_PASSWORD=${DB_PASSWORD} - DB_DATABASE_NAME=immichdb - REDIS_HOSTNAME=redis - JWT_SECRET=${JWT_SECRET} - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project" env_file: - env depends_on: - postgres restart: unless-stopped hostname: immich-machine-learning web: image: altran1502/immich-web:release entrypoint: ["/bin/sh", "./entrypoint.sh"] environment: - DB_HOSTNAME=postgres - DB_USERNAME=postgres - DB_PASSWORD=${DB_PASSWORD} - DB_DATABASE_NAME=immichdb - REDIS_HOSTNAME=redis - JWT_SECRET=${JWT_SECRET} - ENABLE_MAPBOX=false - MAPBOX_KEY=${MAPBOX_KEY} - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project" - ENABLE_MAPBOX=true env_file: - env restart: unless-stopped hostname: immich-web redis: image: redis:6 restart: unless-stopped hostname: immich_redis postgres: image: postgres:14 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} PG_DATA: /var/lib/postgresql/data env_file: - env volumes: - /opt/immich-postgres:/var/lib/postgresql/data restart: unless-stopped hostname: immich_postgres proxy: image: altran1502/immich-proxy:release ports: - 2283:8080 depends_on: - server restart: unless-stopped ``` ### Your .env content ```Shell only secrets ``` ### Reproduction steps ```bash 1. Install Immich 2. Create Albums 3. Open Albums Page ... ``` ### Additional information _No response_
Author
Owner

@raisinbear commented on GitHub (Feb 25, 2023):

What's your architecture? Do you see anything along the lines
immich_postgres | ORC error: No callback manager available for [XYZ]
in the logs / output?
For me this was the case and when opening the albums overview (among others), a lot of CPU was consumed by postgres for a couple of seconds before the page would finally load. I kind of mitigated the issue by specifing jit = off # allow JIT compilation in the relevant - by default commented - line in the postgresql.conf file in the postgres docker volume. It's still slow - and I have the feeling slower than it was a couple of revisions before - but faster now by at least three to four seconds, as the postgres process isn't blocking anymore.

@raisinbear commented on GitHub (Feb 25, 2023): What's your architecture? Do you see anything along the lines `immich_postgres | ORC error: No callback manager available for [XYZ]` in the logs / output? For me this was the case and when opening the albums overview (among others), a lot of CPU was consumed by postgres for a couple of seconds before the page would finally load. I kind of mitigated the issue by specifing `jit = off # allow JIT compilation` in the relevant - by default commented - line in the `postgresql.conf` file in the postgres docker volume. It's still slow - and I have the feeling slower than it was a couple of revisions before - but faster now by at least three to four seconds, as the postgres process isn't blocking anymore.
Author
Owner

@akoyaxd commented on GitHub (Feb 25, 2023):

I actually see a lot of CPU Usage of Postgres, when opening the Album overview. Though I can not find the error message you mentioned in the logs..

@akoyaxd commented on GitHub (Feb 25, 2023): I actually see a lot of CPU Usage of Postgres, when opening the Album overview. Though I can not find the error message you mentioned in the logs..
Author
Owner

@michelheusschen commented on GitHub (Feb 25, 2023):

I know of some album queries that are pretty unoptimized. Are you viewing the page with all albums or selecting a specific album? And could you share how many albums/assets you have and how many assets are in albums? Doesn't have to be exact, just to get a general idea.

@michelheusschen commented on GitHub (Feb 25, 2023): I know of some album queries that are pretty unoptimized. Are you viewing the page with all albums or selecting a specific album? And could you share how many albums/assets you have and how many assets are in albums? Doesn't have to be exact, just to get a general idea.
Author
Owner

@akoyaxd commented on GitHub (Feb 25, 2023):

I currently have 15 albums with mostly ~150 Assets. One has 1100 assets. Yea, I view the page with all Albums.
Opening an Album is reasonable in therms of velocity. Even the large one with 1100 assets.

@akoyaxd commented on GitHub (Feb 25, 2023): I currently have 15 albums with mostly ~150 Assets. One has 1100 assets. Yea, I view the page with all Albums. Opening an Album is reasonable in therms of velocity. Even the large one with 1100 assets.
Author
Owner

@raisinbear commented on GitHub (Feb 25, 2023):

Actually, I don't know if the error itself was the reason for the high cpu load. However, some digging led me to turn of jit, which resolved both error message and cpu load. In case you try this, you have to restart the postgres container.

@raisinbear commented on GitHub (Feb 25, 2023): Actually, I don't know if the error itself was the reason for the high cpu load. However, some digging led me to turn of jit, which resolved both error message and cpu load. In case you try this, you have to restart the postgres container.
Author
Owner

@raisinbear commented on GitHub (Feb 26, 2023):

I just checked again, haven't used the web interface too much recently. Opening the album overview (or merely hovering over the information icon next to the button) really takes quite long. My server is on the weak side, that's why it's probably more noticeable. The jit parameter mentioned earlier takes loading time down from over 9 seconds to roughly 4 seconds for me, but that is still a lot. docker stats shows the postgres container being active for less than a second at roughly 25% CPU load then. The rest of the time is consumed by immich server at full load. I'm very certain that hasn't been the case a few iterations back, (say late December) and I've barely added any assets in the mean time. I'll try to dive in deeper when I have time, but I fear all I can do is find the last version that performed snappy for me. Don't know if that helps.

@raisinbear commented on GitHub (Feb 26, 2023): I just checked again, haven't used the web interface too much recently. Opening the album overview (or merely hovering over the information icon next to the button) really takes quite long. My server is on the weak side, that's why it's probably more noticeable. The `jit` parameter mentioned earlier takes loading time down from over 9 seconds to roughly 4 seconds for me, but that is still a lot. `docker stats` shows the `postgres` container being active for less than a second at roughly 25% CPU load then. The rest of the time is consumed by `immich server` at full load. I'm very certain that hasn't been the case a few iterations back, (say late December) and I've barely added any assets in the mean time. I'll try to dive in deeper when I have time, but I fear all I can do is find the last version that performed snappy for me. Don't know if that helps.
Author
Owner

@titro commented on GitHub (Feb 26, 2023):

can confirm that since 1.48 (i guess so).
Perhaps related to 1582 ?

@titro commented on GitHub (Feb 26, 2023): can confirm that since 1.48 (i guess so). Perhaps related to [ 1582 ?](https://github.com/immich-app/immich/pull/1582)
Author
Owner

@SitramSoft commented on GitHub (Feb 27, 2023):

I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library.

@SitramSoft commented on GitHub (Feb 27, 2023): I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library.
Author
Owner

@alextran1502 commented on GitHub (Feb 27, 2023):

I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library.

Yeah this is the regression from the latest refactor. We are aware of the issue and planning to address this in the upcoming release

@alextran1502 commented on GitHub (Feb 27, 2023): > I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library. Yeah this is the regression from the latest refactor. We are aware of the issue and planning to address this in the upcoming release
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#714