#Jellyseer incredibly slow

21 messages · Page 1 of 1 (latest)

quasi agate
#

Running Jellyseer version 2.7.3 on OAuth2 branch on kubernetes cluster. Seems to be getting slower and slower over time. I can restart it to make things faster briefly, but other times the container itself just doesn't respond (ingress gives me 503 service unavailable). It's basically unusable at this point.

I don't think it's DNS if the container itself won't even respond. It could be that I don't use postgres for the container? It seems like a very simple service that shouldn't resources at all.

#

Just for reference, it can take multiple minutes for the login page to even appear. Then once the main screen finally loads, it can take multiple minutes if I click a movie from the main screen (the movie/tv show details screen takes forever to load).

tight gyro
#

Can you try to run jellyseerr 2.7.3 (not the preview branch) from scratch ? I don't have any issue myself in my kube cluster

quasi agate
#

I was running that before I swapped to OAuth2 with the same issue

#

I only swapped to the OAuth2 branch a few weeks ago

tight gyro
#

when you say slow have you looked in your web browser console ?

quasi agate
#

Here's my helmrelease:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: jellyseer
  namespace: media
spec:
  interval: 15m
  chart:
    spec:
      chart: app-template
      version: 1.5.1
      sourceRef:
        kind: HelmRepository
        name: bjw-s
        namespace: flux-system
  values:
    image:
      repository: docker.io/fallenbagel/jellyseerr
      tag: preview-OIDC
    env:
      TZ: ${TIMEZONE}
      LOG_LEVEL: "info"
    service:
      main:
        ports:
          http:
            port: 5055
    ingress:
      main:
        enabled: false
    podSecurityContext:
      runAsUser: 568
      runAsGroup: 568
      fsGroup: 568
      fsGroupChangePolicy: "OnRootMismatch"
    persistence:
      config:
        enabled: true
        existingClaim: jellyseer-config
        mountPath: /app/config
      cache:
        enabled: true
        existingClaim: jellyseer-cache
        mountPath: /app/config/cache
    resources:
      requests:
        cpu: 200m
        memory: 300Mi
      limits:
        memory: 500Mi
        cpu: 500m
tight gyro
#

Try with our official helm chart, i'm not familiar with app-template as it's not our official install method so I don't know what is going on under the hood

quasi agate
#

Even cached it looks like the main js bundles take over 2s to load

tight gyro
#

for example we don't have any requests/limits so maybe your values are too low

quasi agate
#

I'm going to try again without cache here in a minute, and I can pump up those resource values to give it a try. I don't understand why it needs so much resources though.

Sometimes I see this in the container logs:

Warning: data for page "/" is 264 kB which exceeds the threshold of 256 kB, this amount of data can reduce performance.
See more info here: https://nextjs.org/docs/messages/large-page-data

Large Page Data
night marlin
#

Can yi ualso try turning on settings > network > ipv4 first

quasi agate
#

Of course today its being fast grr

quasi agate
#

I guess the last time I tried to fix this in September, I increased the limits to what they are now

#

But the container does not restart, so if the limit was too low I would expect the container to restart

#

Anyway I'll try swapping to the legit helm chart and keep a better eye on the console when this happens in the future. But is it worth transitioning from sqlite to postgres?

tight gyro
#

It's the same pro/con like for every apps, if you prefer to handle it using postgres or sqlite or if you need HA etc...

#

if you need only one instance, don't have existing postgres cluster, don't need HA just use sqlite 🙂

night marlin