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
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
