Debian13: eturnal 1.12.x allocates >2 GB of memory at launch

[schildbach]

I'm using the Docker image, and granting 2 GB of memory leads to OOM (code 137). Versions before 1.12 were fine with 128 MB.

I have no active TURN sessions:

eturnal 1.12.2 on Erlang/OTP 27 (ERTS 15.2.7.1)
Uptime: 0 days, 0 hours, 2 minutes, 23 seconds
Active TURN sessions: 0
Processes: 81
Total length of run queues: 1
Total CPU usage (reductions): 1779034
Allocated memory (MiB): 2093

[sando38]

Hmm. I cannot reproduce the issue, care to share your docker run command, the platform you use, etc.? the allocated memory certainly is way to high.

saarko@DESKTOP-5EP0JF1:~$ docker run --rm -d --name eturnal -m=2g eturnal/eturnal:1.12.2 
4fdcb263883708f0cc73e5654b85faec3f793a3ea75b1746032b4df7c6547328
saarko@DESKTOP-5EP0JF1:~$ docker exec -it eturnal eturnalctl info
eturnal 1.12.2 on Erlang/OTP 27 (ERTS 15.2.6)
Uptime: 0 days, 0 hours, 11 minutes, 10 seconds
Active TURN sessions: 0
Processes: 83
Total length of run queues: 1
Total CPU usage (reductions): 1862544
Allocated memory (MiB): 64

[schildbach]

This is my compose.yaml:

services:
  eturnal:
    image: my-registry/eturnal:1.12.2
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - "no-new-privileges"
    network_mode: "host"
    volumes:
      - ./eturnal.yml:/etc/eturnal.yml:ro
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 2.5G
#          memory: 128M
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "eturnalctl ping || exit 1"]
      interval: 10s
      timeout: 5s

As you can see, no specific command line or entrypoint, just the ones from your Dockerfile:

            "Cmd": [
                "/bin/sh",
                "-c",
                "run.sh"
            ],
            "Entrypoint": [
                "/sbin/tini",
                "--"
            ],

I'm using the Docker packages that come with Debian Trixie (all updated):

# dpkg -l "docker*"
ii  docker-buildx             0.13.1+ds1-3      amd64        Docker CLI plugin for extended build capabilities with BuildKit (program)
ii  docker-cli                26.1.5+dfsg1-9+b9 amd64        Linux container runtime -- client
ii  docker-compose            2.26.1-4          amd64        Define and run multi-container applications with Docker (program)
ii  docker.io                 26.1.5+dfsg1-9+b9 amd64        Linux container runtime

[sando38]

Thanks, I checked the compose on my end as well with the exact same result of 64MB memory allocated. Will think shortly and come back.

P.S. my docker version for reference

$ docker version
Client: Docker Engine - Community
 Version:           28.3.3
 API version:       1.51
 Go version:        go1.24.5
 Git commit:        980b856
 Built:             Fri Jul 25 11:34:04 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.3.3
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.5
  Git commit:       bea959c
  Built:            Fri Jul 25 11:34:04 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[weiss]

@schildbach, just to track things down, you could check whether enforcing immediate garbage collection brings down memory usage:

docker exec -it eturnal eturnalctl remote_console

Copy the following call (including the trailing .) into that console and hit <Enter>:

lists:foreach(fun erlang:garbage_collect/1, erlang:processes()).

To exit the shell: <Ctrl>+g, <Enter>, q, <Enter>.

[schildbach]

I ran

docker exec -it turn-eturnal-1 eturnalctl remote_console

It blocks for a couple of seconds, then runs OOM (137). I lifted my memory limit (so it's now at 3.7 GB), but the same happens.

[schildbach]

Here is my daemon.json just in case:

{
  "storage-driver": "btrfs",
  "ipv6": true,
  "fixed-cidr-v6": "fd00::/80",
  "userland-proxy": false,
  "experimental": true,
  "iptables": true,
  "ip6tables": true,
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 },
    { "base": "fd00::/104", "size": 112 },
    { "base": "fd01::/104", "size": 112 },
    { "base": "fd02::/104", "size": 112 },
    { "base": "fd03::/104", "size": 112 },
    { "base": "fd04::/104", "size": 112 },
    { "base": "fd05::/104", "size": 112 },
    { "base": "fd06::/104", "size": 112 },
    { "base": "fd07::/104", "size": 112 }
  ],
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "3"}
}

I once read that sometimes the address pools can be too many, too large, too small and then they consume too much RAM. However in previous eturnal versions there was no such problem, and the above address pools I think have become default on later Docker versions anyway.

[sando38]

Thx, just to ensure this is not the issue, when you do not set any limit at all, does eturnal still report consumption of 2GB, 3.5GB or more?

[schildbach]

According to "docker stats":

CONTAINER ID   NAME                        CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
5d8c6a7339f4   turn-eturnal-1              0.01%     2.104GiB / 3.736GiB   56.33%    0B / 0B           25.8MB / 0B       22

According to "eturnalctl info":

Allocated memory (MiB): 2093

This is without memory limits.

[schildbach]

And my eturnal.yml is this:

# A more detailed, commented example configuration can be found here:         
# https://github.com/processone/eturnal/blob/master/config/eturnal.yml         
eturnal:
  log_dir: stdout
  modules:
    mod_log_stun: {}
  secret: "xxx"
  blacklist:
    - recommended

[sando38]

Thx, I created a Debian13 VM, installed docker.io package and simply ran docker run --name eturnal eturnal/eturnal:1.12.2 and have the same (high) memory consumption. We will debug it 👍

[shoutmarble]

I had been noticing slow starts...

docker compose up

docker compose down

eturnal.yml

eturnal:
  realm: "turn.landingdev.xyz"
  secret: "cpCc17rcrz--------------qlsNLNG"

  relay_ipv4_addr: "185.28.22.166"
  relay_ipv6_addr: "2a02:4780:10:e8ad::1"

  relay_min_port: 49500
  relay_max_port: 49800

  listen:
    - ip: "::"
      port: 3478
      transport: udp
      enable_turn: true

    - ip: "::"
      port: 3478
      transport: tcp
      enable_turn: true

    - ip: "::"
      port: 5349
      transport: tls
      enable_turn: true

  tls_crt_file: /opt/eturnal/tls/certificate.pem
  tls_key_file: /opt/eturnal/tls/private.key

compose.yml

networks:
  npm_net:
    external: true
    name: npm_net

services:

  eturnal:
    image: ghcr.io/processone/eturnal:latest-alpine

    container_name: turn

    restart: unless-stopped
    user: 9000:9000

    ### security options
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true

    networks:
        npm_net:
            ipv4_address: 10.10.30.10
            ipv6_address: fd12:3456:789a::30:10

    ### networking options
    ports:
     - 3478:3478/tcp    # STUN/TURN non-TLS
     - 3478:3478/udp    # STUN/TURN non-TLS
     - 5348:5348/tcp    # STUN/TURN TLS
     - 5349:5349/tcp    # STUN/TURN TLS
     - 49500-49800:49500-49800/udp # TURN relay range

    ### Volume mounts - Note: directories/files must be
    ### (at least) readable by the eturnal user (9000:9000)
    volumes:
      - ./eturnal.yml:/etc/eturnal.yml:ro           # for custom config file
      - ./ACME.185.28.22.166:/opt/eturnal/tls:ro    # for custom tls files

[sando38]

Also with Debian13?