主要有以下几个方面

操作系统调优 、磁盘、 网络、 jvm调优 、MirrorMaker调优

操作系统调优

虽然大多数Linux发行版都有一个针对内核调优参数的开箱即用配置，这对大多数应用程序都相当有效，但对于Kafka代理，也有一些更改可以提高性能。这些问题主要围绕着虚拟内存和网络子系统，以及用于存储日志段的磁盘装入点的具体问题。这些参数通常在/etc/sysctl.conf文件中配置，但是有关如何调整内核配置的具体详细信息，请参考Linux发行版的文档。

虚拟内存

虚拟内存通常，Linux虚拟内存系统会根据系统的工作负载自动调整。我们可以对交换空间的处理方式以及脏内存页面进行一些调整，以根据卡夫卡的工作负载调整它。与大多数应用程序一样——特别是涉及吞吐量的应用程序——最好避免（几乎）所有成本进行交换。将内存页面交换到磁盘所产生的成本将会对卡夫卡的内存运行的各个方面产生显著的影响。此外，Kafka大量使用系统页面缓存，如果虚拟机系统正在交换到磁盘，则没有为页面缓存分配足够的内存。

避免交换的一种方法是根本不配置任何交换空间。交换不是要求的，但如果系统发生了灾难性的事故，它确实提供了一个安全网。有交换可以防止操作系统由于内存不足而突然终止进程。因此，建议将vm.swappiness参数设置为一个非常低的值，例如1。该参数是虚拟机子系统使用交换空间而不是从页面缓存中删除页面的可能性的每个比例。最好是减少页面缓存的大小，而不是交换。

为什么不将切换状态设置为零呢？

以前，建议vm.swappiness总是将其设置为0。这个值过去的含义是“除非出现内存不足的情况，否则不要交换”。然而，随着Linux内核3.5-rc1版本的出现，这个值的含义发生了变化，并且这种变化被反向移植到许多发行版中，包括版本2.6.32-303版本中的红帽企业Linux内核。这将值0的含义改为“在任何情况下都不要交换”。因此，现在建议使用一个值为1。

调整内核处理必须刷新到磁盘的脏页的方式，还有一个好处。Kafka依赖于磁盘I/O性能来为生产者提供良好的响应时间。这也是日志段通常被放在快速磁盘上的原因，无论是具有快速响应时间的单个磁盘（例如SSD），还是具有用于缓存的显著NVRAM的磁盘子系统（例如RAID）。其结果是，在刷新后台进程开始将脏页写入磁盘之前，允许的脏页数量可以减少。这是通过将=vm.dirty_background_ratio值低于默认值10来实现的。该值是系统内存总量的百分比，在许多情况下，将此值设置为5是近似的。但是，此设置不应该设置为零，因为这将导致内核不断地刷新页面这将消除Kaffa内核缓冲磁盘写以对抗底层设备性能中的临时峰值的能力。在内核强制同步操作将它们刷新到磁盘之前允许的脏页总数也可以通过更改vm.dirty_ratio的值来增加，增加到默认的20以上（也占系统内存总数的百分比）。这个设置有很多可能的值范围，但在60到80之间是一个合理的数字。此设置确实引入了少量的风险，包括未刷新的磁盘活动的数量，以及如果强制同步刷新，可能会出现长时间的I/O暂停。如果选择了更高的vm.dirty_ratio设置，则强烈建议在Kaffa集群中使用复制，以防止系统故障。在为这些参数选择值时，明智的做法是查看Kafka集群在负载下运行时，无论是在生产中还是在模拟中。当前的脏页数可以通过检查/proc/vmstat文件来确定：

cat /proc/vmstat | egrep "dirty|writeback"

nr_dirty 3875

nr_writeback 29

nr_writeback_temp 0

磁盘

除了选择磁盘设备硬件以及使用RAID的配置之外，用于此磁盘的文件系统的选择可能会对性能产生第二大的影响。有许多不同的文件系统可用，但是本地文件系统的最主要选择是EXT4（第四个扩展文件系统）或扩展文件系统（XFS）。最近，XFS已经成为许多Linux发行版的默认文件系统，这是有充分理由的——它在大多数工作负载中优于EXT4，所需的调优小于EXT4。EXT4可以表现良好，但它需要使用被认为不太安全的调优参数。这包括将手术时间间隔设置为比默认的时间5更长，以减少冲洗的次数。EXT4还引入了块的延迟分配 在系统故障的情况下，数据丢失和文件系统损坏的可能性更大。XFS文件系统也使用了延迟分配算法，但它通常比EXT4使用的算法更安全。XFS对于Kafka的工作负载也有更好的性能，而不需要在文件系统执行的自动调优之外进行调优。在批处理磁盘写入时，它也更有效，所有这些结合在一起可以提供更好的整体I/O吞吐量。

无论为保存日志段的装载选择了哪个文件系统，都建议为装载点设置节点装载选项。文件元数据包含三个时间戳创建时间（ctime）、最后一次修改的时间（mtime）和最后一次访问时间（时间）。默认情况下，每次读取文件时都会更新自动模式。这将产生大量的磁盘写操作。atime属性通常被认为没有什么用处，除非应用程序需要知道一个文件在上次修改后是否已经被访问过（在这种情况下可以使用实时选项）。卡夫卡根本不使用它，所以禁用它是安全的。在挂载上设置噪声将防止这些时间戳更新发生，但不会影响ctime和mtime属性的正确处理。

网络

对于任何产生大量网络流量的应用程序，调整Linux网络堆栈的默认调优是常见的，因为内核对于大型高速数据传输没有默认调优。事实上，为Kaffa建议的更改与为大多数web服务器和其他网络应用程序建议的更改相同。第一个调整是更改为每个套接字的发送和接收缓冲区分配的默认内存量和最大内存量。这将显著提高大型传输的性能。每个套接字的发送和接收缓冲区默认大小的相关参数为net.core.wmem_default和net.core.rmem_default，这些参数的合理设置为131072，或128 KiB。发送和接收缓冲区的最大大小参数为net.core.wmem_max和net.core.rmem_max，合理的设置为2097152，或2 MiB。请记住，最大大小并不表示每个套接字都有这么多的缓冲空间；它只在需要的时候允许这么多。

除了套接字设置外，TCP套接字的发送和接收缓冲区大小也必须分别使用net.ipv4.tcp_wmem和net.ipv4.tcp_rmem参数进行设置。它们使用三个空格分隔的整数进行设置，分别指定最小值、默认值和最大大小。最大大小不能大于使用net.core.wmem_max和net.core.rmem_max为所有套接字指定的值。这些参数的一个示例设置是“4096 65536 2048000”，这是一个4 KiB最小值，64 KiB默认值和2 MiB最大缓冲区。基于Kafka代理的实际工作负载，您可能希望增加最大大小，以允许网络连接的缓冲。

还有其他几个有用的网络调优参数。通过将net.ipv4.tcp_window_scaling设置为1来启用TCP窗口缩放，将允许客户端更有效地传输数据，并允许在代理端缓冲这些数据。将net.ipv4.tcp_max_syn_backlog的值增加到默认值1024以上，将允许接受更多的同时连接。将net.core.netdev_max_backlog的值增加到大于默认值1000可以帮助处理网络流量的爆发，特别是在使用多千兆网络连接速度时，通过允许更多的数据包排队等待内核来处理它们。

生产问题一旦您准备好将Kafka环境从测试中转移到生产操作中，还需要考虑的一些事情将有助于建立可靠的消息传递服务。

垃圾收集器选项

为应用程序调优Java垃圾收集选项一直是一门艺术的东西，需要关于应用程序如何使用内存、大量观察、试验和错误的详细信息。值得庆幸的是，随着Java 7和垃圾优先（或G1）垃圾收集器的引入，这种情况发生了改变。G1被设计为自动调整不同的工作负载，并在应用程序的生命周期内为垃圾收集提供连续的暂停时间。它还通过将堆分割为较小的区域，而不在每次暂停中收集整个堆，轻松地处理大的堆大小。

G1在正常操作中以最小的配置完成所有这些。G1有两个配置选项，用于调整其性能：

MaxGCPauseMillis

这个选项指定了每个垃圾收集周期的首选暂停时间。它不是一个固定的最大值-如果需要，g1可以并且将超过这个时间。此值默认为200毫秒。这意味着G1将尝试安排GC周期的频率，以及在每个周期中收集的区域的数量，这样每个周期将需要大约200 ms。

InitiatingHeapOccupancyPercent

初始化堆占用百分比此选项指定在G1将开始收集周期之前可能使用的总堆的百分比。默认值为45。这意味着G1只有在45%的堆被使用之后才会开始一个收集周期。这包括新（伊甸园）和旧区域的使用。

Kafka代理利用堆内存和创建垃圾对象的方式相当有效，因此可以将这些选项设置得更低。本节中提供的GC调优选项适用于具有64 GB内存的服务器，并在5GB堆中运行Kafka。对于Maxgcp ms，此代理可以配置为20 ms。“初始化堆占用率百分比”的值被设置为35，这将导致垃圾收集的运行时间略早于使用默认值。

Kafka的开始脚本不使用G1收集器，而是默认使用并行的新标记和并发标记和扫描垃圾收集。通过环境变量进行更改。使用本章前面的开始命令，对其进行如下修改

export JAVA_HOME=/usr/java/jdk1.8.0_51

export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC

-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35

-XX:+DisableExplicitGC -Djava.awt.headless=true"

/usr/local/kafka/bin/kafka-server-start.sh -daemon

/usr/local/kafka/config/server.properties

数据配置

对于开发系统，数据中心中的Kafka代理的物理位置并不那么重要，因为如果集群在短时间内部分或完全不可用，就不会产生那么严重的影响。然而，在服务生产流量时，停机意味着美元损失，无论是由于用户失去服务还是对用户正在做什么的遥测损失。这是在Kafka集群中配置复制变得关键时，这也是考虑数据中心机架中代理的物理位置也很重要的时候。如果在部署Kafka之前没有解决，那么可能需要昂贵的维护来移动服务器。

Kafka代理在向代理分配新的分区时没有机架意识。这意味着它不能考虑两个代理可能位于同一物理机架中，或者位于同一可用性区域（如果运行在AWS等云服务中运行），因此可以很容易地将分区的所有副本分配给共享相同机架中相同电源和网络连接的代理。如果该机架出现故障，这些分区将脱机，客户端无法访问。此外，由于不干净的领导人选举，它可能导致额外的恢复数据丢失

最佳实践是将集群中的每个Kafka代理安装在不同的机架上，或者至少不共享电力和网络等基础设施服务的单点故障点。这通常意味着至少部署将运行具有双电源连接（到两个不同的电路）和双网络交换机（通过服务器本身的连接接口进行无缝故障切换）的代理的服务器。即使有双重连接，让经纪人坐在完全便宜的货架上也有好处。有时需要对机柜或机柜进行物理维护（例如移动服务器，或重新布线电源连接）。

调优MirrorMaker

MirrorMaker集群的大小取决于您需要的吞吐量和滞后你可以容忍。如果您不能容忍任何滞后，则必须调整MirrorMaker的大小足够的容量来满足您的最高吞吐量。如果你能忍受一些滞后，您可以将MirrorMaker的大小调整为75-80%的使用率为95-99%。那么，期待当您处于吞吐量峰值时，需要一些滞后。因为MirrorMaker具有在大多数情况下，备用容量会在高峰结束后赶上。然后，您需要使用不同num.streams参数配置的使用者线程数。我们可以给你一些大概的数字（LinkedIn获得6MB/s，有8个消费者线程

12MB/s（16），但由于这在很大程度上取决于您的硬件、数据中心或云

提供者，您将希望运行自己的测试。卡夫卡与卡夫卡同行￾性能生成器工具。使用它在源集群上生成负载，然后

连接MirrorMaker并开始镜像此负载。使用1、2、4、8、16、，24和32个消费者线程。观察性能逐渐减弱的地方num.streams刚好低于此点。如果您正在消费或生产压缩事件（推荐，因为带宽是跨数据中心的主要瓶颈），MirrorMaker将不得不解压缩并重新压缩事件。这Apache Kafka的MirrorMaker | 175使用大量CPU，使用此过程，您将找到可以获得的最大吞吐量单个MirrorMaker实例。如果这还不够，你会想用

额外的实例，然后是额外的服务器。

这几乎是您可以对MirrorMaker本身进行的所有调整。然而，你仍然可以增加每个使用者线程和每个MirrorMaker的吞吐量

例子

如果您正在跨数据中心运行MirrorMaker，则需要优化网络

Linux中的工作配置如下：

•增加TCP缓冲区大小（net.core.rmem_default、net.core_rmem_max、，

net.core.wmem_default、net.core.wmem_max、net.core.optimem_max）

•启用自动窗口缩放（sysctl–w net.ipv4.tcp_window_scaling=1

或将net.ipv4.tcp_window_scaling=1添加到/etc/sysctl.conf）

•减少TCP慢速启动时间（设置/proc/sys/net/ipv4/

tcp_slow_start_after_idle设置为0）

请注意，调整Linux网络是一个庞大而复杂的主题。了解更多关于这些参数和其他参数，我们建议阅读网络调整指南例如Sandra K.Johnson等人

总结

操作系统调优

vm.swappiness=1 启动交换

vm.dirty_background_ratio=5 设置低于默认

网络调优

增加套接字

net.core.wmem_default=131072

net.core.rmem_default=131072

发送和接收缓冲区

net.core.wmem_max=2097152

net.core.rmem_max=2097152

TCP套接字的发送和接收缓冲区

net.ipv4.tcp_wmem=10240 87380 12582912

net.ipv4.tcp_rmem=10240 87380 12582912

net.core.wmem_max=12582912

net.core.rmem_max=12582912

TCP窗口缩放

net.ipv4.tcp_window_scaling=1

接受更多的同时连接

net.ipv4.tcp_max_syn_backlog=2048

网络流量的爆发

net.core.netdev_max_backlog=8096

gc调优

export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC

-XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35

-XX:+DisableExplicitGC -Djava.awt.headless=true"

MirrorMaker调优

如果您正在跨数据中心运行MirrorMaker，则需要优化网络

Linux中的工作配置如下：

•增加TCP缓冲区大小（net.core.rmem_default、net.core_rmem_max、，

net.core.wmem_default、net.core.wmem_max、net.core.optimem_max）

•启用自动窗口缩放（sysctl–w net.ipv4.tcp_window_scaling=1

或将net.ipv4.tcp_window_scaling=1添加到/etc/sysctl.conf）

•减少TCP慢速启动时间（设置/proc/sys/net/ipv4/

tcp_slow_start_after_idle设置为0）

请注意，调整Linux网络是一个庞大而复杂的主题。了解更多关于这些参数和其他参数，我们建议阅读网络调整指南例如Sandra K.Johnson等人