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，也就是线程数可用，资源可用

• 如此描述：https://stackexchange.github.io/StackExchange.Redis/Timeouts

原因：

limits-cpu设置错误

代码质量还是有问题，导致大量线程产生

dotnet程序默认线程数设置问题

本地未发生线程不够的问题，是因为未被容器的限制参数影响

部分微服务在使用redis时，不合理的大key和热key及正则key，造成redis自身也有性能瓶颈，进而影响客户端的timeout