[feature] Automatically set GOMAXPROCS to match Linux container CPU quota in runtime

[gaocegege]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

What happened:

It will be huge overhead for CPU bound tasks if GOMAXPROCS does not match CPU hard limit in K8s. Maybe we can use https://github.com/uber-go/automaxprocs to auto configure it.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

[iawia002]

我拿 storage snapshot 的 CRUD 接口做了测试，docker 分配 2 核 CPU，benchmark 分别测试了 GOMAXPROCS 为 1，2，4 的情况，得到的结果如下：

GOFLAGS=-mod=vendor go test -bench=. -cpu=1,2,4 -run=none github.com/caicloud/storage-admin/pkg/admin/handler

name              time/op
ListSnapshot      55.9µs ± 0%
ListSnapshot-2    28.8µs ± 0%
ListSnapshot-4    27.0µs ± 0%
GetSnapshot       20.0µs ± 0%
GetSnapshot-2     13.5µs ± 0%
GetSnapshot-4     18.0µs ± 0%
CreateSnapshot    42.2µs ± 0%
CreateSnapshot-2  24.4µs ± 0%
CreateSnapshot-4  26.4µs ± 0%
UpdateSnapshot    52.5µs ± 0%
UpdateSnapshot-2  32.4µs ± 0%
UpdateSnapshot-4  46.9µs ± 0%
DeleteSnapshot    4.76µs ± 0%
DeleteSnapshot-2  3.15µs ± 0%
DeleteSnapshot-4  3.33µs ± 0%

2 和 4 的结果相差不大，但是都明显优于 1

/cc @supereagle

[gaocegege]

是在本机上测的么，建议上服务器试试看

跑在核数多的服务器上这个问题可能会更严重，因为 GOMAXPROCS 会更大

[iawia002]

我看我们的服务器都是 4 核的，和我本机一样，在服务器上跑很麻烦，我还要拷代码上去

[aiderzcx]

确实影响不大， 2和4优于1，docker开了2个CPU，设置为1的时候浪费了1个CPU
从原理上来分析，对性能对影响就是线程的调度切换，在正式的服务器上，如果一个 node 上有 16 个 Pod，每个 Pod 1 个服务设置 CPU 数量为 4，那么 64 * 1 * 4 = 64个线程，这个对性能没什么影响

[gaocegege]

服务器是 4 核的？哦那没事了。。。

[gaocegege]

在正式的服务器上，如果一个 node 上有 16 个 Pod，每个 Pod 1 个服务设置 CPU 数量为 4，那么 64 * 1 * 4 = 64个线程，这个对性能没什么影响

更容易出现的情况是这样的：比如一个 Node 有 4 个 CPU，其中任意一个 Pod 设置 cpu hard limit 为 1，GOMAXPROCS 会被设置成 4，Go Runtime 创建 4 个 P，但其实只有一个能用。4 个 M 就会争抢 P，在 CPU Bound 的任务里影响挺大的（亲测算质数任务 MAXPROCS=4 比 MAXPROCS=1（理论最优设置）慢一倍）