译者｜池建强

撰稿｜成敏

晚安，这里是卖益虫说。

那时给大家所推荐一则该文，源自倪朋飞同学的时评《Linux 操控性强化两栖作战》，该文主要讲的是强化操控性的拳法，这几乎是每一后端开发人员都会碰到的绊脚石，热烈欢迎收看。

晚安，我是倪朋飞。

首先先来思索一下操控性难题预测的通常关键步骤。

他们能从计算天然资源困局和插件困局，这三个视角来预测操控性难题的根本原因。

从计算天然资源困局的视角来说，USE 法是最有效的方式，即从使用量、反射率和严重错误数这三个方面，来预测 CPU、缓存、硬盘和文件控制系统 I/O、互联网和Mach天然资源管制等各种类型硬件天然资源。再者那些天然资源的预测方式，我也带你一起简述了，咱时评后面几大组件的分析拳法。

天然资源困局的预测路子，跟计算天然资源困局是那样的。倚赖服务项目的困局，能使用全信道追踪控制系统，展开加速功能定位。而应用领域另一方面的难题，则能通过控制系统初始化、领涨板块表达式，或者应用领域另一方面的分项和笔记等，展开预测功能定位。

当然，虽然控制系统和应用领域是三个相同的视角，但在实际运转时，它们常常相得益彰、此消彼长。

控制系统是应用领域的运转环境，控制系统困局会导致应用领域的操控性下降。而插件片面的结构设计，也会引起计算天然资源的困局。

他们做操控性预测，就是要紧密结合插件和操作控制系统的基本原理，戳破引起难题的“凶手“。

了大半，因为那些困局为他们详述了强化的路径。不过，对于操控性强化来说，又有什么样常用的方式呢？

那时，我就带你一起来看一看，操控性强化的通常方式。同上四节的操控性预测那样，他们也能从控制系统和插件，这三个相同的视角来展开操控性强化。

控制系统强化

首先来看控制系统的强化。在上四节，我曾经介绍过，USE 法能用来预测控制系统硬件天然资源的困局，那么，相对应的强化方式，当然也是从那些天然资源困局入手。

实际上，咱时评的前四个组件，除了最核心的计算天然资源困局预测之外，也已经包含了那些常用天然资源困局的强化方式。

接下来，我就从 CPU 操控性、缓存操控性、硬盘和文件控制系统 I/O 操控性和互联网操控性等四个方面，带你简述一下它们的强化方式。

CPU 强化

首先来看 CPU 操控性的强化方式。在CPU 操控性强化的几个路子中，我曾经介绍过，CPU 操控性强化的核心，在于排除所有不必要的工作、充分利用 CPU 缓存并减少进程调度对操控性的影响。

从这几个方面出发，我相信你已经想到了很多的强化方式。这里，我主要强调一下，最典型的三种强化方式。

第一种，把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的此消彼长。第二种，为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，能充分利用多 CPU 的优势分摊负载。第三种，使用 Cgroups 等方式，为进程设置天然资源管制，避免个别进程消耗过多的 CPU。同时，为核心应用领域程序设置更高的优先级，减少低优先级任务的影响。

缓存强化

说完了 CPU 的操控性强化，他们再来看一看，怎么强化缓存的操控性。在如何“快准狠”找到控制系统缓存的难题中，我曾经为你梳理了常用的一些缓存难题，比如可用内存不足、缓存泄漏、Swap 过多、缺页异常过多和缓存过多等等。所以，说白了，缓存操控性的强化，也就是要解决那些缓存使用的难题。

在我看来，你能通过以下几种方式，来强化缓存的操控性。

第一种，除非有必要，Swap 应该禁止掉。这样就能避免 Swap 的额外 I/O ，带来缓存访问变慢的难题。第二种，使用 Cgroups 等方式，为进程设置缓存管制。这样就能避免个别进程消耗过多缓存，而影响了其他进程。对于核心应用领域，还应该降低 oom_score，避免被 OOM 杀死。第三种，使用大页、缓存池等方式，减少缓存的动态分配，从而减少缺页异常。

硬盘和文件控制系统 I/O 强化

接下来，他们再来看第三类计算天然资源，即硬盘和文件控制系统 I/O 的强化方式。在硬盘 I/O 操控性强化的几个路子中，我已经为你梳理了一些常用的强化路子，这其中有三种最典型的方式。

第一种，也是最简单的方式，通过 SSD 替代 HDD、或者使用 RAID 等方式，提升 I/O 操控性。第二种，针对硬盘和插件 I/O 模式的特征，选择最适合的 I/O 调度算法。比如，SSD 和虚拟机中的硬盘，通常用的是 noop 调度算法；而数据库应用领域，更所推荐使用 deadline 算法。第三种，强化文件控制系统和硬盘的缓存、缓冲区，比如强化脏页的刷新频率、脏页限额，和Mach回收目录项缓存和索引节点缓存的倾向等等。

除此之外，使用相同硬盘隔离相同应用领域的数据、强化文件控制系统的配置选项、强化硬盘预读、增大硬盘队列长度等，也都是常用的强化路子。

互联网强化

最后一个是互联网的操控性强化。在互联网操控性强化的几个路子中，我也已经为你梳理了一些常用的强化路子。那些强化方式都是从 Linux 的互联网协议栈出发，针对每一协议层的工作基本原理展开强化。这里，我同样强调一下，最典型的几种互联网强化方式。

首先，从Mach天然资源和互联网协议的视角来说，他们能对Mach选项展开强化，比如：

你能增大套接字缓冲区、连接追踪表、最大半连接数、最大文件描述符数、本地端口范围等Mach天然资源配额；也能减少 TIMEOUT 超时时间、SYN+ACK 重传数、Keepalive 探测时间等异常处理参数；还能开启端口复用、反向地址校验，并调整 MTU 大小等降低Mach的负担。

那些都是Mach选项强化的最常用措施。

其次，从互联网接口的视角来说，他们能考虑对互联网接口的功能展开强化，比如：

你能将原来 CPU 上执行的工作，卸载到网卡中执行，即开启网卡的 GRO、GSO、RSS、VXLAN 等卸载功能；也能开启互联网接口的多队列功能，这样，每一队列就能用相同的中断号，调度到相同 CPU 上执行；还能增大互联网接口的缓冲区大小和队列长度等，提升互联网传输的吞吐量。

最后，在极限操控性情况（比如 C10M）下，Mach的互联网协议栈可能是最主要的操控性困局，所以，通常会考虑绕过Mach协议栈。

你能使用 DPDK 技术，跳过Mach协议栈，直接由用户态进程用轮询的方式，来处理互联网请求。同时，再紧密结合大页、CPU 绑定、缓存对齐、流水线并发等多种机制，强化互联网包的处理效率。你还能使用Mach自带的 XDP 技术，在互联网包进入Mach协议栈前，就对其展开处理。这样，也能达到目的，获得很好的操控性。

插件强化

说完了控制系统硬件天然资源的强化，接下来，他们再来看一看插件的强化路子。

虽然控制系统的硬件天然资源，是保证插件正常运转的基础，但你要知道，性能强化的最佳位置，还是插件内部。为什么这么说呢？我简单举三个例子你就明白了。

第一个例子，是控制系统 CPU 使用量（sys%）过高的难题。有时候出现难题，虽然表面现象是控制系统 CPU 使用量过高，但待你预测过后，很可能会发现，插件的片面控制系统初始化才是罪魁祸首。这种情况下，强化插件内部控制系统初始化的逻辑，显然要比强化Mach要简单也有用得多。

再比如说，数据库的 CPU 使用量高、I/O 响应慢，也是最常用的一种操控性难题。这种难题，通常来说，并不是因为数据库本身操控性不好，而是插件片面的表结构或者 SQL 查询语句导致的。这时候，强化插件中数据库表结构的逻辑或者 SQL 语句，显然要比强化数据库本身，能带来更大的收益。

所以，在观察操控性分项时，你应该先查看插件的响应时间、吞吐量和严重错误率等分项，因为它们才是操控性强化要解决的终极难题。以终为始，从那些视角出发，你一定能想到很多强化方式，而我比较所推荐下面几种方式。

第一，从 CPU 使用的视角来说，简化代码、强化算法、异步处理和编译器强化等，都是常用的降低 CPU 使用量的方式，这样能利用有限的 CPU 处理更多的请求。第二，从数据访问的视角来说，使用缓存、写时复制、增加 I/O 尺寸等，都是常用的减少硬盘 I/O 的方式，这样能获得更快的数据处理速度。第三，从缓存管理的视角来说，使用大页、缓存池等方式，能预先分配缓存，减少内存的动态分配，从而更好地缓存访问操控性。第四，从互联网的视角来说，使用 I/O 多路复用、长连接代替短连接、DNS 缓存等方式，能强化互联网 I/O 并减少互联网请求数，从而减少互联网延时带来的操控性难题。第五，从进程的工作模型来说，异步处理、多线程或多进程等，能充分利用每一个 CPU 的处理能力，从而提高插件的吞吐能力。

除此之外，你还能使用消息队列、CDN、负载均衡等各种方式，来强化插件的架构，将原来单机要承担的任务，调度到多台服务项目器中并行处理。这样也常常能获得更好的整体操控性。