巨人肩膀
改版通知

巨人肩膀网站已全新改版。若您仍依赖旧站功能或数据，欢迎联系我们，我们会协助处理。联系我们

← 返回专栏列表

CDH大数据环境参数优化指南

ckckck2025年1月10日27 浏览

1 配置原则

如何发挥集群最佳性能

原则1：CPU核数分配原则

  • 数据节点：建议预留2～4个核给OS和其他进程（数据库，HBase等）外，其他的核分配给YARN。
  • 控制节点：由于运行的进程较多，建议预留6～8个核。

原则2：内存分配

  • 除了分配给OS、其他服务的内存外，剩余的资源应尽量分配给YARN。

原则3：虚拟CPU个数分配

  • 节点上YARN可使用的虚拟CPU个数建议配置为逻辑核数的1.5～2倍之间。如果上层计算应用对CPU的计算能力要求不高，可以配置为2倍的逻辑CPU。

原则4：提高磁盘IO吞吐率

  • 尽可能挂载较多的盘，以提高磁盘IO吞吐率。

影响性能的因素

因素1：文件服务器磁盘I/O

  • 一般磁盘顺序读写的速度为百兆级别，如第二代SATA盘顺序读的理论速度为300Mbps，只从一个盘里读，若想达到1Gbps每秒的导入速度是不可能的。并且若从一个磁盘读，单纯依靠增加map数来提高导入速率也不一定可以。因为随着map数变多，对于一个磁盘里的文件读，相当由顺序读变成了随机读，map数越多，磁盘读取文件的随机性越强，读取性能反而越差。如随机读最差可变成800Kbps。因此需要想办法增大文件服务器的磁盘IO读效率，可以使用专业的文件服务器，如NAS系统，或者使用更简单的方法，把多个磁盘进行Raid0或者Raid5。

因素2：文件服务器网络带宽

  • 单个文件服务器的网络带宽越大越好，建议在10000Mb/s以上。

因素3：集群节点硬件配置

  • 集群节点硬件配置越高，如CPU核数和内存都很多，可以增大同时运行的map或reduce个数，如果单个节点硬件配置难以提升，可以增加集群节点数。

因素4：SFTP参数配置

  • 不使用压缩、加密算法优先选择aes128-cbc，完整性校验算法优先选择umac-64@openssh.com。

因素5：集群参数配置

因素6：Linux文件预读值

  • 设置磁盘文件预读值大小为16384，使用linux命令：
    bash 复制代码 
    echo 16384 > /sys/block/sda/queue/read_ahead_kb

2 Manager

2.1 提升Manager配置服务参数的效率

操作场景

在安装集群或者扩容节点以后，集群中可能添加了较多数量的节点。此时如果系统管理员在CDH Manager上修改服务参数、保存新配置并重启服务时，Manager的Controller进程可能占用大量内存，增加了CPU工作负荷，用户需要等待一段时间才能完成参数修改。系统管理员可以根据实际业务使用情况，手动增加Controller的JVM启动参数中内存参数，提升配置服务参数的效率。

对系统的影响

该操作需要在主管理节点重新启动Controller，重启期间会造成CDH Manager暂时中断。备管理节点Controller无需重启。

前提条件

已确认主备管理节点IP。

操作步骤

  1. 使用PuTTY，以omm用户登录主管理节点。
  2. 执行以下命令，切换目录。
    bash 复制代码 
    cd ${BIGDATA_HOME}/om-server/om/sbin
  3. 执行以下命令修改Controller启动参数文件“controller.sh”，并保存退出。
    bash 复制代码 
    vi controller.sh
    修改配置项“JAVA_HEAP_MAX”的参数值。例如，集群中包含了400个以上的节点，建议修改如下，表示Controller最大可使用8GB内存：
    bash 复制代码 
    JAVA_HEAP_MAX=-Xmx8192m
  4. 执行以下命令，重新启动Controller。
    bash 复制代码 
    sh ${BIGDATA_HOME}/om-server/om/sbin/restart-controller.sh
    提示以下信息表示命令执行成功：
    bash 复制代码 
    End into start-controller.sh
    执行sh ${BIGDATA_HOME}/om-server/om/sbin/status-oms.sh，查看Controller的“ResHAStatus”是否为“Normal”，并可以重新登录CDH Manager表示重启成功。
  5. 使用PuTTY，以omm用户登录备管理节点，并重复步骤2～步骤3。

2.2 根据集群节点数优化Manager配置

操作场景

CDH集群规模不同时，Manager相关参数差异较大。在集群容量调整前或者安装集群时，用户可以手动指定Manager集群节点数，系统将自动调整相关进程参数。

说明

在安装集群时，可以通过Manager安装配置文件中的“cluster_nodes_scale”参数指定集群节点数。

操作步骤

  1. 使用PuTTY，以omm用户登录主管理节点。
  2. 执行以下命令，切换目录。
    bash 复制代码 
    cd ${BIGDATA_HOME}/om-server/om/sbin
  3. 执行以下命令查看当前集群Manager相关配置。
    bash 复制代码 
    sh oms_config_info.sh -q
  4. 执行以下命令指定当前集群的节点数。
    命令格式：
    bash 复制代码 
    sh oms_config_info.sh -s 节点数
    例如：
    bash 复制代码 
    sh oms_config_info.sh -s 10
    根据界面提示，输入“y”：
    bash 复制代码 
    The following configurations will be modified:
Module Parameter Current Target
Controller controller.Xmx 4096m => 8192m
Controller controller.Xms 1024m => 2048m
...
Do you really want to do this operation? (y/n):
    界面提示以下信息表示配置更新成功：
    bash 复制代码 
    ...
Operation has been completed. Now restarting OMS server. [done]
Restarted oms server successfully.
    说明：
    • 配置更新过程中，OMS会自动重启。
    • 相近数量的节点规模对应的Manager相关配置是通用的，例如100节点变为101节点，并没有新的配置项需要刷新。

3 优化CM

这些服务主要是提供监控功能，目前的调整主要集中在内存放，以便有足够的资源完成集群管理。

CM优化

4 HBase优化

1 提升BulkLoad效率

操作场景

批量加载功能采用了MapReduce jobs直接生成符合HBase内部数据格式的文件，然后把生成的StoreFiles文件加载到正在运行的集群。使用批量加载相比直接使用HBase的API会节约更多的CPU和网络资源。ImportTSV是一个HBase的表数据加载工具。

前提条件

在执行批量加载时需要通过“Dimporttsv.bulk.output”参数指定文件的输出路径。

操作步骤

参数入口：执行批量加载任务时，在BulkLoad命令行中加入如下参数。

BulkLoad参数

2 提升连续put场景性能

操作场景

对大批量、连续put的场景，配置下面的两个参数为“false”时能大量提升性能。

  • hbase.regionserver.wal.durable.sync
  • hbase.regionserver.hfile.durable.sync

当提升性能时，缺点是对于DataNode（默认是3个）同时故障时，存在小概率数据丢失的现象。对数据可靠性要求高的场景请慎重配置。

操作步骤

连续put场景性能优化

3 Put和Scan性能综合调优

操作场景

HBase有很多与读写性能相关的配置参数。读写请求负载不同的情况下，配置参数需要进行相应的调整，本章节旨在指导用户通过修改RegionServer配置参数进行读写性能调优。

操作步骤

JVM GC参数

  • RegionServer GC_OPTS参数设置建议：
    • -Xms与-Xmx设置相同的值，需要根据实际情况设置，增大内存可以提高读写性能，可以参考参数“hfile.block.cache.size”（见表12-4）和参数“hbase.regionserver.global.memstore.size”（见表12-3）的介绍进行设置。
    • -XX:NewSize与-XX:MaxNewSize设置相同值，建议低负载场景下设置为“512M”，高负载场景下设置为“2048M”。
    • -XX:CMSInitiatingOccupancyFraction建议设置为“100 * (hfile.block.cache.size + hbase.regionserver.global.memstore.size + 0.05)”，最大值不超过90。
    • -XX:MaxDirectMemorySize表示JVM使用的堆外内存，建议低负载情况下设置为“512M”，高负载情况下设置为“2048M”。

Put相关参数

  • RegionServer处理put请求的数据，会将数据写入memstore和hlog，当memstore大小达到设置的“hbase.hregion.memstore.flush.size”参数值大小时，memstore就会刷新到HDFS生成HFile。
  • 当当前region的列簇的HFile数量达到“hbase.hstore.compaction.min”参数值时会触发compaction。
  • 当当前region的列簇HFile数达到“hbase.hstore.blockingStoreFiles”参数值时会阻塞memstore刷新生成HFile的操作，导致put请求阻塞。

Put和Scan性能调优
Put和Scan性能调优
Put和Scan性能调优

4 提升实时写数据效率

操作场景

需要把数据实时写入到HBase中或者对于大批量、连续put的场景。

前提条件

调用HBase的put或delete接口，把数据保存到HBase中。

操作步骤

写数据服务端调优

参数入口：在CDH Manager系统中，选择“服务管理 > HBase > 服务配置”，“参数类别”类型设置为“全部配置”。在搜索框中输入参数名称。

影响实时写数据配置项

实时写数据优化
实时写数据优化
实时写数据优化
实时写数据优化
实时写数据优化

写数据客户端调优

写数据时，在场景允许的情况下，最好使用Put List的方式，可以极大的提升写性能。每一次Put的List的长度，需要结合单条Put的大小，以及实际环境的一些参数进行设定。建议在选定之前先做一些基础的测试。

写数据表设计调优

表12-7 影响实时写数据相关参数

写数据表设计调优

5 提升实时读数据效率

操作场景

需要读取HBase数据场景。

前提条件

调用HBase的get或scan接口，从HBase中实时读取数据。

操作步骤

读数据服务端调优

参数入口：在CDH Manager系统中，选择“服务管理 > HBase > 服务配置”，“参数类别”类型设置为“全部配置”。在搜索框中输入参数名称。

表12-8 影响实时写数据配置项

实时读数据优化

说明：如果同时存在读和写的操作，这两种操作的性能会互相影响。如果写入导致的flush和Compaction操作频繁发生，会占用大量的磁盘IO操作，从而影响读取的性能。如果写入导致阻塞较多的Compaction操作，就会出现Region中存在多个HFile的情况，从而影响读取的性能。所以如果读取的性能不理想的时候，也要考虑写入的配置是否合理。

读数据客户端调优

  • Scan数据时需要设置caching（一次从服务端读取的记录条数，默认是1），若使用默认值读性能会降到极低。
  • 当不需要读一条数据所有的列时，需要指定读取的列，以减少网络IO。
  • 只读取RowKey时，可以为Scan添加一个只读取RowKey的filter（FirstKeyOnlyFilter或KeyOnlyFilter）。

读数据表设计调优

表12-9 影响实时读数据相关参数

读数据表设计调优

6 JVM参数优化操作场景

当集群数据量达到一定规模后，JVM的默认配置将无法满足集群的业务需求，轻则集群变慢，重则集群服务不可用。所以需要根据实际的业务情况进行合理的JVM参数配置，提高集群性能。

操作步骤

参数入口：HBase角色相关的JVM参数需要配置在“${HBASE_HOME}/conf”目录下的“hbase-env.sh”文件中。

每个角色都有各自的JVM参数配置变量，如表12-10。

表12-10 HBase相关JVM参数配置变量

JVM参数优化

5 Hdfs优化

HDFS优化

1 提升写性能

操作场景

在HDFS中，通过调整属性的值，使得HDFS集群更适应自身的业务情况，从而提升HDFS的写性能。

操作步骤

参数入口：在CDH Manager系统中，选择“服务管理 > HDFS > 服务配置”，“参数类别”类型设置为“全部配置”。在搜索框中输入参数名称。

表12-11 HDFS写性能优化配置

HDFS写性能优化

2 JVM参数优化

操作场景

当集群数据量达到一定规模后，JVM的默认配置将无法满足集群的业务需求，轻则集群变慢，重则集群服务不可用。所以需要根据实际的业务情况进行合理的JVM参数配置，提高集群性能。

操作步骤

参数入口：HDFS角色相关的JVM参数需要配置在“${HADOOP_HOME}/etc/hadoop”目录下的“hadoop-env.sh”文件中。

JVM各参数的含义请参见其官网：JVM参数说明

每个角色都有各自的JVM参数配置变量，如表12-12。

表12-12 HDFS相关JVM参数配置变量

HDFS JVM参数优化

配置方式举例：

bash 复制代码 
export HADOOP_NAMENODE_OPTS="-Dhadoop.security.logger=${HADOOP_SECURITY_LOGGER:-INFO,RFAS} -Dhdfs.audit.logger=${HDFS_AUDIT_LOGGER:-INFO,N

3 使用客户端元数据缓存提高读取性能

操作场景

通过使用客户端缓存元数据块的位置来提高HDFS读取性能。

说明：
此功能仅用于读取不经常修改的文件。因为在服务器端由某些其他客户端完成的数据修改，对于高速缓存的客户端将是不可见的，这可能导致从缓存中拿到的元数据是过期的。

操作步骤

设置参数的路径：在CDH Manager页面中，选择“服务管理 > HDFS > 服务配置”，将“参数类别”设置为“全部配置”，并在搜索框中输入参数名称。

表12-13 参数配置

客户端元数据缓存

说明：

  • 要在过期前完全清除客户端缓存，可调用DFSClient#clearLocatedBlockCache()。
  • 用法如下所示：
    java 复制代码 
    FileSystem fs = FileSystem.get(conf);
DistributedFileSystem dfs = (DistributedFileSystem) fs;
DFSClient dfsClient = dfs.getClient();
dfsClient.clearLocatedBlockCache();

4 使用当前活动缓存提升客户端与NameNode的连接性能

操作场景

HDFS部署在具有多个NameNode实例的HA（High Availability）模式中，HDFS客户端需要依次连接到每个NameNode，以确定当前活动的NameNode是什么，并将其用于客户端操作。一旦识别出来，当前活动的NameNode的详细信息就可以被缓存并共享给在客户端机器中运行的所有客户端。这样，每个新客户端可以首先尝试从缓存加载活动的NameNode的详细信息，并将RPC调用保存到备用的NameNode。在异常情况下有很多优势，例如当备用的NameNode连接长时间不响应时。当发生故障，将另一个NameNode切换为活动状态时，缓存的详细信息将被更新为当前活动的NameNode的信息。

操作步骤

设置参数的路径如下：在CDH Manager页面中，选择“服务管理 > HDFS > 服务配置”，将“参数类别”设置为“全部配置”，并在搜索框中输入参数名称。

表12-14 配置参数

NameNode连接性能优化

6 Zookeeper优化

Zookeeper优化

7 Kafka优化

Kafka优化

8 YARN + MapReduce优化

YARN优化
MapReduce优化

9 Hive优化

Hive优化
Hive优化

10 Kudu优化

Kudu优化

  1. Kudu后台对数据进行维护操作，如写入数据时的并发线程数，一般设置为4，官网建议的是数据目录的3倍。

    • Kudu Tablet Server Maintenance Threads：这个参数决定了Kudu后台对数据进行维护操作，如写入数据时的并发线程数。并发数越大，吞吐量越高，但对集群计算能力的要求也越高。默认值为1，表示Kudu会采用单线程操作；对于需要大量数据进行快速写入/删除的集群，可以设置更大的值。该值可以设置跟计算节点的数据磁盘数量和CPU核数有关，一般来说，建议设置为4以获取比较均衡的性能，最大不超过8。
    • 参数：maintenance_manager_num_threads

  2. 分配给Kudu Tablet Server块缓存的最大内存量，建议是2-4G。

    • Kudu Tablet Server Block Cache Capacity：Tablet的Block buffer cache，根据集群内存配置和数据量规模设置。一般建议至少2GB～4GB。
    • 参数：block_cache_capacity_mb

  3. Tablet Server能使用的最大内存量，有多大，设置多大。

    • Tablet Server在批量写入数据时并非实时写入磁盘，而是先Cache在内存中，在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。
    • 对于写入性能要求比较高的集群，建议设置更大的值（一般是机器内存的百分之80）。
    • Kudu Tablet Server Hard Memory Limit：Kudu的Tablet Server能使用的最大内存。
    • 参数：memory_limit_hard_bytes

  4. 参数决定了Kudu能够同时打开的操作系统文件数。不设置则使用系统的ulimits值，设置后会覆盖系统的设置。

    • 需要根据集群的规模及并发处理能力，非常谨慎的设置这个值。
    • 参数：Maximum Process File Descriptors

  5. 参数设置了每个Tablet的默认复制因子，默认值为3，表示每个表的数据会在Kudu中存储3份副本。

    • 我们可以根据需要修改这个全局默认值，也可以在建表语句中通过kudu.num_tablet_replicas属性来设置每个表的副本数。
    • 参数：kudu.num_tablet_replicas=1

  6. tserver宕掉后，5分钟后没有恢复的情况下，该机器上的tablet会移动到其他机器。

    • 参数：--follower_unavailable_considered_failed_sec=300

  7. 超过参数时间的历史数据会被清理，如果是base数据不会被清理。而真实运行时数据大小持续累加，没有被清理。

    • 参数：--tablet_history_max_age_sec=900

  8. hash分区数量 * range分区数量不能超过60个（1.7.0版本之后没限制了）。

  9. 设置block的管理器为文件管理器（默认是日志服务器）。

    • 解释：并非所有文件系统格式都需要设置该选项。ext4、xfs格式支持hole punching（打孔），所以不需要设置block_manager=file，但是ext3格式需要。可以通过df -Th命令来查看文件系统的格式。
    • 参数：--block_manager=file

  10. 设置ntp服务器的时间误差不超过20s（默认是10s）。

    • 参数：max_clock_sync_error_usec=20000000

  11. 设置rpc的连接时长（默认是3s，建议不要设置）。

    • 参数：--rpc_negotiation_timeout_ms=300000

  12. 设置rpc一致性选择的连接时长（默认为1s，建议不要设置）。

    • 参数：--consensus_rpc_timeout_ms=1000

  13. 记录kudu的crash的信息。

    • 解释：
      • Kudu在遇到崩溃时，使用Google Breakpad库来生成minidump。这些minidumps的大小通常只有几MB，即使禁用了核心转储生成，也会生成。
      • 生成minidumps只能在Linux上建立。
      • minidump文件包含有关崩溃的进程的重要调试信息，包括加载的共享库及其版本，崩溃时运行的线程列表，处理器寄存器的状态和每个线程的堆栈内存副本，以及CPU和操作系统版本信息。
      • Minitump可以通过电子邮件发送给Kudu开发人员或附加到JIRA，以帮助Kudu开发人员调试崩溃。为了使其有用，开发人员将需要知道Kudu的确切版本和发生崩溃的操作系统。请注意，虽然minidump不包含堆内存转储，但它确实包含堆栈内存，因此可以将应用程序数据显示在minidump中。如果机密或个人信息存储在群集上，请不要共享minidump文件。
    • 参数：
      • --minidump_path=minidumps
      • --max_minidumps=9
      • （默认是在设置的log目录下生成minidumps目录，里边包含最多9个以dmp结尾的文件，无法设置为空值，需要注意的是如果自定义minidump文件，在master不能启动的情况下，需要将该目录中的文件删除）

  14. Stack WatchLog。

    • 解释：每个Kudu服务器进程都有一个称为Stack Watchdog的后台线程，它监视服务器中的其他线程，以防它们被阻塞超过预期的时间段。这些跟踪可以指示操作系统问题或瓶颈存储。通过WARN日志信息的跟踪（Trace）可以用于诊断由于Kudu以下的系统（如磁盘控制器或文件系统）引起的根本原因延迟问题。

  15. cdh设置多master。

    • 参数：--master_addresses=cdh01:7051,cdh02:7051cdh03:7051

  16. kudu出现启动速度特别慢。

    • 解决办法：
      1. 取消所有配置参数（除了资源、时间同步）
      2. 升级版本到kudu1.6.0
      3. client必须停止（client不占用io的情况，3台机器，每台机器60G，127分区数量，启动速度3分钟）
      4. 查看io使用情况 iostat -d -x -k 1 200

  17. 单hash分区最大是60。

  18. 安装kudu过程中，会要求CPU支持ssc4.2指令集，但是我们的虚拟机cpu没有这个执行集，所以无法安装。

  19. 设置client长连接过期时间。

    • 参数：--authn_token_validity_seconds=12960000（150天）
    • 注意：设置到tserver的配置文件中。

  20. tserver和master的wal和data目录要分隔（或者是目录设置为lvm卷轴）。

    • 原因：wal目录只能设置为1个。
    • 参数：--fs_wal_dir_reserved_bytes
    • 解释：
      • Number of bytes to reserve on the log directory filesystem for non-Kudu usage. The default, which is represented by -1, is that 1% of the disk space on each disk will be reserved.
      • Any other value specified represents the number of bytes reserved and must be greater than or equal to 0.
      • Explicit percentages to reserve are not currently supported.
      • 用于非kudu都使用的日志目录文件系统的字节数，默认情况下是-1，每个磁盘上的磁盘空间的1%将被保留，指定的任何其他值表示保留的字节数，必须大于或等于0。

  21. 设置用户权限，能移动tablet。

    • 参数：--superuser_acl=*

参数调优核心总结为两个字：平衡。

  1. 时效和稳定性的平衡；
  2. 资源的平衡，在某一时间点，集群的内存、io、cpu等负载均衡。

11 CDH的组件java调优建议值

CDH组件调优
CDH组件调优

12 常见优化参数

1: hdfs相关优化

  1. dfs.block.size
    • HDFS中的数据block大小，默认是64M，对于较大集群，可以设置为128或264M。
  2. dfs.datanode.socket.write.timeout
    • 增加dfs.datanode.socket.write.timeout和dfs.socket.timeout两个属性的时间，避免出现IO超时。
  3. dfs.datanode.max.transfer.threads
    • 增加datanode在进行文件传输过程中的最大线程数。默认值4096，可修改为8192。
  4. dfs.namenode.handler.count
    • NameNode中用于处理RPC调用的线程数,即指定NameNode的服务器线程的数量。NameNode有一个工作线程池用来处理客户端的远程过程调用及集群守护进程的调用，处理程序数量越多意味着要更大的池来处理来自不同DataNode的并发心跳以及客户端并发的元数据操作）。对于大集群或者有大量客户端的集群来说，通常需要增大参数dfs.namenode.handler.count的默认值10。设置该值的一般原则是将其设置为集群大小的自然对数乘以20，即20logN，N为集群大小。
    • 如果该值设的太小，明显的状况就是DataNode在连接NameNode的时候总是超时或者连接被拒绝，但NameNode的远程过程调用队列很大时，远程过程调用延时就会加大。症状之间是相互影响的，很难说修改dfs.namenode.handler.count就能解决问题，但是在查找故障时，检查一下该值的设置是必要的。如果前面的描述你仍然觉得很不清楚，可以看下面的python程序，假设我们大数据集群的大小为500台，那么我们可以直接看怎么计算应该设置合理值。
  5. dfs.datanode.handler.count
    • 数据节点的服务器线程数，默认为10。可适当增加这个数值来提升DataNode RPC服务的并发度。在DataNode上设定,取决于系统的繁忙程度,设置太小会导致性能下降甚至报错。线程数的提高将增加DataNode的内存需求，因此，不宜过度调整这个数值。
  6. dfs.namenode.avoid.read.stale.datanode
    • 指示是否避免读取“过时”的数据节点（DataNode），这些数据节点（DataNode）的心跳消息在指定的时间间隔内未被名称节点（NameNode）接收。过时的数据节点（DataNode）将移动到返回供读取的节点列表的末尾。有关写入的类似设置，请参阅df.namenode.avoint.write.stale.datanode。默认值是false，推荐设置为true。
  7. dfs.namenode.avoid.write.stale.datanode
    • 指示超过失效DataNode时间间隔NameNode未收到检测信号信息时是否避免写入失效DataNode。写入应避免使用失效DataNode，除非多个已配置比率（dfs.namenode.write.stale.datanode.ratio）的DataNode标记为失效。有关读取的类似设置，请参阅dfs.namenode.avoid.read.stale.datanode。默认值是false，推荐设置为true。
  8. fs.trash.interval
    • 注：该配置底层文件在core-default.xml。
    • 垃圾桶检查点之间的分钟数。还可控制删除垃圾桶检查点目录后的分钟数。要禁用垃圾桶功能，请输入0。默认为禁用垃圾桶功能。为防止重要文件误删，可启用该特性。
  9. hive.merge.sparkfiles
    • 在Spark作业结束时合并小文件。如启用，将创建map-only作业以合并目标表/分区中的文件。

2: Yarn相关优化

Nodemanager:

  • yarn.nodemanager.resource.cpu-vcores:64
    • 每个节点最大使用的vcore数，可以适当放大(一般以2倍去放大，提高CPU的使用率)。
  • yarn.nodemanager.resource.memory-mb
    • 调整每台物理机器可以被调度的内存资源。
  • yarn.nodemanager.vmem-pmem-ratio=50
    • 物理内存和虚拟内存的比例,任务每使用1MB物理内存，最多可使用虚拟内存量，默认为2.1。
  • yarn.nodemanager.pmem-check-enabled
    • 是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
  • yarn.nodemanager.vmem-check-enabled
    • 是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

ResourceManager:(yarn-site.xml 中设置 container)

  • yarn.scheduler.minimum-allocation-mb:1024
    • 最小可申请内存量，默认1024,如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。
  • yarn.scheduler.maximum-allocation-mb: 8069
    • 单个container最大可申请内存量，默认是8069（不能超过物理机的最大内存）。
  • yarn.scheduler.minimum-allocation-vcores: 1
    • 最小可申请CPU数，默认是1。
  • yarn.scheduler.maximum-allocation-vcores:
    • 单个container最大可申请CPU数（也是tm最大可设置的slot，和物理机核数保持一致即可）。

ApplicationMaster:

  • mapreduce.map.memory.mb=2048
    • 分配给Map Container的内存大小，运行时按需指定。
  • mapreduce.reduce.memory.mb=4096
    • 分配给Reduce Container的内存大小，运行时按需指定。
  • yarn.scheduler.minimum-allocation-vcores
    • 单个任务可申请的最小虚拟CPU个数,默认是1。
  • yarn.scheduler.maximum-allocation-vcores
    • 单个任务可申请的最多虚拟CPU个数（不能超过物理机的最大CPU个数）。

3：Kafka相关优化

broker端：

  • message.max.bytes
    • 此设置用于设置message.max.bytes参数来限制单个消息的大小，默认值是10000000，也就是1MB。
  • num.replica.fetchers
    • 建议设置为CPU核心数/4，适当提高可以提升CPU利用率及Follower同步Leader数据当并行度。
  • num.network.threads
    • 处理消息的最大线程数。broker处理消息的最大线程数，默认为3，建议设为cpu核数+1。
  • num.io.threads
    • broker处理磁盘IO的线程数，建议设为cpu核数x2。
  • auto.leader.rebalance.enable

end