Linux内核参数优化

前言

Linux内核有非常多的参数，而对这些内核参数的修改会尽可能的提高内核的稳定性，并且，在业务高峰期的时候，可以保证内核尽可能的稳定高效，而不是某些非常低级的DDOS洪水就崩溃的Linux内核。总的来说，系统内核的优化是对系统稳定高效的运行的一个重要的强有力的保障。

那么，Linux的内核参数是可以按照它们的功能进行一个简单的分类的，大体分类为：网络层面，文件系统层面（也就是指的文件打开数，文件的读写性能这些参数），内存层面，内核层面。

通常Linux系统是使用最低的内核参数，就像CPU一样，通常是降频使用的，这么做的目的无非是为了系统的稳定性，但性能会有很多的牺牲，并且，这些默认的参数仅仅是针对普通的日常运行，而生产当中，第一是需要压榨服务器的性能（也可以称为提高服务器的性能），从而保证生产活动中的很多任务能够圆满完成（比如，文件打开数如果不做优化，有的时候会非常尴尬的发现，某些程序运行不正常啦。），第二是某些安全性方面的提升（网络层面的优化可以使得服务器自身就可以有一定的网络防御，毕竟装甲厚度高一点对服务器的安全也是有一定的好处的嘛）。

一、修改内核参数的方法

1.1 临时生效

sysctl 命令用来配置linux 系统内核参数，这些参数以文件的形式显示在 /proc/sys/ 目录中

配置项就是目录名加文件名，值就是该文件中的内容

以大家最为熟悉的关于路由转发为例，它的内核参数名是 net.ipv4.ip_forward ，那么它的路径就是 /proc/sys/net/ipv4/ip_forward

[root@ubuntu2004 ~]#cat /proc/sys/net/ipv4/ip_forward
0

那么临时生效有两种方法

第一种：sysctl 命令

#通过-w选项设置参数的值
[root@ubuntu2004 ~]#sysctl -w net.ipv4.ip_forward=0
net.ipv4.ip_forward = 0

#-a表示查看所有生效参数
[root@ubuntu2004 ~]#sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 0

第二种：echo命令

[root@ubuntu2004 ~]#echo 0 > /proc/sys/net/ipv4/ip_forward

[root@ubuntu2004 ~]#sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 0

1.2 永久生效

永久生效就是写入配置文件啦，配置文件的路径是 /etc/sysctl.conf 

[root@ubuntu2004 ~]#vim /etc/sysctl.conf
net.ipv4.ip_forward = 1

#读取配置文件，不执行这条命令是不会生效的
[root@ubuntu2004 ~]#sysctl -p
net.ipv4.ip_forward = 1

[root@ubuntu2004 ~]#sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

注意：不是所有内核参数都是可以被修改的

二、关于TCP的内核参数

2.1 sync半连接和accept全连接队列

半连接和全连接的概念

• 半连接：还没有完成3次握手的连接
• 全连接：己经完成三次握手，但没有被应用层提走的连接

如下图所示

作为服务器来说，能接收的用户请求的数量是有限制的，这个数量会放在sync半连接队列里，在第一次握手和第二次握手后，用户就会占一个队列，每一个用户发请求过来都会占一个队列，直到第三次握手后，才会删除。三次握手完成后，就会把用户请求放在了全连接队列中，然后用户发起新的请求，需要accept函数来接收这个请求，接收之后就把队列的值删除。

SYN洪泛攻击

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

为了缓解 SYN FLOOD 等利用 TCP 协议特点进行攻击而引发的性能问题，可以考虑优化下列的内核参数，其中增大 TCP 半连接的最大数量可以增加服务器能够同时处理的半连接数量，从而减轻 SYN FLOOD 攻击对服务器性能的影响。虽然这不是一种完全有效的解决方案，但可以为服务器提供一定程度的防御能力，使其更能够抵御攻击。同时可以确保服务器能够维护更多的合法连接，避免因连接数量不足而导致合法连接被拒绝的情况发生。

#未完成连接队列大小，即半连接队列长度，默认值128，建议调整大小为1024以上
net.ipv4.tcp_max_syn_backlog

#完成连接队列大小，默认值128，建议调整大小为1024以上，在高并发请求中，可能会导致链接超时或重传，一般结合并发请求数来调大此值。
net.core.somaxconn

#内核放弃连接之前发送SYN+ACK包的数量。将该值设置为较小的值，减少 SYN_RECV 状态的连接重传 SYN+ACK 包的次数。
net.ipv4.tcp_synack_retries = 1

 

2.2 TCP超时重传

异常网络状况下（开始出现超时或丢包），TCP控制数据传输以保证其承诺的可靠服务TCP服务必须能够重传超时时间内未收到确认的TCP报文段。为此，TCP模块为每个TCP报文段都维护一个重传定时器，该定时器在TCP报文段第一次被发送时启动。如果超时时间内未收到接收方的应答，TCP模块将重传TCP报文段并重置定时器。至于下次重传的超时时间如何选择，以及最多执行多少次重传，就是TCP的重传策略。

与TCP超时重传相关的两个内核参数

#指定在底层IP接管之前TCP最少执行的重传次数，默认值是3
/proc/sys/net/ipv4/tcp_retries1

#指定连接放弃前TCP最多可以执行的重传次数，默认值15（一般对应13～30min）
/proc/sys/net/ipv4/tcp_retries2

2.3 TIME_WAIT 状态

在请求数比较大的场景下，连接频繁地建立和关闭，你可能会看到大量处于 TIME_WAIT 状态的连接，它们会占用大量内存和端口资源。这时，我们可以优化与 TIME_WAIT 状态相关的内核参数。

#系统同时保持TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立刻被清除并打印警告信息。默认为180000，对于Apache、Nginx等服务器来说可以将其调低一点，如改为5000~30000，不同业务的服务器也可以给大一点，比如LVS、Squid。 此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。
net.ipv4.tcp_max_tw_buckets = 36000

#用于设置系统中 Connection Tracking（连接跟踪）机制的最大连接数，当系统中的连接数量超过了这个限制时，新的连接请求可能会被拒绝或者丢弃
net.netfilter.nf_conntrack_max

#表示开启端口重用。被 TIME_WAIT 状态占用的端口还能用到新建的连接中，默认值为0，表示关闭。
net.ipv4.tcp_tw_reuse = 1

#表示开启TCP连接中TIME-WAIT sockets的快速回收。默认为0，表示关闭。注意：reuse和recycle这两个参数是为防止生产环境下服务器time_wait网络状态数量过多设置的。
net.ipv4.tcp_tw_recycle = 1

#表示套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间，默认值是60秒。我们需要设置小一点的值。
net.ipv4.tcp_fin_timeout = 2

#用于设置连接跟踪表中处于 TIME_WAIT 状态的 TCP 连接的超时时间，即最大报文生存时间，将其设置小一点可以及时释放系统资源。需要注意的是，调整这个参数可能会对系统的性能和稳定性产生影响。
net.netfilter.nf_conntrack_tcp_timeout_time_wait

#用来设定允许系统打开的端口范围，即用于向外连接的端口范围。我们可以增大本地端口的范围，可以支持更多连接，提高整体的并发能力。
net.ipv4.ip_local_port_range = 2000 65000

# 一个进程可以打开的最大文件数。
fs.nr_open = 40000500

#设置系统所有进程一共可以打开的文件数量，可以和fs.nr_open一起使用。
fs.file-max = 40000500

2.4 TCP长连接

长连接的操作步骤是：

• 建立连接——数据传输…（保持连接）…数据传输——关闭连接

我们模拟一种长连接的情况:

• client 向 server 发起连接

• server 接到请求，双方建立连接

• client 向 server 发送消息

• server 回应 client

• 一次读写完成，连接不关闭

• 后续读写操作…

• 长时间操作之后client发起关闭请求

应用场景：

• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三次握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包就OK了，不用建立TCP连接。

• 例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

长连接的优点和缺点：

• 长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，适合长连接

• client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

在长连接的场景中，通常使用 Keepalive 来检测 TCP 连接的状态，以便对端连接断开后，可以自动回收。但是，系统默认的 Keepalive 探测间隔和重试次数，一般都无法满足应用程序的性能要求。所以，这时候你需要优化与 Keepalive 相关的内核参数。

#表示当keepalive启用时，间隔多久发送1次keepalive探测包，即TCP发送keepalive消息的频度。默认是2小时，建议改为10分钟。
net.ipv4.tcp_keepalive_time = 600

#探测失败后，间隔几秒后重新探测。根据实际情况缩短发送 Keepalive 探测包的间隔时间。
net.ipv4.tcp_keepalive_intvl = 15

#Keepalive 探测失败后，还需要发送多少次 keepalive 消息才判断连接已经断开，即重试次数。根据实际情况减少该值。
net.ipv4.tcp_keepalive_probes = 3

三、关于内存的内核参数

3.1 内存申请

当内存不足的时候，系统会出现OOM的提示，OOM 即 Out Of Memory，这情况在 java 程序中比较常见。系统会选一个进程将之杀死，在日志中看到类似下面的提示

Jul 10 10:20:30 kernel: Out of memory: Kill process 9527 (java) score 88 or sacrifice child

当 JVM 因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error，因为这个问题已经严重到不足以被应用处理。

原因：

• 给应用分配内存太少：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。
• 应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。

使用的解决办法：

• 限制 java进程的max heap，并且降低 java程序的worker数量，从而降低内存使用

• 给系统增加swap空间

• 设置内核参数 vm.overcommit_memory （虽然不推荐，但也要知道）

Linux默认是允许memory overcommit（内存过度使用）的，只要你来申请内存我就给你，寄希望于进程，实际上用不到那么多内存，但万一用到那么多了呢？Linux设计了一个OOM killer机制挑选一个进程出来杀死，以腾出部分内存，如果还不够就继续。也可通过设置内核参数 vm.panic_on_oom 使得发生OOM时自动重启系统。这都是有风险的机制，重启有可能造成业务中断，杀死进程也有可能导致业务中断。所以Linux 2.6之后允许通过内核参数 vm.overcommit_memory 禁止memory overcommit。

vm.overcommit_memory 接受三种取值:

• 0 – Heuristic overcommit handling. 这是缺省值，它允许overcommit，但过于明目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存。Heuristic的意思是“试探式的”，内核利用某种算法猜测你的内存申请是否合理，它认为不合理就会拒绝overcommit。
• 1 – Always overcommit. 允许overcommit，对内存申请来者不拒。内核执行无内存过量使用处理。使用这个设置会增大内存超载的可能性，但也可以增强大量使用内存任务的性能
• 2 – Don’t overcommit. 禁止overcommit。 内存拒绝等于或者大于总可用 swap 大小以及overcommit_ratio 指定的物理 RAM 比例的内存请求。如果希望减小内存过度使用的风险，这个设置就是最好的。

3.2 释放内存

vm.drop_caches 是一个 Linux 内核参数，用于手动清理操作系统中的页缓存（page cache）、目录项缓存（dentries cache）和索引节点缓存（inodes cache）。通过修改这个参数，可以触发内核对缓存的清理操作，从而释放系统的内存资源。

vm.drop_caches 接受四种取值:

• 0：不清理任何缓存。
• 1：清理页缓存（page cache）。
• 2：清理页缓存和目录项缓存（dentries cache）。
• 3：清理所有缓存。

#清除缓存
echo 3 > /proc/sys/vm/drop_caches

需要注意的是，通过修改 vm.drop_caches 参数手动清理缓存可能会导致一些性能损失，因为清理缓存可能会导致系统需要重新读取数据到内存中，增加了 IO 操作的开销。因此，在使用这个参数时需要谨慎考虑，并且根据实际需求和场景来决定是否进行缓存清理操作。

3.3 Swap分区

物理内存与虚拟内存的概念

• 物理内存就是计算机系统中实际存在的硬件内存，通常是 RAM（随机访问存储器）的形式。它是计算机用于存储和访问数据、指令和程序的物理硬件。
• 虚拟内存是为了满足物理内存不足而提出的策略，它是利用磁盘空间虚拟出的一块虚拟内存区域，被用作虚拟内存的这块磁盘空间我们称之为交换空间（Swap Space）。

虚拟内存的作用：

当运行某个大程序、大游戏，需要的内存超过空闲内存但小于物理内存总量时，会暂时把内存里这些数据放到磁盘上的虚拟内存里，空出物理内存运行游戏。等退出游戏后，又会把虚拟内存里的东西读出来，放回物理内存。所以，虚拟内存并不是用来虚拟物理内存的，而是暂存数据的。如果对内存的需求大于物理内存总量，那虚拟内存设多大都不管用。电脑内存太低，根本的方法还是增加物理内存，才能流畅。虚拟内存机制上就不管用，即使管用，比物理内存低100倍的速度，也管不上什么实际的作用。所以，虚拟内存大了是没用的，反而白占用磁盘空间。

Swap介绍：

Linux将会在适当的时候将物理内存中不经常读写的数据块自动交换到 Swap 交换空间（这个交换的操作是由 Linux 内核来执行的），从而侧面将经常读写的数据保留在了物理内存。说白了就是，它为什么叫交换空间，就是要实现数据的交换（将不常用数据交换到作为虚拟内存的磁盘空间，而保留常用数据在真正的物理内存空间中）。这个交换的策略由 Linux 系统内核定时执行，目的就是为了保持尽可能多的空闲物理内存。

那什么叫做在适当的时候会进行数据交换，我们所说的适当时间其实是 Linux 内核根据“最近最少使用”算法（LRU 算法），定时地将一些不经常使用的页面文件（其实就是文件数据，因为内存是以页面存储数据的）交换到 Swap。

有时候你会发现：Linux 物理内存还有很多，而 Swap 的数据占用却很大，这是什么原因呢？其实，这是正常现象，你想想，如果一个内存占用很大的进程正在运行，必然就会耗费大量的内存资源，此时 Linux 内核就会将一些不常用的页面文件交换到 Swap Space 中，但当后来该内存占用较大的进程终止时，Linux 就会释放该进程占用的大量内存资源，而此时被交换出去的页面文件数据并不会自动又交换到物理内存中来（除非有这个必要），那此时你看到的就是物理内存空间空闲，Swap Space 占用较大的现象了。

这里要明白的是，当程序要读虚拟内存中的某个页面数据时，而恰好这个页面数据位于 Swap Space 中。那此时的流程就是：交换空间（Swap Space）中的数据在被读取时通常会首先被交换到物理内存，然后才能被程序访问。因此，这里又涉及到了两个知识点：

• 页面缺失（Page Fault）

  • 当程序尝试访问一个在物理内存中不存在的内存页时，会触发一个页面缺失。这可能是因为该页已经被交换到了交换空间中，或者是因为程序首次访问该页。在任何情况下，操作系统会注意到页面缺失。

• 页面调度（Page Scheduling）

  • 操作系统负责页面调度，决定哪些页面从交换空间加载到物理内存中以满足程序的需求。通常，操作系统会使用一种页面替换算法（例如LRU - 最近最少使用）来选择哪些页从交换空间中加载，以便最大限度地减少性能开销。一旦数据加载到物理内存中，操作系统会更新进程的页表，以指示这些页面现在位于物理内存中，程序可以访问它们。页表是一个数据结构，用于映射虚拟地址到物理地址。

总结：swap交换分区是系统RAM的补充，swap 分区支持虚拟内存，当内存不足时，用磁盘模拟内存使用，速度很慢。当没有足够的 RAM 保存系统处理的数据时会将数据写入 swap 分区，当系统缺乏 swap 空间时，内核会因 RAM 内存耗尽而终止进程。

配置过多 swap 空间会造成存储设备处于分配状态但闲置，造成浪费，过多 swap 空间还会掩盖内存泄露，所以我们可以通过 vm.swappiness 内核参数来优化。

vm.swappiness 表示当内存占用达到一定的百分比时（100-swappiness ），会启用swap分区的空间，默认值为30，即内存达到了70%，就启用swap分区的空间。

vm.swappiness 还接受 0 和 1 的值

• 当 /proc/sys/vm/swappiness 的值为 0 时，表示系统完全避免使用交换空间，只使用物理内存。这意味着系统将尽可能多地使用物理内存，即使物理内存不足，也不会使用交换空间。这可能会导致性能下降，因为频繁地访问物理内存比访问交换空间要慢得多。

• 当 /proc/sys/vm/swappiness 的值为 1 时，表示系统更倾向于使用交换空间而不是物理内存。这意味着系统在物理内存不足时会使用交换空间，但仍然优先考虑使用物理内存。这种设置可能会提高性能，因为交换空间通常比物理内存更快。然而，如果系统经常需要使用交换空间，那么性能可能会受到影响。

关闭Swap交换分区的优点：

• 提高性能：Swap交换分区通常会在物理内存不足时被使用，这会导致额外的I/O操作和延迟。当系统使用物理内存满足所有应用程序的需求时，关闭Swap交换分区可以避免这种情况的发生，从而提高服务器的性能。

• 减少磁盘使用：Swap交换分区通常占用一部分硬盘空间，关闭Swap交换分区可以减少磁盘使用，从而为其他用途释放空间。

• 减少系统管理复杂性：当系统有Swap交换分区时，需要定期检查Swap交换分区的使用情况，并可能需要调整Swap交换分区的大小。关闭Swap交换分区可以避免这些问题，从而简化系统管理。

关闭Swap交换分区的缺点：

• 内存压力增大：如果系统物理内存不足，关闭Swap交换分区会导致系统无法使用硬盘空间作为额外的内存，这可能导致应用程序崩溃或性能下降。

• 系统不稳定：在极端情况下，如果系统物理内存不足并且没有Swap交换分区可用，可能会导致系统不稳定或无法正常运行。

四、关于IP的内核参数

4.1 TTL

TTL，即生存时间，在IP报文头里占8位，数据报在网络中可通过的路由器数的最大值，TTL 字段是由发送端初始设置一个 8 bit字段。推荐的初始值由分配数字 RFC 指定，当前值为 64。发送 ICMP 回显应答时经常把 TTL 设为最大值 255，当数据包在网络中传输时，每经过一个路由器，TTL值就减1，如果减到0时，数据包仍未到达目的主机，那么这个数据包就会自动被丢弃掉，同时路由器会向最初的发送者发送一个ICMP报文。TTL的主要作用是防止数据包在网络中无限的传输，避免浪费网络流量，通过TTL值，网络可以判定数据包在网络中是否时间过长，过长就被丢弃掉。此外TTL还可以判断目的主机的操作系统类型，不同的操作系统，它的默认TTL值是不同的，Windows的默认TTL值是128。

修改TTL的值

echo 100 > /proc/sys/net/ipv4/ip_default_ttl

较小的 TTL 值会导致数据包更快地在网络中超时并被丢弃，从而减少网络拥塞和提高网络的可靠性。但同时也会增加 ICMP 错误消息的生成和传输负担。因此，在调整 TTL 值时需要谨慎考虑，并根据实际需求和场景来进行权衡和调优。

4.2 其他的内核参数

#路由转发（1为允许）
net.ipv4.ip_forward			

#禁ping（1为禁用）	
net.ipv4.icmp_echo_ignore_all	

#允许应用程序可以监听本地不存在的IP（1为允许）
net.ipv4.ip_nonlocal_bind   	

#禁用IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

五、关于inotify的内核参数

inotify是Linux中的监控服务，监控同步数据服务器目录中信息的变化 ，属于异步的文件系统事件监控机制，利用事件驱动机制，而无须通过诸如cron等的轮询机制来获取事件，linux内核从2.6.13起支持 inotify，通过inotify可以监控文件系统中添加、删除，修改、移动等各种事件。

查看内核是否支持 inotify ，Linux支持inotify的内核最小版本为 2.6.13

#列出下面的文件，说明服务器内核支持inotify
[root@centos8 ~]#ls -l /proc/sys/fs/inotify 
-rw-r--r-- 1 root root 0 Dec  7 10:10 max_queued_events
-rw-r--r-- 1 root root 0 Dec  7 10:10 max_user_instances
-rw-r--r-- 1 root root 0 Dec  6 05:54 max_user_watches

三个内核参数的解释

#inotify事件队列最大长度，如值太小会出现Event Queue Overflow错误，默认16384，生产环境建议调大，比如 27679
fs.inotify.max_queued_events

#每个用户创建inotify实例最大值，默认值128
fs.inotify.max_user_instances

#每个inotify实例可以监视的文件的总数量，（inotifywait 单进程），默认值：8192，建议调大
fs.inotify.max_user_watches

 

六、关于LVS-DR模式的内核参数

LVS-DR：Direct Routing，直接路由，LVS默认模式，应用最广泛，通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变。

LVS-DR模式的工作原理

• 请求报文经过LVS服务器，PREROUTING-->POSTROUTING，响应报文直接从后端发往客户端（不需要开启ip_forward参数）。

• 但是CIP访问的是VIP，结果以RIP来响应，CIP不认，所以它的解决办法就是在每个后端服务器上都有VIP，以VIP来回应，但是在同一个局域网中，同一个IP地址不能配在多台服务器，会造成地址冲突。

• 地址冲突就是因为用户要访问VIP，ARP将VIP解析成MAC地址，发起广播去访问，结果多台服务器上都有VIP，都会去接收请求，说我就是VIP，客户就不知道应该接收哪台服务器的数据报文。

• 然而在DR模式中，后端服务器配VIP的作用是为了以VIP的身份去响应客户端，而不是为了接收客户端的请求，所以为了不造成地址冲突，就要让后端服务器上的VIP不去接收客户端发起的ARP广播请求，简单来说就是让外界不知道后端服务器有VIP，后端服务器自己默默拥有。

• 所以要修改两个内核参数，一个是announce（向外面宣传我存在，即一个网卡新配的IP，生效后会通过免费ARP向外界说明我有新的IP诞，请更新你们的MAC地址和跟我的IP对应关系，实际上就是向外界询问有没有这个IP地址，没有的话我有了，如果已经有就会报地址冲突），一个是ignore（别人发起请求我回应）。

• 前提：VIP必须建立在另一块网卡，不能和RIP在同一块网卡，但是为了配VIP而专门配一个网卡没必要，可以在系统本身自带的 lo（虚拟网卡，也称回环网卡） 配。

所以我们需要将announce参数设为2（不向外界宣传），ignore参数设为1（别人发起请求我不回应）

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

另外还可以思考一个问题，在DR模式中，LVS服务器的eth0网关如果随便配置，会发生什么？答案是即使随便配置，LVS也能调度，但如果不配置，LVS就不能调度了。

原因是LVS服务器收到客户端远程来的数据报文，假设这个数据报文来自192.168.10.123，和LVS不在一个网段，如果不配网关，LVS不具有跨网段通讯能力，所以当收到192的数据报文，发现与自己不在一个网段，通过反向检测发现自己不能回应报文，不能通讯，就会调度失败，随便配，LVS就有网关了，自己就能回应报文了，具有通讯能力，就调度了（LVS觉得自己有通讯能力就转发，没有就不转发）。

所以这里涉及到一个反向检测的内核参数

#反向检测看自身是否有能力跨网段通讯
/proc/sys/net/ipv4/conf/all/rp_filter

当然了，如果你是将LVS单独配置，需要考虑以上的内核参数；如果你是使用了 Keepalived+LVS 的高可用架构，则不需要考虑了，因为 Keepalived 已经内嵌了 LVS 的功能。