CPU and memory usage spike after login resulting in fatal out of memory error


I’m trying to run vikunja but within about ~5 seconds of logging the docker container running the API has a CPU and memory usage spike and then crashes with an fatal out of memory error.

I’m using a Digital Ocean VPS with one CPU core, 1GB of memory, Ubuntu 18.04.6 LTS and Apache as the reverse proxy.

Actions taken:

  1. Created docker-compose.yml
  2. Setup apache virtualhost for proxy and frontend.
  3. Ran docker-compose up
  4. Registered user account and am logged-in.
  5. API container crashes with memory error.
  6. Frontend returns to login page.

container log: https://files.verifiedjoseph.uk/vikunja-api-container-log.txt


version: '3'
    image: vikunja/api
    container_name: vikunja-api
    restart: always
      - ~/apps/vikunja/files:/app/vikunja/files
      - 3456:3456
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/database/vikunja.db


How much memory is Vikunja using? How much free memory has your system available when you start it?

It does not look like this is a problem with logging in itself but some other part of it.

HI, kolaente

Thanks for replying

The container its self is using ~11MiB (docker stats) after I start it but before I login.

Server: (free -m results)

              total        used        free      shared  buff/cache   available
Mem:            985         494         166         152         324         205
Swap:             0           0           0

From looking at htop when I login to vikunja, its four cloud-init devel hotplug-hook -s net query processes causing the spike in CPU usage.

From Googling, there is an issue with cloud-init and cpu spikes (Bug #1946003 “hotplug causing cloud-init to spike CPU usage” : Bugs : cloud-init). I’m not sure why it’s only having when I login to vikunja.

That doesn’t sound like Vikunja uses up all the memory it can get. During login, it might need a bit more cpu and memory to check the password hash, but from the logs you sent it does not look like it is crashing during that but after it already logged in successfully.

If you’re hitting the issue you linked, it should be enough to start the Vikunja container and wait a bit.

You’re correct. Its crashing after the login.

I left the container running for 30 mins and tried again, it still crashed. I think I’ll wait for canonical to push out a fix for the linked cloud-init bug and see if that fixes it.

Thanks for your help.


1 Like

As a workaround, have you tried setting up a swap partition? 200 MB available should be enough, but maybe the extra swap would help in situations where it needs a bit more for a burst.

I setup a 200MB swap file (and confirmed it is being used), it still crashed. :upside_down_face: