docker容器资源限制与容器内的dotnet应用线程限制
作者:IT杂人
文章指出因docker-compose资源限制配置错误(如误将cpu设为0.5导致线程过多),引发redis超时问题,同时微服务中大key、热key等不合理操作加剧redis性能瓶颈,需优化代码和容器参数设置
docker容器资源限制
使用docker-compose管理容器
所以yml文件配置可以 增加
deploy: resources: limits: cpus: "8" memory: 4096M reservations: cpus: "0.5" memory: 500M
- limits=> cpus: “8” //cpu利用率最大限制:建议设置成实际cpu核数的一半以上,如果单核时,设置0.5即可
- limits=> memory: “4096M” // 内存分配最大限制:按实际应用分配
另:–pids-limit 限制容器最大可用线程数,用于不可控的线程造成整个服务器挂掉,Tune container pids limit (set -1 for unlimited),在docker-compose.yml文件中不同版本格式不一样。
https://forums.docker.com/t/how-to-set-docker-compose-pids-limit/127609 - 在2.0版本中,是一个大节点配置,与container_name同级 在portainer2.9.3也只支持如下配置 pids_limit: 10 - 在3.0以上版本且docker-compse版本要大于1.29以上才支持 deploy: resources: limits: pids: 10
dotnet程序线程限制
#应用编译目录下文件设置:xxx.runtimeconfig.json { "runtimeOptions": { "tfm": "net5.0", "framework": { "name": "Microsoft.AspNetCore.App", "version": "5.0.0" }, "configProperties": { "System.Threading.ThreadPool.MinThreads": 8 } } }
configProperties=>最小线程数:因为使用了容器,不便修改此文件 ,考虑到服务器一般是8核心上,默认写上8核。
对性能的影响
docker官方文档说明 :https://docs.docker.com/engine/reference/commandline/run/
1.通过容器启动时:由于对yml文件中的配置,limits理解错误,设置了0.5,以为是cpu利用率的50%,没发现是针对单核需要这样设置,导致dotnet后台程序线程数多了后,redis的一个使用场景经常报timeout;
2.本地调试时:不会报redis的timeout,也就是线程数可用,资源可用
原因
limits-cpu设置错误
代码质量还是有问题,导致大量线程产生
dotnet程序默认线程数设置问题
本地未发生线程不够的问题,是因为未被容器的限制参数影响
部分微服务在使用redis时,不合理的大key和热key及正则key,造成redis自身也有性能瓶颈,进而影响客户端的timeout
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。