Docker taking up a lot of space

[roughnecks]

Playbook Configuration:

My vars.yml file looks like this:

# Enable/Disable presence
matrix_synapse_presence_enabled: true

# Serve the base domain as well (unless you already have something serving it)
matrix_nginx_proxy_base_domain_serving_enabled: true

# Shared Secret Auth password provider module
matrix_synapse_ext_password_provider_shared_secret_auth_enabled: true
matrix_synapse_ext_password_provider_shared_secret_auth_shared_secret: blah

# Heisenbridge
matrix_heisenbridge_enabled: true

# Telegram
matrix_mautrix_telegram_enabled: true
matrix_mautrix_telegram_api_id: blah
matrix_mautrix_telegram_api_hash: blah

# Whatsapp
matrix_mautrix_whatsapp_enabled: true
matrix_mautrix_whatsapp_configuration_extension_yaml:
  bridge:
    displayname_template: "{{ '{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)' }}"
    personal_filtering_spaces: true

# Reminder BOT
matrix_bot_matrix_reminder_bot_enabled: true
# Adjust this to whatever password you chose when registering the bot user
matrix_bot_matrix_reminder_bot_matrix_user_password: blah
# Adjust this to your timezone
matrix_bot_matrix_reminder_bot_reminders_timezone: Europe/Berlin

# Twitter
matrix_mautrix_twitter_enabled: false

# Steam
matrix_mx_puppet_steam_enabled: false

# Synapse retention rules
matrix_synapse_configuration_extension_yaml: |
  retention:
    # The message retention policies feature is disabled by default. Uncomment the
    # following line to enable it.
    #
    enabled: true
    # Default retention policy. If set, Synapse will apply it to rooms that lack the
    # 'm.room.retention' state event. Currently, the value of 'min_lifetime' doesn't
    # matter much because Synapse doesn't take it into account yet.
    #
    default_policy:
      min_lifetime: 1d
      max_lifetime: 90d

  database:
    # Reduce number of postgres idle connections
    args:
      cp_min: 3
      cp_max: 5

# Synapse Admin
matrix_synapse_admin_enabled: false

# PostGres Backup
matrix_postgres_backup_enabled: true
matrix_postgres_backup_keep_days: 1

# Postgres
matrix_postgres_process_extra_arguments: [
  "-c max_connections=75",
  "-c shared_buffers=96MB",
]

# Element Client
matrix_client_element_enabled: false

Matrix Server:

• OS: Debian 11
• Architecture amd64

Problem description:

My problem is that:

root@pandora:/var/lib/docker/overlay2# du -hs
5.1G    .

Used space is increasing fast and I don't have much left. I'm on a low tier VPS. I tried: # docker system prune -a but only a couple hundred MB were released. I checked online and it looks like I'm not alone on this issue but I haven't gone very far with finding a solution.

If you read my vars.yml you can see that I enabled and subsequently disabled some of the modules, so I'm not sure if docker images changes could do that to the overlay2 folder.

Last time I checked with df -h (yesterday) I had 6.5GB used on /, today it's 7.8. This is just a personal HS with my user being the only one logged - registration is disabled.

Any help would be much appreciated, thanks.

[thebiblelover7]

@roughnecks Is the matrix-docker-ansible-deploy playbook the only thing installed? Or do you have other services installed with docker?

Mine is pretty big too (I have a lot of other services running):

/var/lib/docker/overlay2# du -hs
40G .

After removing unused images from Portainer, it got reduced to 23G.

/var/lib/docker/overlay2# du -hs
23G .

[roughnecks]

@roughnecks Is the matrix-docker-ansible-deploy playbook the only thing installed? Or do you have other services installed with docker?

I've got no other services, just matrix.

[thebiblelover7]

@roughnecks I have no idea then, but 5 gb seems to me like a reasonable amount for just the docker images necessary for you to run your matrix server + the bridges.

[roughnecks]

It's just that since when it was 6.5GB on / I have only removed stuff, not added anything, but disk space increased.. This is what I don't understand.

Thanks for your answer though.

[thebiblelover7]

@roughnecks That is weird, though... Maybe some things are getting stored there that aren't supposed to be.

[roughnecks]

This is also interesting:

root@pandora:~# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          10        9         2.604GB   116.6MB (4%)
Containers      9         9         0B        0B
Local Volumes   1         1         0B        0B
Build Cache     0         0         0B        0B

Only 2.6GB reported; sorry if this isn't what I think, I'm new to docker and all this stuff.

[roughnecks]

New data: https://paste.debian.net/hidden/f29afda1/

There's a lot of dir inside "overlay2" and the ones on top are my images.

[spantaleev]

Try stopping services (run the playbook with --tags=stop) and evaluate the situation then. The du value should be close to what docker system df says.

When containers are running, they take up additional space in /var/lib/docker/overlay2 (well, or elsewhere, depending on the Storage Driver - docker info | grep 'Storage Driver').

[roughnecks]

Yeah, when stopped, disk pace is equal... so is it normal to have it doubled when the playbook is running(?)..

root@pandora:/var/lib/docker/overlay2# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          10        0         2.604GB   2.604GB (100%)
Containers      0         0         0B        0B
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B
root@pandora:/var/lib/docker/overlay2# du -hs
2.7G    .
root@pandora:/var/lib/docker/overlay2# docker info | grep 'Storage Driver'
 Storage Driver: overlay2

[spantaleev]

Yes, it is. Container image layers are extracted and organized to make up each existing container's filesystem.

Different storage drivers may handle this more efficiently. In any case, this is a Docker thing and not an issue with the playbook itself.

[roughnecks]

I see, thanks for explaining.