核心原则：混部部署场景下的资源总量控制

在翼 MR 集群中，多个大数据组件（如 HDFS、HBase、YARN 等）可能会部署在同一台 ECS 实例上（即混部场景）。为避免资源竞争导致系统不稳定，请遵循以下基本原则：

· 总内存控制 ：所有组件 JVM 堆内存之和 ≤ 实例总内存 ×80%。预留至少 20% 的内存给操作系统、Page Cache、堆外内存及突发流量。

· CPU 资源控制 ：各组件线程池参数（如 Kafka 的num.io.threads等）配置之和不宜超过实例 vCPU 核数的 2~3 倍，避免过度竞争。

· YARN 资源隔离 ：若该节点同时运行 YARN NodeManager，其yarn.nodemanager.resource.memory-mb配置不应超过实例总内存的 60%，以保证其他常驻组件的内存安全。

说明
以下各组件配置建议均基于独立部署场景给出。若您采用混部部署，请务必参照上述核心原则，适当调低各组件内存及线程参数。

Doris

Doris 所在节点配置升级后，需根据实际内存和磁盘情况调整 FE 和 BE 配置。

FE（Frontend）配置建议

• JVM 堆内存 ：修改fe.conf中的 JVM 参数。推荐使用 G1 垃圾回收器，堆内存初始与最大值保持一致。生产环境下建议按业务调整， 最大不超过 100 GB 。示例：JAVA_OPTS="-Xms16g -Xmx16g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

• 日志路径 ：避免将日志放在系统目录。平台默认（翼 MR 版本 ≥ 2.21）会将日志放到数据目录下；低版本需手动修改fe.conf中的LOG_DIR、sys_log_dir、audit_log_dir为目标路径。请确保日志盘有至少 50 GB 空间。

• 日志滚动数量 ：sys_log_roll_num（默认 10 个，每个 1 GB）、audit_log_roll_num（默认 30 个，每个 1 GB），可根据需要调整。

BE（Backend）配置建议

• 存储路径 ：磁盘扩容后，需在be.conf的storage_root_path中添加新磁盘路径，并滚动重启 BE 节点。

• 数据均衡 ：新增磁盘后，新建表会自动均衡到新磁盘；存量表如需快速均衡，可采用以下方式之一：

  • 方式一： CREATE TABLE LIKE创建新表，再用INSERT INTO SELECT同步数据。
  • 方式二： 使用 Decommission 命令（先设置ADMIN SET FRONTEND CONFIG("drop_backend_after_decommission" = "false");，再对 BE 执行 decommission，待数据迁移完成后取消）。
  • 方式三： 通过 HTTP API 手动迁移分片。

• 内存配置调整（当实例内存扩容时需关注）：

  • 内存上限mem_limit： be.conf 中默认值为物理内存的 90%。增加内存后通常保持默认即可，如需调整可按实际情况修改。
  • 内存水位线参数：
    • soft_mem_limit_frac：默认为 mem_limit * 0.9（即系统内存的 81%），超过时触发 Minor GC，一般无需调整。
    • max_sys_mem_available_low_water_mark_bytes：系统可用内存低水位，默认 1.6 GB。在大内存机器上可适当调高（如 4~8 GB），为 Full GC 预留更多缓冲。
  • Workload Group 内存： Workload Group 的 memory_limit 百分比是基于 BE 进程可用内存计算的。内存扩容后，若百分比不变，其绝对内存上限会自动增大。建议结合实际业务重新评估各 Workload Group 的内存分配比例。

混部场景特殊说明

• BE 节点占用内存较大，建议 优先独立部署 。必须混部时，BE 堆内存建议不超过实例总内存的 40%，FE 堆内存不超过实例总内存的 20%。例如：64 GB 实例上，BE 分配 ≤ 25 GB，FE 分配 ≤ 12 GB。

Elasticsearch

Elasticsearch节点配置升级后，内存配置需遵循“50% 原则”且绝对上限不超过 31 GB。

内存配置建议

• 服务器总内存 32 GB → 配置 16 GB

• 服务器总内存 64 GB → 配置 31 GB

• 服务器总内存 128 GB → 配置 31 GB（多余内存预留给操作系统 Page Cache 以加速 Lucene 检索）

修改方法

• 修改config/jvm.options.d/目录下文件中的-Xms、-Xmx参数，例如：-Xms31g、-Xmx31g
• 采用滚动重启集群的方式使配置生效。

混部场景特殊说明

• 强烈建议 ES节点独立部署 。若必须混部，JVM 堆内存调整为实例总内存的 30%~40%（但不超过 31 GB），并进一步增大预留的 Page Cache 内存（例如总内存 64 GB 时，堆内存配置 20 GB 而非 31 GB）。

HBase

HBase 所在节点配置升级后，需调整 RegionServer 和 Master 的 JVM 堆内存及请求处理线程数。

配置建议

组件	配置文件	配置项	推荐值	说明
RegionServer	hbase-env.sh	HBASE_REGIONSERVER_OPTS	-Xms32g -Xmx32g（具体根据内存配额）	一般配置内存配额的一半或更多；超过64 GB 可考虑使用 G1GC
Master	hbase-env.sh	HBASE_MASTER_OPTS	-Xms4g -Xmx4g	集群规模不大（region < 10000）时 4~8 GB 足够
RegionServer	hbase-site.xml	hbase.regionserver.handler.count	与CPU 核数相同	控制处理客户端请求的线程数

混部场景特殊说明

• HBase RegionServer 是内存消耗大户，强烈建议独立部署 。必须混部时，堆内存不超过实例总内存的 50%，且需使用 G1GC（添加-XX:+UseG1GC）。

HDFS

HDFS 所在节点配置升级后，需调整 NameNode 和 DataNode 的堆内存。

NameNode 堆内存

• 修改hadoop-env.sh中的NAMENODE_HEAPSIZE项（单位 MB），例如：NAMENODE_HEAPSIZE=20480 # 20 GB
• 堆内存计算公式（经验值）：**每 100 万对象（文件+块）建议分配 0.5 ** GB 堆内存 。例如：HDFS集群有100万文件数，100万数据块堆内存，(推荐值) = (1 +  1)  × 0.5GB。

DataNode 堆内存

• 修改hadoop-env.sh中的DATANODE_HEAPSIZE项，例如：DATANODE_HEAPSIZE=10240 # 10 GB
• 推荐每 100 万副本（replica）分配 2 GB 堆内存。

混部场景特殊说明

• NameNode 堆内存不超过实例总内存的 40%，DataNode 堆内存不超过实例总内存的 30%。大规模集群（文件数 > 500 万）建议 NameNode 独立部署。

Hive

Hive 所在节点配置升级后，需调整 Metastore 和 HiveServer2 的 JVM 堆内存。

配置建议

• Metastore ：修改hive-env.sh中"​SERVICE" = "metastore"部分的HADOOP_CLIENT_OPTS，例如：export HADOOP_CLIENT_OPTS="HADOOP_CLIENT_OPTS -Xmx2048m -Xms2048m -Xss20m"
• HiveServer2 ：修改hive-env.sh中"​SERVICE" = "hiveserver2"部分的HADOOP_CLIENT_OPTS，例如：export HADOOP_CLIENT_OPTS="HADOOP_CLIENT_OPTS -Xmx4096m -Xms4096m"

混部场景特殊说明

• Metastore 和 HiveServer2 相对轻量。混部时，Metastore 保持 2 GB，HiveServer2 可根据实例总内存调整，建议不超过实例总内存的 15%。

Kafka

Kafka 所在节点配置升级后，建议配置如下：

• JVM 堆内存 ：修改kafka-env.sh，设置export KAFKA_HEAP_OPTS="-Xmx20G -Xms20G -Xmn4G"。注意堆内存建议不超过物理内存的 50%，且不超过 32 GB。
• server.properties建议修改以下线程参数（基于 CPU 核数）：
  • num.io.threads：写磁盘线程数，建议为 CPU 核数的 50%。
  • num.replica.fetchers：副本拉取线程数，建议为 CPU 核数 50% 的 1/3。
  • num.network.threads：数据传输线程数，建议为 CPU 核数 50% 的 2/3。
  • replica.fetch.max.bytes、socket.send.buffer.bytes、socket.receive.buffer.bytes、socket.request.max.bytes：内存增加时可适当加大。

混部场景特殊说明

• Kafka Broker 建议优先独立部署。必须混部时，堆内存不超过实例总内存的 30%，且各线程参数总和应控制在 vCPU 核数的 2~3 倍内。

Kerberos

建议保持默认值，无需修改配置。

Kibana

Kibana 是一个基于 NodeJS 的单页 web 应用，一般情况下对内存 CPU 占用很少，无须修改内存、CPU 等配置。

Kyuubi

Kyuubi 一般情况下，对内存 CPU 占用很少，无须修改内存、CPU 等配置。若需调整，可在kyuubi-env.sh中修改KYUUBI_JAVA_OPTS的-Xmx参数，建议 4 GB。

OpenLDAP

建议保持默认值，无需修改配置。

Ranger

Ranger 所在节点配置升级后，修改建议如下：

• ranger-admin ：修改{installdir}/ews/ranger-admin-services.sh中变量ranger_admin_max_heap_size的值，以及JAVA_OPTS中的-Xmx、-Xmn等。一般设置 1~8 GB：1K 策略建议 1 GB，1 万策略建议 8 GB。
• ranger-usersync ：修改/{installdir}/ranger-usersync-services.sh中变量ranger_usersync_max_heap_size及JAVA_OPTS中的-Xmx、-Xmn。同样一般设置 1~8 GB。

Spark

Spark 所在节点配置升级后，修改建议如下：

• spark.history.kerberos.principal和spark.history.kerberos.keytab：Spark 读写 eventLog 的租户，如有特殊需求自行更改。

• spark.yarn.historyServer.address：History Server 的地址，如有特殊需求自行更改。

• spark.dynamicAllocation.enabled和spark.dynamicAllocation.maxExecutors：分别控制动态分配和动态开启下能使用的最大资源，如有特殊需求自行更改。

• spark.executor.cores和spark.executor.memory：确保每一个 core 分配到 2~4 GB 内存（标准 4 GB），设置过小容易 OOM。

混部场景特殊说明

• Spark 任务执行时会动态申请 YARN 容器资源。混部场景下，需确保yarn.nodemanager.resource.memory-mb配置的可用内存不超过实例总内存的 60%，以预留内存给其他常驻组件。

Trino

Trino 的服务包括 coordinator 和 worker。Trino 所在节点配置升级后，可以根据jvm.config参数配置进行，通过调整服务的内存大小调整服务的性能，例如-Xmx128g -Xms128g，然后重启服务。

混部场景特殊说明

• Trino worker 对内存要求较高，建议独立部署。必须混部时，堆内存不超过实例总内存的 40%。

YARN

YARN 所在节点配置升级后，可以根据yarn-env.sh参数配置进行，通过调整服务的内存大小来调整服务的性能，如-Xmx20g -Xms20g -Xmn4g，然后重启服务。

• NodeManager 资源 ：修改yarn-site.xml中的以下配置：
  • yarn.nodemanager.resource.memory-mb：可用于分配给 container 的内存大小（单位 MB）。
  • yarn.nodemanager.resource.cpu-vcores：可用于分配给 container 的 vcore 数。
• 动态生效 ：可执行动态配置命令，无需重启 NodeManager：yarn rmadmin -updateNodeResource {nodemanager_hostname}:45454 <内存MB> <vcore数>

混部场景特殊说明

• 混部时，yarn.nodemanager.resource.memory-mb建议配置不超过实例总内存的 50%~60%。例如 64 GB 实例，可配置 32 GB 给 YARN 容器，其余留给 HBase、HDFS DataNode 等组件。

ZooKeeper

ZooKeeper 所在节点配置升级后，可通过配置java.env文件，在其中添加：

export ZK_SERVER_HEAP=2048 # 单位 MB

一般堆内存建议 2~4 GB，过大反而会增加 GC 暂停时间。

混部场景特殊说明

• ZooKeeper 对内存要求不高，混部时保持 2 GB 即可。

以上为本次优化后的配置修改建议。请在实际配置中根据业务负载和监控数据进一步微调。