随着业务容器化的推进，经常有客户抱怨应用 QPS 无法和在物理机或者云主机上媲美，并且时常会出现 DNS 查询超时、短连接 TIME_OUT、网络丢包等问题，而在容器中进行调优与诊断的效果因为安装工具的复杂度大打折扣。本文基于网易轻舟中间件业务容器化实践，总结容器场景下的性能调优心得，供读者参考。

性能调优的“望闻问切”

在讨论容器化场景的性能调优之前，先谈一下性能调优中的“望闻问切”。对于性能问题，大部分人首先想到的是 CPU 利用率高，但这只是个现象，并不是症状。打个比方：感冒看医生时，病人跟大夫描述的是现象，包括头部发热、流鼻涕等；而大夫通过探查、化验，得到的医学症状是病人的白细胞较多、咽喉红肿等，并确诊为细菌性感冒，给开了 999 感冒灵。性能调优流程与此相似，也需要找到现象、症状和解法。回到 CPU 利用率高的例子：已知现象是 CPU 利用率高，我们通过 strace 检查，发现 futex_wait 系统调用占用了 80% 的 CPU 时间——这才是症状；根据这个症状，我们业务逻辑代码降低了线程切换，CPU 利用率随之降低。

大部分的性能调优都可以通过发现现象、探测症状、解决问题这三个步骤来完成，而这在容器的性能调优中就更为重要的，因为在主机的性能调优过程中，我们有很多的经验可以快速找到症状，但是在容器的场景中，很多客户只能描述问题的现象，因为他们并不了解使用的容器引擎的工作原理以及容器化架构的实现方式。

容器化性能调优的难点

容器化场景中的性能调优主要面临 7 个方面的挑战。

中间件种类多，调优方法又各不相同，如何设计一种好的框架来适配

我们借鉴 redhat tuned 思想，提出一种与业务相关的内核参数配置新框架，它可以把我们对 Linux 系统现有的一些调优手段（包括电源管理工具，CPU、内存、磁盘、网络等内核参数）整合到一个具体的策略 (profile) 中，业务场景不同，profile 不同，以此来快速实现云计算对不同业务进行系统的性能调节的需求。

VM 级别的调优方式在容器中实现难度较大

在 VM 级别我们看到的即是所有，网络栈是完整暴露的，CPU、内存、磁盘等也是完全没有限制的。性能调优老司机的工具箱安个遍，诊断流程走一趟基本问题就查个八九不离十了，但是在容器中，很多时候，都是默认不自带诊断、调优工具的，很多时候连 ping 或者 telnet 等基础命令都没有，这导致大部分情况下我们需要以黑盒的方式看待一个容器，所有的症状只能从物理机或者云主机的链路来看。但是我们知道容器通过 namespace 的隔离，具备完整网络栈，CPU、内存等通过隔离，只能使用 limit 的资源，如果将容器当做黑盒会导致很多时候问题症状难以快速发现，排查问题变难了。

容器化后应用的链路变长导致排查问题成本变大

容器的场景带来很多酷炫的功能和技术，比如故障自动恢复、弹性伸缩、跨主机调度等，但是这一切的代价是需要依赖容器化的架构，比如 Kubernetes 网络中需要 FullNat 的方式完成两层网络的转发等，这会给排查问题带来更复杂的障碍，当你不清楚编排引擎的架构实现原理的时候，很难将问题指向这些平时不会遇到的场景。例如上面这个例子中，FullNat 的好处是降低了网络整体方案的复杂性，但是也引入了一些 NAT 场景下的常见问题，比如短连接场景中的 SNAT 五元组重合导致包重传的问题等等，排查问题的方位变大了。

不完整隔离带来的调优复杂性

容器本质是一种操作系统级虚拟化技术，不可避免涉及隔离性，虽然平时并不需要考虑隔离的安全性问题，但是当遇到性能调优的时候，内核的共享使我们不得不面对一个更复杂的场景。举个例子，由于内核的共享，系统的 proc 是以只读的方式进行挂载的，这就意味着系统内核参数的调整会带来的宿主机级别的变更。在性能调优领域经常有人提到 C10K 或者 C100K 等类似的问题，这些问题难免涉及到内核参数的调整，但是越特定的场景调优的参数越不同，有时会有“彼之蜜糖，我之毒药”的效果。因此同一个节点上的不同容器会出现非常离奇的现象。

不同语言对 cgroup 的支持

这个问题在大多数场景下无需考虑，列在第四位是期望能够引起大家重视。网易轻舟在一次排查“ES 容器（使用 java 11）将 CPU requests 都配置成 8 时，其性能低于将 request CPU 都配置成 1”的问题时，发现是 Java 的标准库中对 cgroup 的支持不完全导致的，好在这点在大多数场景中没有任何影响。

网络方案不同带来的特定场景的先天缺欠

提到容器架构避不开网络、存储和调度，网络是评判容器架构好坏的一个核心标准，不同的网络方案也会有不同的实现方式与问题。比如网易轻舟 Kubernetes 中使用了 Flannel 的 CNI 插件实现的网络方案，标准 Flannel 支持的 Vxlan 的网络方案，Docker 的 Overlay 的 macVlan，ipvlan 的方案，或者 OpenShift SDN 网路方案，还有网易轻舟自研的云内普通 VPC 和 SRIOV+VPC 方案等等。这些不同的网络方案无一例外都是跨宿主机的二层网络很多都会通过一些 vxlan 封包解包的方式来进行数据传输，这种方式难免会增加额外的 CPU 损耗，这是一种先天的缺欠，并不是调优能够解决的问题。有的时候排查出问题也只能绕过而不是调优。

镜像化的系统环境、语言版本的差异

应用容器化是一个需要特别注意的问题，很多公司并没有严格的配管流程，比如系统依赖的内核版本、语言的小版本等等，很多时候都是选择一个大概的版本，这会带来很多语言层级的 BUG，比如 Java 应用程序运行在容器中可能会遇到更长的应用程序暂停问题、Java 7 无法感知 CPU 个数导致 GC 线程过多问题和 PHP7.0 中 php-fpm 的诡异行为。环境的问题本就需要严格管控，但是当遇到了容器，很多时候我们会分不清哪些不经意的行为会带来严重的问题，警惕性因为容器镜像能够正常启动而降低了。

性能优化步骤和调优管理变更流程

性能优化通常可以通过如表五个步骤完成：

调优管理变更和性能优化并不直接相关，但可能是性能调优成功最重要的因素。以下总结来源于网易轻舟团队的实践和经验：

在调优之前，实施合理的调优管理流程变更
永远不要在生产系统上调优
压测的环境要相对独立，不能受其他压力的影响，这里说的不仅是压测的服务器端，而且包括压测客户端
在调优过程中，每次只修改一个变量
反复测试提升性能的参数，有时候，统计来的结果更加可靠
把成功的参数调整整理成文档，和社区分享，即使你觉得它们微不足道
生产环境中获得的任何结果对 Linux 性能都有很大用处

调优手段

通用调优对于容器业务来说，尽量让 CPU 访问本地内存，不要访问远端内存。

CPU 访问不同类型节点内存的速度是不相同的，访问本地节点的速度最快，访问远端节点的速度最慢，即访问速度与节点的距离有关，距离越远访问速度越慢，此距离称作 Node Distance。正是因为有这个特点，容器应用程序要尽量的减少不同 Node 模块之间的交互，也就是说，我们根据容器内存 Node 亲和性，选择容器使用的 CPU 固定在一个 Node 模块里，因此其性能将会有很大的提升。有一种特殊场景除外，如果一个容器申请的 request 大于单个 Node 上预留的 CPU 后，这种亲和性的绑定就会失效，此时回归到原始的跨 Node 范围绑定，对于之前已经做了亲和性的容器（申请的 request 小于单个 Node 上预留的 CPU）我们的策略是继续维持不变。

针对不同的场景的参数调优针对不同的场景，可以考虑以下参数着手进行调优。

与 CPU 相关的配置

cpu相关的参数	说明
force_latency	如果为1的话，表示强制把cstate置为c0
governor=performance	表示开启intel睿频技术
energy_perf_bias=performance	通过x86_energy_perf_policy工具允许管理员定义相关性能和能效，分为三种：1. performance:默认设置，不会考虑节省能源2. normal:潜在到能耗节省，容忍部分性能妥协。3. powersave:接收严重性能降级，最大能效。
min_perf_pct	如果设置为100的话，其含义是尽量让CPU跑在P0就是Turbo的最高频率，对于CPU，有一个标称频率（Base Freqency)。比如某台服务器的CPU的Base Freqency是3.0GHz，也就是在普通状态下，BIOS关闭Turbo开关的话，CPU的最高频率不会超过3.0GHz。Pn指的是硬件上的最低频率，P1是Base Frequency。在这范围的频率就是P1，P2，P3…Pn，后面的数字越小，就说明频率越高。那么P1以上的频率就称为Turbo频率，P0就是Turbo的最高频率。Turbo就是我们所说的超频，就是超出标称频率。
kernel.sched_min_granularity_ns	表示进程最少运行时间，为了防止任务频繁的切换，可以设置得较大些。
kernel.sched_migration_cost_ns	其值越大表示task更不容易被迁走，该变量用来判断一个进程是否还是hot，如果进程的运行时间（now - p->se.exec_start）小于它，那么内核认为它的code还在cache里，所以该进程还是hot，那么在迁移的时候就不会考虑它。
sysctl_sched_wakeup_granularity	该变量表示进程被唤醒后至少应该运行的时间的基数，它只是用来判断某个进程是否应该抢占当前进程，并不代表它能够执行的最小时间（sysctl_sched_min_granularity），如果这个数值越小，那么发生抢占的概率也就越高（见wakeup_gran、wakeup_preempt_entity函数）

与内存相关的配置

内存相关的参数	说明
transparent_hugepages（默认值是madvise）	设置为never表示关闭透明大页
vm.dirty_ratio	表示当系统脏页到达内存X%，强制同步WriteBack(WB)，如果脏页越多，WB会变慢，响应就会变慢，所以响应要快的话，此值可以设置得较小些。
vm.dirty_background_ratio	当系统脏页到达内存X%，强制异步WB，在低水位的时候就刷的话，刷的就相对越快，所以响应要快的话，此值可以设置得较小些。

磁盘相关的参数

磁盘相关的参数

说明

readahead（一般默认值是256）

Linux的文件预读readahead，指Linux系统内核将指定文件的某区域预读进页缓存起来，便于接下来对该区域进行读取时，不会因缺页（page fault）而阻塞。因为从内存读取比从磁盘读取要快很多。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，所以业务是磁盘密集型的，此值可以设置得较大些。

与 sysctl 相关的配置

sysctl参数	说明
net.core.busy_read net.core.busy_poll	这两个参数默认都是0，它表示是繁忙轮询，有助于减少网络接收路径中的延迟，使socket层代码查询网络设备的接收队列并禁用网络中断，这可以消除由于中断和由此产生的环境切换所造成的延误。但是，它会增加CPU的使用率。繁忙轮询可以防止CPU进入睡眠状态，睡眠状态会造成额外的功耗。
net.ipv4.tcp_fastopen	tcp_fastopen（TFO）提高性能的关键是省去了热请求的三次握手，适用于对小包的应用场景进行调优
vm.max_map_count kernel.pid_max kernel.threads-max	这三个参数可以用于调节os支持的最大线程数量
fs.inotify.max_queued_events fs.inotify.max_user_instances fs.inotify.max_user_watches	max_queued_events表示调用inotify_init时分配给inotify instance中可排队的event的数目的最大值，超出这个值的事件被丢弃，但会触发IN_Q_OVERFLOW事件;max_user_instances表示每一个real user ID可创建的inotify instatnces的数量上限，默认128;max_user_watches表示同一用户同时可以添加的watch数目（watch一般是针对目录，决定了同时同一用户可以监控的目录数量）.调大这三个参数是为了解决“当运行docker镜像时，报Error: ENOSPC: System limit for number of file watchers reached”问题
net.core.somaxconn	定义了系统中每一个端口最大的监听队列的长度
net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_tcp_be_liberal net.netfilter.nf_conntrack_checksum options nf_conntrack hashsize配合使用	调大netfilter ct参数，防止连接数过多，导致“nf_conntrack: table full, dropping packet on…”问题
net.ipv4.ip_forward	开启数据包转发的功能，所谓转发即当主机拥有多于一块的网卡时，其中一块收到数据包，根据数据包的目的ip地址将数据包发往本机另一块网卡，该网卡根据路由表继续发送数据包
net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-arptables net.bridge.bridge-nf-call-ip6tables	这三个参数置为1表示二层的网桥在转发包时也会被iptables/arptables/ip6tables的FORWARD规则所过滤
net.core.netdev_max_backlog	默认是1000，在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目
net.core.netdev_budget	默认是300，net_rx_action budget表示一个CPU单次轮询（poll）所允许的最大收包数量，如果在内核缓存层面发现有丢包的话，可以调整net.core.netdev_max_backlog和net.core.netdev_budget这两个参数
net.ipv4.neigh.default.gc_thresh1 net.ipv4.neigh.default.gc_thresh2 net.ipv4.neigh.default.gc_thresh3	这三个参数是为了解决“neighbour table overflow”问题
net.ipv4.conf.eth0.arp_ignore	1表示只响应目的IP地址为接收网卡上的本地地址的arp请求
net.ipv4.tcp_rmem=“P1 P2 P3”	第一个值是为socket接收缓冲区分配的最少字节数；第二个值是默认值（该值会被rmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数（该值会被rmem_max覆盖）。
net.ipv4.tcp_wmem=“P1 P2 P3”	第一个值是为socket发送缓冲区分配的最少字节数；第二个值是默认值（该值会被wmem_default覆盖），缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数（该值会被wmem_max覆盖）。
net.ipv4.udp_mem=“P1 P2 P3”	UDP的情况，含义同上