CentOS6.5网络卡顿延迟高该如何进行内核参数优化？

CentOS 6.5 作为一个经典的操作系统版本，尽管已进入生命周期末期（EOL），但在许多遗留环境中仍在稳定运行，对于承载关键业务的服务器而言，对其进行合理的网络优化，以挖掘其最后潜力，依然具有重要的现实意义，本文旨在系统性地介绍针对 CentOS 6.5 的网络优化策略，涵盖内核参数、网卡配置、系统限制等多个层面，力求为系统管理员提供一份详实、可操作的参考指南。

在进行任何优化操作之前,必须强调：所有更改都应在测试环境中充分验证，并记录原始配置，以便在出现问题时能够快速回滚，优化是一个持续的过程，而非一次性的任务，需要结合业务实际流量和性能监控数据进行动态调整。

内核参数调优

Linux 内核提供了丰富的网络协议栈参数，通过调整这些参数可以显著提升网络性能和并发处理能力，这些参数主要集中在 /etc/sysctl.conf 文件中，修改后，使用 sysctl -p 命令使其立即生效。

以下是一些关键的优化参数及其建议值,适用于高并发连接的场景：

参数	推荐值	说明
net.ipv4.tcp_tw_reuse	1	允许将TIME_WAIT状态的 sockets 重新用于新的TCP连接，对于高并发服务器，能有效减少TIME_WAIT套接字数量。
net.ipv4.tcp_tw_recycle	0	（谨慎使用） 快速回收TIME_WAIT套接字，但在NAT环境下可能导致连接异常，通常建议设为0，依赖tcp_tw_reuse。
net.ipv4.tcp_syncookies	1	开启SYN Cookies功能，当SYN队列溢出时，通过Cookies方式处理SYN请求，有效防范SYN Flood攻击。
net.core.somaxconn	4096	定义了监听队列的最大长度，对于高并发应用（如Nginx、Tomcat），应适当调大此值，避免连接请求被丢弃。
net.ipv4.tcp_max_syn_backlog	8192	记录那些尚未收到客户端确认信息的SYN请求队列的最大长度，与somaxconn配合，提升抗SYN Flood能力。
net.ipv4.tcp_fin_timeout	15	TCP连接在FIN-WAIT-2状态的超时时间，适当减小可以加快资源回收。
net.core.rmem_max	16777216	接收套接字的缓冲区最大值（字节）。
net.core.wmem_max	16777216	发送套接字的缓冲区最大值（字节）。
net.ipv4.tcp_rmem	4096 87380 16777216	TCP接收缓冲区的最小、默认、最大值。
net.ipv4.tcp_wmem	4096 65536 16777216	TCP发送缓冲区的最小、默认、最大值。

操作示例：
将上述参数追加到 /etc/sysctl.conf 文件末尾，然后执行 sysctl -p 即可，增大缓冲区可以提升数据吞吐量，但也会消耗更多内存，需根据服务器实际情况权衡。

网卡队列与中断优化

现代服务器通常配备多核CPU和多队列网卡,合理配置它们可以极大提升网络处理效率。

1. 开启多队列（RSS）：
   多队列网卡可以将网络流量分散到多个硬件接收队列，再由不同的CPU核心处理，避免单一核心成为瓶颈，可以使用 ethtool 命令查看和设置。

   

   # 查看当前网卡队列数
   ethtool -l eth0
   # 设置网卡队列数（设置为CPU核心数）
   ethtool -L eth0 combined 4

   注意：此设置需要网卡驱动支持，且重启后可能失效，需将其写入开机启动脚本。

2. 绑定中断亲和性：
   默认情况下，网卡中断可能由CPU 0处理，导致其负载过高，可以将中断均匀地分配到各个CPU核心。
   查看网卡对应的中断号：

   cat /proc/interrupts | grep eth0

   将中断号（如45）绑定到指定的CPU核心（如CPU 2和3，掩码为1100二进制，即C十六进制）：

   echo C > /proc/irq/45/smp_affinity

   同样,此操作也需要写入脚本以实现开机自动配置。

文件描述符与连接数限制

在高并发场景下,每个TCP连接都会消耗一个文件描述符，CentOS 6.5 默认的 ulimit 值（通常为1024）往往不够用，需要手动调高。

编辑 /etc/security/limits.conf 文件，在末尾添加以下内容：

* soft nofile 65535
* hard nofile 65535

这表示将所有用户的软限制和硬限制都设置为65535,修改后，用户需要重新登录才能生效，可以通过 ulimit -n 命令验证是否设置成功。

其他优化建议

1. DNS解析优化：确保 /etc/resolv.conf 中配置了响应速度快、稳定的DNS服务器，如公共DNS（114.114.114.114或8.8.8.8），可以减少域名解析带来的延迟。
2. 精简防火墙规则：iptables 规则越复杂，数据包处理的延迟就越高，定期审查并优化规则，减少不必要的模块和跳转，可以提升转发效率。
3. 保持系统时间同步：使用 ntpd 服务确保服务器时间准确，这对于日志分析和分布式系统协同至关重要。

---

相关问答 (FAQs)

问题1：为什么我的服务器在按照上述步骤优化后，性能提升并不明显，甚至没有变化？

解答：网络优化是一个系统性工程，瓶颈可能不在网络层面，需要确认服务器的实际瓶颈所在，可以使用 top, vmstat, sar, iftop 等工具进行监控，分析是CPU、内存、磁盘I/O还是应用程序本身的问题，如果应用程序是单线程的，那么多核CPU的优势就无法发挥，如果磁盘I/O已经饱和，那么网络再快也无济于事，优化参数的值并非一成不变，需要根据实际的业务负载（如长连接多还是短连接多）进行针对性调整，优化后没有效果，很可能是因为当前瓶颈并非网络，或者参数调整未触及真正的瓶颈点。

问题2：tcp_tw_recycle 参数在网上看到很多推荐开启，但你的表格里建议设为0，这是为什么？

解答：这是一个非常好的问题，也反映了网络优化的复杂性。tcp_tw_recycle 的设计初衷是快速回收处于TIME_WAIT状态的连接，以释放系统资源，在纯粹的服务器对服务器或客户端对服务器的环境中，开启它确实能带来好处，在存在NAT（网络地址转换）的环境中，开启 tcp_tw_recycle 会引发严重问题，NAT设备会修改来自不同内网主机的连接的源端口，当这些连接到达开启了tcp_tw_recycle的服务器时，服务器可能会因为时间戳校验问题而错误地丢弃来自同一NAT设备后的其他正常连接，导致连接随机失败或超时，现代网络环境几乎处处是NAT（如公司网关、云服务器的浮动IP等），为了系统的稳定性和兼容性，强烈建议将 tcp_tw_recycle 设置为0，转而使用更安全的 tcp_tw_reuse 来复用TIME_WAIT连接。