#high memory usage using compiled binary in docker

14 messages · Page 1 of 1 (latest)

junior saffron
# 
FROM denoland/deno:2.2.3 AS builder
WORKDIR /app
COPY . .
RUN deno task build
RUN deno compile \
  --allow-read --allow-write --allow-net --allow-env \
  --include dist/ --output candiru main.ts

# Runtime stage
FROM debian:bookworm-slim
WORKDIR /app
COPY --from=builder /app/candiru .
EXPOSE 3000
CMD ["/app/candiru"]

I'm fairly new to docker. I tried something similar to what's in the docs here, with deno task build in the build stage, before trying to run the compiled version of my app.

Memory usage is very high (800mb) in both versions. Running the compiled version of the app on my machine only uses around 70mb.

How can I decrease the memory usage of the docker container? I'd love to get it under 200mb.

Any help would be greatly appreciated!
link to my repo for context if that helps:
https://github.com/candirugame/candiru

stone dome
#

From what I've seen, Deno version 2 and up has a higher start up memory cost when run in Docker. I've seen similar numbers to what you're describing. They have eventually dropped a bit but the baseline is still several hundred mb higher than prior to Deno v2.0.0

junior saffron
#

I’ve noticed that setting the memory limit around 800 drops it to around 500, which is still much higher than I’d like

#

Setting it below 800 causes a crash :/

rocky jasper
#

They have eventually dropped a bit
Have links for that? I'm interested in containerized performance. That almost sounds like a bug. (ex: JVMs used to use the OS memory, not the container memory, to allocate initial heap.)

#

@junior saffron how big is that dist/ that you include? I wonder if it's getting loaded into memory at startup?

junior saffron
rocky jasper
#

Yes, deno compile --include includes the file contents into the compiled file so that they're available at runtime without having to read them from disk.

junior saffron
#

The compiled exe is roughly 700mb.. wondering if the entire thing gets pulled into memory?

image.png
rocky jasper
#

700mb? And your dist/ was only 12MB? So you just have a LOT of dependencies?

#

Running the compiled version of the app on my machine only uses around 70mb.
Is that binary also 682 MB? If not, it seems your build processes have diverged.

junior saffron
# rocky jasper 700mb? And your dist/ was only 12MB? So you just have a LOT of dependencies?

Maybe.. does this seem excessive?
deno.json

    "imports": {
        "@deno/vite-plugin": "npm:@deno/vite-plugin@^1.0.0",
        "@oak/oak": "jsr:@oak/oak@^17.1.3",
        "@std/http": "jsr:@std/http@^1.0.10",
        "vite": "npm:vite@^5.4.8"
    },

package.json

"dependencies": {
        "@analogjs/content": "^1.10.1",
        "@analogjs/platform": "^1.10.1",
        "@analogjs/router": "^1.10.1",
        "@angular/animations": "^19.0.0",
        "@angular/common": "^19.0.0",
        "@angular/compiler": "^19.0.0",
        "@angular/core": "^19.0.0",
        "@angular/forms": "^19.0.0",
        "@angular/platform-browser": "^19.0.0",
        "@angular/platform-browser-dynamic": "^19.0.0",
        "@angular/platform-server": "^19.0.0",
        "@angular/router": "^19.0.0",
        "@semantic-release/git": "^10.0.1",
        "@types/three": "^0.169.0",
        "dot-prop": "^9.0.0",
        "fdir": "^6.4.2",
        "front-matter": "^4.0.2",
        "joi": "^17.13.3",
        "marked": "^5.0.2",
        "marked-gfm-heading-id": "^3.1.0",
        "marked-highlight": "^2.0.1",
        "marked-mangle": "^1.1.7",
        "npm": "^10.9.1",
        "prismjs": "^1.29.0",
        "rxjs": "~7.8.0",
        "semantic-release": "^24.1.2",
        "socket.io": "^4.8.0",
        "socket.io-client": "^4.8.0",
        "three": "^0.169.0",
        "three-mesh-bvh": "^0.8.2",
        "tslib": "^2.3.0",
        "vite": "^5.4.11",
        "zone.js": "~0.15.0"
    },
junior saffron
rocky jasper
#

I just mean, you said you can compile it and run it outside of docker and it only takes 70mb. that's 1/10th the size. I wonder if you're compiling a very different set of dependencies. (and that --include dist/ looks like a likely cuplrit.)