背景
物理机时代,业务根据/proc/sys/kernel/threads-max设置线程池大小。容器(特指docker)该值仍然获取的是物理机上的信息,而容器规格一般比物理机小,再根据这个值获取信息设置容器内线程数就不准确了。物理机上这个值受哪些资源影响,因此有了这篇文章。
梳理
内核版本4.18 线程数限制为[20,0x3fffffff]

物理机时代,业务根据/proc/sys/kernel/threads-max设置线程池大小。容器(特指docker)该值仍然获取的是物理机上的信息,而容器规格一般比物理机小,再根据这个值获取信息设置容器内线程数就不准确了。物理机上这个值受哪些资源影响,因此有了这篇文章。
内核版本4.18 线程数限制为[20,0x3fffffff]

线上A模块访问B模块,A模块部署在物理机,B模块部署在容器上。早晚高峰A访问B会出现超时报警。
业务方找到我们排查,我首先申请了监控中提示超时的两台机器权限,看一下超时规律
登录10.167.8.25容器所在的宿主机常规排查
dmesg显示如下,联系值班同学和系统部同学硬件报修。
EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
漂移容器10.167.8.252后,10.167.41.18 在两台物理机上小时级别日志中会出现近10次
git: https://github.com/moby/moby.git
branch: v18.06.3-ce
ide: goland2020.2
配置goland的build tag 
一起见证docker 代码中套路
exec.Command=> cmd.Start() => cmd.Wait()
docker
|
V
dockerd -> containerd ---> shim -> runc -> runc init -> process1
|--> shim -> runc -> runc init -> process2
+--> shim -> runc -> runc init -> process3