版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/snipercai/article/details/80409146
问题现象：
在批量重启容器时，期间开始出现租户marathon的UI卡顿严重的情况，在UI上进行操作，基本均反馈报错信息如下：
Futures timed out after [10000 milliseconds]
现状：
目前中间容器化平台情况如下：
管理节点数：5台（
24C/64G/600*2/千兆）（
Intel(R) Xeon(R) CPU E7- 4807 @ 1.87GHz
）
slave-public节点数：2台（
24C/64G/600*2/千兆）（
Intel(R) Xeon(R) CPU E7- 4807 @ 1.87GHz
）
slave节点数：106台
租户A：资源cpu数
1830
运行174容器实例
租户B：资源cpu数
2230
运行413容器实例
问题分析1：租户marathon的jvm内存不足
在DC/OS的管理marathon上查看租户B的marathon容器，默认分配的资源为2C2G，通过docker stats查看该容器的内存使用率100%，内存短缺，同时日志中发现gc的报错，判断jvm的内存太小造成。
解决办法：
增加租户B的marathon容器的内存至20G，同时设置JAVA_OPT的jvm参数为20G，通过docker stats查看其内存使用率在60%~70%，实际使用约14G左右，无gc报错，jvm内存不足问题已经排除
问题效果：UI卡顿问题仍未解决。
问题分析2：CPU资源不足，CPU使用量在DC/OS上默认被quota限制
在DC/OS上，CPU资源默认采用quota进行限制，
MESOS_CGROUPS_ENABLE_CFS默认为True，通过docker stats、nmon、top等方式监控发现租户B的marathon的java进程长期维持在190%左右（默认设置为2C），怀疑cpu资源不足造成调度延迟
解决办法：
1、增加租户B的marathon容器的CPU至16C，通过docker stats查看其cpu使用率峰值可达1500%以上，但持续时间较短，预测在忙时cpu利用率应在16C以上。
2、修改租户marathon所用的slave-public节点的cpu限制参数，将
MESOS_CGROUPS_ENABLE_CFS=false，同时重启mesos-slave
服务systemctl restart dcos-mesos-slave-public
问题效果：UI卡顿问题解决
总结：
1、DC/OS默认创建的租户marathon资源配比较小（2C/2G），在管理超过100个容器实例以上时，极可能出现marathon资源不足的情况，所以需要仔细评估容器实例规模和租户marathon的资源需求，不明确时，可以考虑关闭CPU的quota限制，采用CPU的shares方式。
2、租户marathon所运行在的slave-public节点，其上的mesos-slave服务名称与普通资源节点并不一致，名为dcos-mesos-slave-public，在修改mesos-slave资源参数后，需要重启mesos-slave服务生效。