DC/OS上租户marathon的UI卡顿的问题分析

问题现象：

在批量重启容器时，期间开始出现租户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服务生效。