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