[evol262]

This falsehood needs to die.

It's true for non-trivial cases, and exceptionally false for some things. Like databases. A lot of the sysctl tuning for large database environments has to be done on the host, either directly, allowing unsafe sysctls and restarting kubelet, running with privileges, etc.

This is not "independent of the underlying infrastructure" or "the VM and my laptop have the same kernel tunables set". They don't. And it matters.

[JonathanBeuys]

Only when your application depends on optimizing your database to the max.

Most applications don't.

And even if the application I work on does - then only in production. Not on my laptop. So on my laptop I will simply chose a docker image that resembles production as closesly as possible. I will not use a VM.

[KaiserPro]

> Only when your application depends on optimizing your database to the max.

Only when you don't need to store data for any length of time. The point of containers is that they don't store state. You have to manage that.

And for some cases you can get away with it. But for most websites, keeping a single container up for many years isn't a great strategy. (Yes, I know there are ways around this. but they are not as simple as "docker run postgres")

[xorcist]

Trivial use cases are generally trivial.

[koolba]

The vast majority of use cases for databases are trivial. For every esoteric, optimized to the max, bleeding edge kernel parameter tuned environment, you have 10,000+ CRUD apps that do little more than primary key look ups on vanilla btree indexes.

[therealdrag0]

I’ve worked at a half dozen companies most people have never heard of and they all had database complexity and performance issues. The whole “only FAANG has scale” meme needs to die.

You’re probably right there’s a magnitude more tiny apps but who cares. A large number of us still are interested in and need to solve for non-trivial cases.

[Too]

Most database performance issues are bad choice of indices, bad data model, bad queries, not enough RAM, missing pooling, unrealistic expectations and lack of pre-computed caches.

None of these are solved by "optimize kernel-parameters to the max".

[therealdrag0]

I agree! I must have misread or misunderstood the context.

[koolba]

This is exactly what I was talking about.

[lrvick]

This sounds like a good argument for firecracker or some other micro hypervisor wrapper around your container to give you more control. You should never ever touch the host OS of a production system.