Having errors with Album since v1.88.0 / v1.88.1 (FIXED IN v1.88.2)
Not all albums get shown on the mobile app.
And it's really slow to open albums
not sure if this is relevant to the new version
97 Replies
can you go to the Photos page and make sure that the spinning icon stop spinning?
this one?
ah you are talking about the web
how many album do you have?
18 Albums
most of them have 200 files but 3 of them have 9000, 4000 and 1200
Can you open the dev console (F12) go to Network tab, put in the search bar "album" and refresh the album page and look for this request
look at the timing tab too
damn, pretty long on your system
is this over your DNS or local IP?
local ip
well over a traefik proxy but yeah
can you expand the Size column to see how big is the response?
I tihnk im blind where is that š
25kb
takes around 700ms now
WHAT
and it takes that long
weird
can you bypass traefik?
yeah ill just open the port anyway
one second
alright so it isnt traefik
good news though, I can see the albums in the app now
Oh well ill go to sleep right around now, ill check if the problem persists tomorrow
btw LOL
that was the album I was talking about
We might have introduced some unoptimized query for the album
Thank you for the reporting
Will fix it
oh and im not sure but I think the search function doesn't work properly on the non default user
looking for something gives me some alumbs and a untitled one as well as some photos and videos sorted by date
Thanks, will fix that as well
sorry for the trouble !
@martabal look like we have query need to be optimized for the virtual column here
Weird, I tested the queries with my prod instance and results were good (0.003 s for 500 assets) š¤
problem persists in 1.88.1 and a reboot, nothing to find in logs
just checked with my phone via the safari browser and on my laptop, same issues
works instantly in the immich app though
How much time does it take you to execute SELECT MIN(assets."fileCreatedAt")
FROM "assets" assets
JOIN "albums_assets_assets" aa ON aa."assetsId" = assets.id
WHERE aa."albumsId" = ā<your_biggest_albumId>ā ?
am I doing this right? (I don't do a lot of stuff with dbs lol)
postgres=#
Are you in the correct db ?
\c <your_immich_db_name>
yeah im in the immich db
ERROR: column "7840e53a-81f9-4c34-abfb-cc703da8c7c2" does not exist
ok fixed
my mistake
that was instant
For the loong respone time only exist with old albums and not if I create new albums
oh so im not the only one?
Nope, same issue here
Does the album size matter ?
the bigger the longer it takes from my experience
9000 file album takes 2-3 minutes
4000 file album takes takes around 1 minute
600 file album around 10 seconds
30 file album 2 seconds
in the app they're all instantly
Damn 2 seconds for 30 files is insane
Yep size does matter on the album
I retract my comment on it does not effect on new albums, it's the size of the album that really make the load time awful
And my fans also usually go off, so it's definitely doing something lol
since 1.88?
The fans of your server right ?
sorry that was an overstatement its more like 500ms
yeah
is it also instant for you in the app?
I changed a bit the persisted datas in the client, this is probably unrelated, but did you try with a new private sessions ?
I tried a couple browsers, same speeds on private firefox window
I tried in different client like Safari, Chrome, Edge, FireFox. same issue. When loading album does CPU usage rocking high when load album
from normal 2% usages to 65+%
Yep since 1.88 and 1.88.1
since the app is unaffected, I would think it's cause there isn't a web container anymore
but I don't know enough to make those assumptions :/
well it's Postgres going nuts , when loading the album š
This is what i got from the log in the Mobile app on iOS after my upgrade:
'2023-11-21 10:39:16.037308,LogLevel.SEVERE,"ImmichErrorLogger","Catch all error: ApiException 400: HTTP connection failed: GET /album/09061d0f-fb67-490f-95dc-997d2829ff35 (Inner exception: Bad file descriptor)
Album is now load andrunning fin on the mobile, but had this hickup
let me update the app to test
was using 1.87.0
GLHF š
seems to work on my app š„³
No issues on the album list ?
list is fine, only have two albums so far. I might not be the right one to ask, but page load in a split second
I had problems once but that resolved itself
didnt show all albums in the app at first
so I only have problems in the web app
Ok I experience what you have
not as much as you but I can see a difference
Happy to hear I'm not the only one seeing this. Do you need more info being able to troubleshot this?
No, I think I'm good, thank you
@Alex I think the issue is here : https://github.com/immich-app/immich/blob/5c0821330fb4f45c6197c9ef64842601ee48f65a/server/src/domain/album/album.service.ts#L84
Changing to reduce the function call from 500 ms to 9 ms for > 500 assets
I don't think you need the album with all the assets on the page load, just the album's data
I have the same problem with jumping in an album and back to album-view, postgress eating all CPU's
291691 70 20 0 311620 197660 171004 S 63,8 1,6 0:04.22 postgres
154695 root 20 0 1299560 238132 48160 S 31,2 1,9 6:03.97 immich_server
291679 70 20 0 172812 141020 137240 S 2,7 1,1 0:01.07 postgres
291687 70 20 0 172456 80352 76928 S 2,7 0,7 0:00.31 postgres
291688 70 20 0 311704 196120 169444 S 2,3 1,6 0:02.03 postgres
291690 70 20 0 172364 138736 135252 S 1,3 1,1 0:00.41 postgres
153553 root 20 0 1270996 42648 22688 S 1,0 0,3 0:25.82 caddy
291680 70 20 0 172364 138616 135160 S 1,0 1,1 0:00.37 postgres
291705 70 20 0 172364 75864 72512 S 1,0 0,6 0:00.20 postgres
291706 70 20 0 172264 67480 64204 S 1,0 0,6 0:00.19 postgres
291659 70 20 0 172684 92440 88764 S 0,7 0,8 0:00.80 postgres
291689 70 20 0 172684 90052 86364 S 0,7 0,7 0:00.50 postgres
15 root 20 0 0 0 0 I 0,3 0,0 5:30.45 rcu_sched
870 root 20 0 2743908 63644 25928 S 0,3 0,5 19:17.94 dockerd
Opening the album view (aprox 100 different albums) takes very long
What takes so long ?
Going from the album list to the album view or album view to album list ?
Going to /albums š
better: from INSIDE of an album back to /albums
Complete process takes about 4.2 seconds
Weird, I have 2 times better performance for the album list since v1.87.0 š¤
Another user on the same system (12CPU / 12GB RAM) with "only" 55 albums does NOT have the problem
how much time ?
the other user?
yes
mom
No the time the user takes to load /api/album
I takes you 1.21 seconds
how long does it take to the other user ?
the other user has about 0.6sec delay
oh yeah this seems relevant I am accessing a shared album but the time to access is the same on both users
0.8 deleay before all thumbs are loaded
complete page reload takes more than 2 Seconds of waiting for server
ARGG, same on android app, takes forever to open Bibliothek / Album View
only postgres is running high during opening /albums
154695 root 20 0 1303224 242060 48216 R 66,1 2,0 8:40.25 immich_server
308166 70 20 0 172356 43876 40592 S 7,3 0,4 0:00.22 postgres
308170 70 20 0 172356 42400 39116 S 5,3 0,3 0:00.16 postgres
308171 70 20 0 172280 42024 38804 S 5,0 0,3 0:00.15 postgres
153553 root 20 0 1270996 40584 22716 S 4,7 0,3 0:35.86 caddy
308172 70 20 0 172244 40796 37588 R 4,3 0,3 0:00.13 postgres
308169 70 20 0 172600 41996 38788 R 3,7 0,3 0:00.11 postgres
308168 70 20 0 172356 40168 36884 S 3,0 0,3 0:00.09 postgres
308173 70 20 0 172596 40268 36808 R 3,0 0,3 0:00.09 postgres
308165 70 20 0 172356 41196 37912 S 2,7 0,3 0:00.08 postgres
308167 70 20 0 172356 39452 36172 S 2,3 0,3 0:00.07 postgres
308077 70 20 0 172356 40964 37628 S 1,0 0,3 0:00.32 postgres
153542 lxd 20 0 33512 5492 2680 S 0,3 0,0 0:43.40 redis-server
155175 vegasys+ 20 0 17468 8592 5888 S 0,3 0,1 0:21.51 sshd
155178 vegasys+ 20 0 7368 3420 3160 S 0,3 0,0 0:28.56 bash
271354 root 20 0 1853892 401148 118908 S 0,3 3,3 0:15.91 gunicorn
306805 root 20 0 11076 4528 3636 R 0,3 0,0 0:00.64 top
1 root 20 0 167628 11760 6928 S 0,0 0,1
(log was taken to late, much higher CPU usage a coulple of seconds before)
yes, it depends on how much albums are present. With less than 30 albums, it's "okay" - but if you go beyond 100 albums it is very slow
FYI: No errors under docker compose logs -f
Good job š Many thanx
I would be interested to have reports for this fix (you just have to replace the server docker tag by
pr-5224)
Even with the assets of my prod instance loaded, it was hard to experience the delays you guys reported but I think this is because I don't have as much assets as youPardon, what do I have to do? š
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
command: [ "start.sh", "immich" ]
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload
env_file:
- .env
ports:
- 127.0.0.1:2283:3001
depends_on:
- redis
- database
- typesense
restart: always
Yeah, replace
${IMMICH_VERSION:-release} by pr-5224
then I think a docker compose down && docker compose pull && docker compose up -d should do the trickjupp
give me a minute
MUCH faster now
could you do the same with /sharing ?
screenshot above with more than 100 albums
Much faster!
but yeah it seems like /sharing album list isnt as fast as /albums yet
once that's fixed this conversation can be closed š
Thanks, search on non default user seems to be fixed!
interisting: Even after this change the performance is worse than before 1.88 ....
Pushing out hot fix
thank you for the hard work guys!
I have never used a service and got fixes on the same day this many times before
š
OK release is out and confirmed fixed theissue
Works again, thank you š
Sorry for the trouble everyone š
no problem man, these perf related issue is hard to measure without meaningful test instance