1.-XX:ParallelGCThreads=cpus
2.-XX:ConcGCThreads=cpus/2
CMS是常见的收集器，它设置并行度的时候是取机器的核数来计算的。如果给容器分配2个CPU，JVM仍然按照宿主机的核数初始化这些线程数量，GC的回收效率会降低。想规避这个问题有两点，第一点是挂载假的Proc文件系统，比如Lxcfs。第二种是使用类似Hyper的基于Hypervisor的容器。
Mesos容器化要求关注两类参数：配置参数和run参数。
3.需要关注的配置参数
1.MESOS_systemd_enable_support
2.MESOS_docker_mesos_image
3.MESOS_docker_socket
4.GLOG_max_log_size
5.GLOG_stop_logging_if_full_disk
Mesos是配置参数最多的。在物理机上，Mesos默认使用系统的Systemd管理任务，如果把Mesos通过Docker run的方式启动起来，用户就要关systemd_Enable_support，防止Mesos Slave拉取容器运行时数据造成混乱。
第二个是Docker_Mesos_Image，这个配置告诉Mesos Slave，当前是运行在容器内的。在物理机环境下，Mesos Slave进程宕掉重启，、就会根据executor进程/容器的名字做recovery动作。但是在容器内，宕机后executor全部回收了，重启容器，Slave认为是一个新环境，跳过覆盖动作并自动下发任务，所以任务有可能会发重。
Docker_Socket会告诉Mesos，Docker指定的远端地址或本地文件，是默认挂到Mesos容器里的。用户如果直接执行文件，会导致文件错误，消息调取失败。这个时候推荐一个简单的办法：把当前物理机的目录挂到容器中并单独命名，相当于在容器内直接访问整个物理机的路径，再重新指定它的地址，这样每次一有变动Mesos就能够发现，做自己的指令。
后面两个是Mesos Logging配置，调整生成logging文件的一些行为。
需要关注的run参数
1.–pid=host
2.–privileged
3.–net=host (optional)
4.root user
启动Slave容器的时候最好不加Pid Namespace，因为容器内Pid=1的进程一般都是你的应用程序，易导致子进程都无法回收，或者采用tini一类的进程启动应用达到相同的目的。–privileged和root user主要是针对Mesos的持久化卷功能，否则无法mount到容器内，–net=host是出于网络效率的考虑，毕竟源生的bridge模式效率比较低。
图4：去哪儿数据平台部署流程图
基于Marathon的Streaming调度
拿Spark>
图5：替代Spark Mesos Dispatcher
不过还是有一些问题存在：
Checkpoint & Block
1.动态预留 & 持久化卷
2.setJars
3.清理无效的卷
关于Checkpoint&Block，通过动态预留的功能可以把这个任务直接“钉死”在这台机器上，如果它挂的话可以直接在原机器上重启，并挂载volume继续工作。如果不用它预留的话，可能调度到其他机器上，找不到数据Block，造成数据的丢失或者重复处理。
持久化卷是Mesos提供的功能，需要考虑它的数据永存，Mesos提供了一种方案：把本地磁盘升级成一个目录，把这个转移到Docker里。每次写数据到本地时，能直接通过持久化卷来维护，免去手工维护的成本。但它目前有一个问题，如果任务已被回收，它持久化卷的数据是不会自己删掉的，需要写一个脚本定时轮巡并对应删掉。
临时文件
1.java.io.tmpdir=/mnt/mesos/sandbox
2.spark.local.dir=/mnt/mesos/sandbox
如果使用持久化卷，需要修改这两个配置，把这一些临时文件写进去，比如shuffle文件等。如果配置持久化卷的话，用户也可以写持久化卷的路径。
Coarse-Grained
Spark有两种资源调度模式：细粒度和粗粒度。目前已经不太推荐细粒度了，考虑到细粒度会尽可能的把所有资源占满，容易导致Mesos资源被耗尽，所以这个时候更倾向选择粗粒度模式。
