4 ms·

People using Kubernetes don't tune or change those settings, it's up to the app to behave properly.

• dilyevsky 3y ago
  False. Kubernetes cpu request sets the shares, cpu limit sets the cfs quota
  • Thaxll 3y ago
    You said to change docker flags. Anyway your post is irrelevant, the goal is to let know the runtime about how many posix threads should it use. If you set request / limit to 1 core but you run on 64 cores node , then you runtime will see that which will bring performance down.
    • dilyevsky 3y ago
      Original article is about docker. That’s the point of my comment - dont set cpu limit
      • riv991 3y ago
        I intended it to be applicable to all containerised environments. Docker is just easiest on my local machine. I still believe it's best to set these variables regardless of cpu limits and/or cpu shares
        • dilyevsky 3y ago
          All you did is kneecapped your app to have lower performance so it fits under your arbitrary limit. Hardly what most people describe as “best” - only useful in small percentage of usecases (like reselling compute)
          • riv991 3y ago
            I've seen significant performance gains from this in production. Other people have encountered it too hence libraries like Automaxprocs existing and issues being open with Go for it.
            • dilyevsky 3y ago
              Gains by what metric? Are you sure you didn't trade in better latency for worse overall throughput? Also, sure you didn't hit one of many CFS overaccounting bugs which we've seen a few? Have you compared performance without the limit at all?
              • riv991 3y ago
                Previously we had no limit. We observed gains in both latency and throughput by implementing Automaxprocs and decided to roll it out widely. This aligns with what others have reported on the Go runtime issue open for this. "When go.uber.org/automaxprocs rolled out at Uber, the effect on containerized Go services was universally positive. At least at the time, CFS imposed such heavy penalties on Go binaries exceeding their CPU allotment that properly tuning GOMAXPROCS was a significant latency and throughput improvement." https://github.com/golang/go/issues/33803#issuecomment-1430865244 https://github.com/golang/go/issues/33803#issuecomment-14308...