Best docker image for Elixir (glibc, malloc, musl)

Just saw this comment on HN:

„ Uses alpine images for small footprint

That’s really become a docker meme. Please be aware you’re sacrificing performance due to not using glibc. glibc has thread-local pools for malloc, afaik musl uses locks.„

I always try to use alpine images. Does this make the Beam run slower than with other images?

3 Likes

Personally I use the slim variants which are usually the latest Debian release. A lot of other images have Buster tags at the moment but the official Elixir image is still only offering Stretch.

I used to use Alpine but I moved to using Debian for all of my base images at least a year ago.

Personally I sleep better at night knowing I’m using super well tested libraries at the cost of only having images that are maybe 50-100mb larger in practice on a real world app. I never ran into a project where that file size difference made a difference. If you were running at “roflcopter” scale you would probably pre-seed your host images with your base Docker image already on the system so it’s not a network win.

1 Like

I think Alpine is also well tested, maybe not as well as Debian, but still. But what I’m wondering is the malloc vs musl question and how it affects the BEAM?

That’s partly why I switched to Debian. It’s to avoid having to think about these things and wondering if some low level alternate implementation of a popular library is going to cause issues.

A few years ago I remember a post on Reddit where someone ran an artificial benchmark that performed ~10,000 SQL queries from a web app into PostgreSQL using psycopg2 (a Python library to interface with Postgres) and it was noticeably slower with Alpine vs Debian.

I don’t know if that would be the same with Elixir but it’s an example where choosing your base image may have performance implications, although in this case it’s hard to say how useful that benchmark is because it was basically a vacuum test.

3 Likes

People always look into Alpine images from the wrong perspective…

I look into them from the security point of view, and once they have a lot less libraries, packages, watever, they have a much smaller attack surface then Debian, Ubuntu or Centos ones, but don’t take my word for it, just see the history of them and you will see that Alpine won’s by far in terms of security.

Not using Alpine due to performance or compatibility issues is understandable, and I would not argue to much against it :wink:

Probably not. I would guess the BEAM uses direct kernel calls to allocate memory pages and internally it creates its own alloc function.

1 Like

It does indeed. There are a few scenarios when it would fall-back to using malloc, but they should not occur during normal operations.

7 Likes