Closed Lumino2 closed 1 year ago
@Lumino2
I highly doubt this is a gluetun problem. I run gluetun plus 12 other Docker containers in a Proxmox CT w/4GB of RAM. Resource usage is very low, and performance is excellent with Speedtest.net results through the VPN typically in the 500-600Mbps both up and down. I'm running Debian 11.6 as the Proxmox CT OS.
Im also running debian 11 on a fresh proxmox installation with 1 VM. Speed is not an issue. I've ran other docker containers and memory was stable. As soon as I start the gluetun container and run some traffic through it, the memory skyrockets.
@Lumino2
There's really no reason to run gluetun in a Proxmox VM -- from a resource usage standpoint it's much better to run it in a Proxmox CT. Also, Alpine is great for building small footprint Docker containers, but I think Debian is a better choice for a Proxmox container.
So, my suggestion is rather than trying to figure out where the issue lies with your inefficient current setup -- why not spin-up a Proxmox CT with Docker? 2 CPUs and 4GB of RAM should be sufficient. There's one small change you need to make to the Proxmox .conf file for any OpenVPN or Wireguard use in a Proxmox CT, but I detailed that here: https://github.com/qdm12/gluetun/discussions/1482
@Lumino2
Since it's been a few months since I tried gluetun in a Proxmox VM rather than a CT, I spun-up a VM running Debian 11.7 with Docker, gluetun and the linuxserver.io Firefox container. I ran a few Speedtests, and other traffic through the VPN with no indication of a memory leak or overflow (2 CPUs and 8GB RAM). The Firefox container requires more resources than most, but ran fine. As mentioned in my previous comment, this is not a resource efficient setup, but other than that I saw no issues.
If there's some reason you really want to use a VM rather than a CT, I'd look to your use of Alpine as the OS, or qBittorrent as likely culprits.
Thanks for the effort, I tried firefox and memory usage was fine. I conclude that it's a qbittorrent issue. Will try the more efficient setup you recommended and thus this can be closed. Thanks!
I conclude that it's a qbittorrent issue.
Are you running both in the same container? You can always run a shell or exec in a container and call top
to see which process holds memory. On alpine you could use htop with apk add htop; htop
I've had luck disabling unbound and Docker health check.
How did you disable the healthcheck? I thought it couldn't be disabled so I just pointed mine to localhost with "HEALTH_TARGET_ADDRESS=127.0.0.1:9999"
In docker compose:
services:
gluetun:
container_name: gluetun2
image: qmcgaw/gluetun
restart: unless-stopped
healthcheck:
disable: true
In docker compose:
services: gluetun: container_name: gluetun2 image: qmcgaw/gluetun restart: unless-stopped healthcheck: disable: true
Thank you, I thought it was an environment variable to make gluetun itself stop doing a healthcheck, I didn't know that docker could stop it.
For everyone reading this thread, i invested more time in this and resolved the issue. I set up a dedicated Docker container for qbittorrent & gluetun, allocating 4GB of RAM with ballooning enabled. While Proxmox's interface indicates full RAM usage, checking via Proxmox's terminal and HTOP shows only 4GB of RAM is actually in use.
Is this urgent?
No
Host OS
Alpine
CPU arch
x86_64
VPN service provider
Surfshark
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2023-06-12T13:56:16.720Z (commit 83826e1)
What's the problem 🤔
I'm running proxmox => linux alpine => docker (gluetun + qbittorrent) The setup works correctly but as soon as traffic is sent through gluetun RAM usage builds up rapidly until the server becomes really slow. When gluetun is idle, memory usage stays the same level. I have 16GB of ram dedictated to the vm that only runs 2 docker instances which should be plenty. I don't see the cause in the logs. Anyone can help?
Share your logs
Share your configuration