[nine_k]

A container, being basically a chroot, consumes a rather small amount of resources, mostly as space in namespace and ipfilter tables.

If your containers use many of the same base layers (e.g. the same Node or Python image), the code pages will be shared, as they would be shared with plain OS processes.

Running several processes in a container is the norm. First, you run with --init anyway, so there is a `tini` parent process inside. Then, Node workers and Java threads are pretty common.

Running several pieces of unrelated software in a container is less common, that's true.

Containers are a way to isolate processes better, and to package dependencies. You could otherwise be doing that with tools like selinux and dpkg, and by setting LD_nnn env variables. Containers just make it much easier.

[topspin]

> Running several processes in a container is the norm.

I'm highly aware. The reason the word "process" is quoted in my highly down-voteable comment is the misuse of the term "process" by Docker et al. to mean "application." Google the "one process per container" mantra to see what I mean. Somehow the Docker crowd were oblivious to the 60+ year old concept of and terminology related to OS processes when they promulgated their guidance on how containers should be used.

I try not to indulge too many hang-ups in life, but that particular bit of damage is insufferable.

[Roark66]

I quite like containers to limit/reserve the ram/cpu use for certain processes. For example imagine a tiny service used by Few concurrent users that needs a SQL db, a app server, and a reverse proxy (For ssl/caching) in front. I'm quite happy to put stuff like this on a tiny VM with 1vCPU and 1GB RAM. Mnthly cost ~$5 for compute. I typically reserve/limit 64MB/128MB for nginx, 384mb/512mb for mariadb, and 256mb/384mb for the app server (PHP etc).Also I have cpu share reservation/limits too. Of course it requires tuning the configs, but it runs great(verified with load testing and actual use). If you put the same software on the same host with no reservations/limits there are situations where latencies grow a lot or the whole thing freezes because one component consumes too much resources. If anyone knows any non-container lie overhead ways to partition a single vcpu and a gig of ram like this I'd be interested to hear about it.

[predakanga]

Systemd has a mechanism[0] for configuring those limits.

I believe you can limit a unit to 1 vCPU and 256MB of memory by using something like the following:

[Service]

CPUQuota=100% # 100% of a core

MemoryLimit=256MB

Red Hat has some documentation[1] as well if the systemd stuff is too oblique.

[0]: https://www.freedesktop.org/software/systemd/man/systemd.res...

[1]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

[topspin]

> If anyone knows any non-container lie overhead ways to partition a single vcpu and a gig of ram like this I'd be interested to hear about it.

You can use cgroups[1] to do this, because that's what your container runtime is doing. People don't know this because they think these features have something to do with their container runtime and that's what they use, so no one discovers it.

Plus, the user facing tools for cgroups are slightly hideous. And that won't ever get fixed for the reasons previously stated. Sigh.

Also, I'm sure a lot of people would appreciate learning about your tuning techniques, containers or otherwise. Consider writing it up.

[1] circa 2007...

[ilyt]

You can set up same limits via systemd units as they are using same interfaces as containers. They can be set up via systemd overrides to existing services so they are pretty straightforward

Just be beware of same problems like swap trap (limiting only memory and not memory and swap will just make apps hitting the memory limit start to swap like hell)