docker容器资源限制与容器内的dotnet应用线程限制
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
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
相关文章
解决docker报错Encountered errors while bringing&n
这篇文章主要介绍了解决docker报错Encountered errors while bringing up the project实测有效!具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2024-03-03
项目访问使用docker bridge网络模式(端口映射)配置过程
这篇文章主要介绍了项目访问使用docker bridge网络模式(端口映射)配置过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2025-03-03
Windows11安装Docker Desktop教程的图文教程
本文主要介绍一下Windows11安装Docker Desktop教程的图文教程,文中通过图文介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2024-10-10


最新评论