go-vikunja / vikunja

Mirror of vikunja from https://code.vikunja.io/api
GNU Affero General Public License v3.0
773 stars 56 forks source link

Vikunja eating memory with large swap enabled on Raspberry Pi #97

Open DaCHack opened 7 months ago

DaCHack commented 7 months ago

Description

Running Raspberry Pi OS on a RPi4 2GB

Vikunja runs fine under default settings with less than 5% memory usage. When enabling 2GB of swap for another app I noticed that suddenly Vikunja took 40% of physical memory filling up the entire physical memory. Swap file was not used by the system yet due to swappiness at 0. Still, system got extremely slow so I need to revert back to default settings and disable swap to have all service available to the users again.

Vikunja Frontend Version

0.21.0

Vikunja API Version

0.21.0

Browser and version

Edge

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

kolaente commented 7 months ago

Is this about the frontend or API? How are you running Vikunja? Did it use the memory as cache or as actual memory?

DaCHack commented 7 months ago

I am not sure about frontend or API: Both is running as a docker container on my RPi. I think in htop it was /app/vikunja/vikunja with multiple threads eating the memory - cannot reproduce right now without breaking the system again. I run both at latest docker images for arm64 as well as linuxserver/mariadb:10.6.13 in the stack. It was using actual memory.

kolaente commented 7 months ago

Sounds like a problem of the api. Were you doing anything during that time? Did it happen at a specific time? Anything in the logs when it happened?

DaCHack commented 7 months ago

No, I was not doing anything yet. I occured right after the reboot to enable swap and did not stop until I stopped the containers for vikunja.

The logs show a couple of timeouts from database connections that I assume stem from the large latency when the system was memory flooded (while I do not get why it was slow despite no swap was used...). Also this occurred as first output after boot which might have the same root cause since eventually vikunja was able to connect:

2023-11-27T21:57:04.02580685Z: CRITICAL ▶ migration/Migrate 002 Migration failed: dial tcp: lookup db on 127.0.0.11:53: no such host
2023-11-27T21:57:05.653843555Z: CRITICAL    ▶ migration/Migrate 002 Migration failed: dial tcp 172.22.0.4:3306: connect: connection refused
2023-11-27T21:57:07.051648955Z: CRITICAL    ▶ migration/Migrate 002 Migration failed: dial tcp 172.22.0.4:3306: connect: connection refused
2023-11-27T21:57:08.666376493Z: INFO    ▶ migration/Migrate 052 Ran all migrations successfully.
2023-11-27T21:57:08.670324654Z: INFO    ▶ cmd/func25 054 Vikunja version v0.21.0
kolaente commented 7 months ago

Does it always happen or only sometimes?

DaCHack commented 7 months ago

It happened on two consecutive boots

kolaente commented 7 months ago

Not sure how to reproduce this - I've never noticed this on any of the instances I run myself. Please report back if you can pin it down to something more clearly. I'll keep an eye on it as well.