Show Table of Contents
第 6 章 网络
网络子系统由很多敏感连接的不同部分构成。红帽企业版 Linux 7 网络因此旨在为大多数工作负载提供最佳性能,并且自动优化其性能。因此,不需要时常手动调节网络性能。本章探讨了可以对功能网络系统做的进一步优化。
网络性能问题有时是硬件故障或基础结构层故障造成的。解决这些问题超出了本文的范畴。
6.1. 注意事项
要决定调优,用户需要对红帽企业版 Linux 包的接收有充分的认识。本章节解释了如何接收和处理网络数据包,以及潜在瓶颈会出现的地方。
发送至红帽企业版 Linux 系统的数据包是由 NIC(网络接口卡)接收的,数据包置于内核硬件缓冲区或是循环缓冲区中。NIC 之后会发送一个硬件中断请求,促使生成一个软件中断操作来处理该中断请求。
作为软件中断操作的一部分,数据包会由缓冲区转移到网络堆栈。根据数据包及用户的网络配置,数据包之后会被转发、删除或转移到一个应用程序的 socket接收队列,并将从网络堆栈中删除。这一进程会持续进行,直到 NIC 硬件缓冲区中没有数据包或一定数量的数据包(在
/proc/sys/net/core/dev_weight 中指定)被转移。
6.1.1. 调节前
网络性能问题最常见的是由硬件故障或基础结构层故障造成的。红帽极力推荐在开始调节网络堆栈前核实硬件及基础结构层是否在按预期运行。
6.1.2. 数据包接收瓶颈
虽然网络堆栈基本上是自我优化的,但是在网络堆栈处理过程中有很多导致瓶颈且降低性能的问题。
- NIC 硬件缓冲区或循环缓冲区
- 如果大量的数据包被弃置,硬件缓冲区就会成为瓶颈。要监控系统传送的数据包,请见 <第 6.2.4 节 “ethtool”>。
- 硬件或软件中断队列
- 中断会增加延迟,争用处理器。处理器如何处理中断,请见 <第 3.1.3 节 “中断请求管理”>。如何监控系统中断处理,请见 <第 3.2.3 节 “/proc/ 中断”>。影响中断处理的配置选项,请见 <第 3.3.7 节 “设置中断关联”>。
- 应用程序的 socket接收队列
- 应用程序接收队列的瓶颈是大量的数据包没有复制到请求应用程序中,或是 UDP 输入错误(
InErrors)增加,此错误在/proc/net/snmp中。监控系统中的这些错误,请见 <第 6.2.1 节 “ss”> 和 <第 6.2.5 节 “/proc/net/snmp”>。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.