[HN Gopher] Predictive CPU isolation of containers at Netflix (2...
___________________________________________________________________
Predictive CPU isolation of containers at Netflix (2019)
Author : Cwizard
Score : 63 points
Date : 2024-04-08 22:35 UTC (2 days ago)
(HTM) web link (netflixtechblog.com)
(TXT) w3m dump (netflixtechblog.com)
| shadowpho wrote:
| This is amazing, they use ML to predict utilization on the fly
| high_na_euv wrote:
| It seems like we are more and more getting away from OSes
| managing our resources
|
| Runtimes/vms implement memory management, varius threading
| techniques and things like we see here
|
| Maybe in the future we will entirely skip OS's overhead and run
| apps directly on HW and they will manager themselves more
| efficiently (their runtimes/vms like jvm clr)
| exe34 wrote:
| Could build them on top of unikernels.
| gpderetta wrote:
| wash, rinse, repeat.
| cj wrote:
| Is it node that still limits all processes to 2gb or something
| by default? (I think their rationale was "it's a v8 flag so we
| don't touch it")
| actionfromafar wrote:
| Upside is that it makes sure your stuff can be deployed on
| 32-bit.
| lexicality wrote:
| Does that come in handy often?
| piyh wrote:
| TIL
|
| https://nodejs.org/api/cli.html#--max-old-space-sizesize-
| in-...
| yencabulator wrote:
| More like "kernel programming is hard, let's put fancier logic
| and RPC in userspace". Which sounds perfectly sane.
| mochomocha wrote:
| (I'm the author of the blog post)
|
| Beyond "kernel programming is hard", there are a few other
| reasons why it made sense for us:
|
| - observability & maintenance: much easier to implement and
| ship this type of changes in userspace than rolling out a
| kernel fork. We also built custom AB infra to be able to
| evaluate these optimizations.
|
| - the kernel is really good at making reasonable decisions at
| high-frequency based on a limited amount of data and
| heuristics. But these decisions are far from optimal in all
| scenarios. In contrast in user-space we can make better
| decisions based on more data (or ML predictions), but do so
| less frequently.
| Sparkyte wrote:
| Kind of an old article. It is pretty straight forward thing to
| do. If you spend enough time accurately load testing your
| environments you can dial in the container resources and shave
| thousands of dollars. Lots of places are too scared of under
| allocating. Limit and request exist for a reason. Limit is for
| surge and request is what is always guaranteed. It is okay to
| exceed your request as long as you balance add a scaling policy
| to balance out the surge. And be cautious with request and limit
| on memory not all applications benefit from this.
| burutthrow1234 wrote:
| They're automatically predicting the limit _and_ figuring out
| binpacking into hyperthreaded CPUs and NUMA cores. K8s just
| pushes your supplied values down to the kernel, which is
| exactly what they're saying is inefficient.
| Sparkyte wrote:
| It is indeed inefficient so this is more like a process lasso
| approach to the resource management?
| yencabulator wrote:
| See also ghOSt by Google (2021):
|
| https://storage.googleapis.com/pub-tools-public-publication-...
|
| https://github.com/google/ghost-userspace
|
| https://github.com/google/ghost-kernel
| dang wrote:
| Related:
|
| _Predictive CPU isolation of containers at Netflix using a MIP
| solver_ - https://news.ycombinator.com/item?id=21116565 - Sept
| 2019 (21 comments)
|
| _Predictive CPU Isolation of Containers at Netflix_ -
| https://news.ycombinator.com/item?id=20096699 - June 2019 (1
| comment)
___________________________________________________________________
(page generated 2024-04-10 23:01 UTC)