F5 BIG-IP系统的CPU

2020-07-07 21:38:01

欧阳晨曦

F5 BIG-IP系统的CPU

Drew Li

大家好，今天我们来聊一聊BIG-IP的CPU，之后还会给大家分享一个关于CPU问题处理的用户实例，供大家参考。

相信大家在日常维护BIG-IP系统时会经常遇到CPU状态异常的问题，在这里我们主要介绍一下BIG-IP系统涉及到的关于CPU的一些知识，以便帮助大家在遇到CPU占用异常这类问题时，能够给大家问题处理带来更多的思路。

首先我们来回顾下与BIG-IP CPU相关的一些知识。

查询BIG-IP linux host的逻辑核，物理核，以及每个物理CPU的core

1.查询系统逻辑(processor)CPU个数：

# cat /proc/cpuinfo | grep 'processor' | wc -l

2.查询物理CPU个数：

# cat /proc/cpuinfo | grep 'physical id' | sort | uniq | wc -l

3.每个物理CPU中Core的个数：

# cat /proc/cpuinfo | grep 'cpu cores' | wc -l

4.位于相同物理封装的处理器(physical id)中的逻辑处理器的数:

# cat /proc/cpuinfo | grep ' siblings ' | wc -l

以一台3900为例，分别查询3900逻辑CPU个数、物理CPU个数、core的个数以及位于相同物理封装的处理器中逻辑处理器的数量。

从上边的输出中我们可以看到3900有1个物理封装的CPU、逻辑CPU是4个、1个物CPU上有4个core、1个物理封装内有逻辑处理器是4个。

5.利用如下命令查看平台所有CPU数据

# cat /proc/cpuinfo

TMM的CPU使用率(K15468: Overview of BIG-IP TMM CPU usage)

由于TMM进程会直接参与流量处理，所以在这里需要花一点篇幅介绍下TMM的CPU使用率。例如，可以使用如下命令查看TMM的CPU使用情况（以Viprion 2100板卡为例）

# tmsh show /sys tmm-info

从图中我们能够清晰的看到每5秒、1分钟、5分钟的TMM的CPU的使用情况。

在查询TMM的CPU使用率的时候，大家可能注意到了，执行# tmsh show /sys tmm-info后，为什么我们只能看到偶数核的TMM的CPU使用情况，却看不到奇数核TMM的CPU使用情况？

想搞清楚这个问题那么我们就要从BIG-IP 11.5.0开始引入的奇偶数核，控制平面、数据平面任务分离的特性(HTsplit)讲起。

BIG IP系统使用Intel超线程技术CPU时，数据和控制平面任务被不同的逻辑核执行

在11.5.0版本之前，使用英特尔超线程技术（HT技术）物理CPU的系统上，每个支持HT技术的逻辑核，同时处理数据平面（TMM任务平面）和控制平面（非TMM任务，MCPD、Java等）的任务。所以如果要让数据平面任务（TMM）与控制平面任务共享一个逻辑核，需要TMOS在TMM和控制平面任务之间执行上下文切换。这种上下文切换，会显著影响系统性能，此外，控制平面和数据任务也可能相互阻塞。

因此BIG-IP 11.5.0之后，BIG-IP对数据平面和控制平面任务进行了拆分（K15003: Data and control plane tasks use separate logical cores when the BIG-IP system CPU uses Intel Hyper-Threading Technology），在使用HT技术的CPU上，数据和控制平面任务分离（HTsplit），数据平面任务和控制平面任务使用不同的逻辑核分别处理不同任务。数据平面、偶数核CPU处理TMM进程，即使在TMM所在偶数核CPU满载状态下，所有其他进程（非TMM进程）在控制平面逻辑核上继续执行任务。

那么奇数核的core就不能处理流量了嘛？

答案当然是否定的，偶数核超线程（0、2、4等）专用于TMM处理流量，作为数据平面任务的高优先级进程。奇数核超线程（1、3、5等）以正常优先级处理控制平面任务。

但是，当TMM利用率达到80%，奇数核超线程后会限制控制平面任务，只保留20%的CPU容量，允许TMM使用剩余80%奇数核CPU资源。如果上述情况发生，在/var/log/kern.log 会有类似的log:

info kernel: ltm driver: Idle enforcer starting - tid: <pid> cpu: 1/1

info kernel: ltm driver: Idle enforcer exiting - tid: <pid> cpu: 1

判断硬件平台是否支持HT技术

参考K14358: Overview of Clustered Multiprocessing (11.3.0 and later)，查看相关硬件平台是否支持HT技术。

或者通过如下命令# tmsh show sys tmm-info | grep Sys::TMM (K23505424: Overview of the HTSplit feature)，从输出结果查看硬件平台是否支持HT技术。

通过命令查看，BIG-IP 6900不支持HT技术，而Viprion 2100支持HT技术。

SSL TPS（K6475: Overview of SSL TPS licensing limits）

在11.5.0之后版本，由于引入了奇偶数核，数据、控制平面任务处理分离特性（HTsplit）,那么设备SSL TPS limits怎么计算呢？

以一台2000设备为例，如果在软硬件平台支持HTsplit特性的前提下，通过如下命令查询TMM的SSL TPS：

#tmsh show sys license detail | grep -i

perf_SSL_total_TPSperf_SSL_total_TPS [500]

查询TMM数量：

#tmsh show sys tmm-info global | grep -i 'TMM count'

TMM Count 2

那么，该设备能够处理的SSL TPS为(2+2)*500=2K TPS

对于没有License控制的SSL transaction TPS数量的设备，需要查询设备的datasheet确定硬件设备所支持的SSL transaction TPS。

例如这台3900

需要注意Viprion和其他单框设备在计算SSL transaction TPS数量时的区别，

在Viprion上执行

#tmsh show sys license detail | grep -i

命令输出为每块板卡支持的SSL transaction TPS，所以Viprion设备整框SSL transaction TPS=(#tmsh show sys license detail | grep -i perf_SSL_total_TPS)* Blade。

CPU问题处理用户实例

下面将结合一个具体case来，应用下刚刚讲到的这些的知识点。下图取自一台BIG-IP 2000。

下面我们来一起分析下导致CPU异常增高的原因。

1.确定客户所使用的LTM版本，客户使用版本是BIG-IP LTM 14.1.2，该版本支持CPU超线程（HT技术）。

2.确认硬件平台是否支持HTSplit特性(K23505424: Overview of the HTSplit feature)

# tmsh show sys tmm-info | grep Sys::TMM(客户是一台2000设备)

Sys::TMM: 0.0

Sys::TMM: 0.2

输出结果只看到了偶数核TMM，所以该平台支持HTSplit。

3.确认客户软件db是否开启支持HTsplit特性

# tmsh list sys db scheduler.splitplanes.ltm

sys db scheduler.splitplanes.ltm {

value "true"

}

返回值“true”，所以客户版本支持HTsplit。

4.观察性能统计发现奇数核CPU1/CPU3以及偶数核CPU0/CPU2的CPU使用率趋近于100%。

5.再来查看该设备的SSL transaction TPS的License限制

# tmsh show sys license detail | grep -i perf_SSL_total_TPS

perf_SSL_total_TPS [500]

TMM Count 2

# tmsh show sys tmm-info global | grep -i 'TMM count'

那么，该2000设备所有TMM能够处理的SSL TPS为(2+2)*500=2K TPS

6.观察SSL Transactions性能统计，图中显示大部分时间SSL请求数量没有达到系统硬件支持的最大SSL Transaction TPS。由于性能统计取的是系统平均值，所以不能确定系统的SSL Transactions TPS是否超限。

7.继续查看问题发生时间点的var/log/ltm、var/log/kern日志

var/log/ltm：

Jun 12 13:12:07 err tmm1[10745]: 01260008:3: SSL transaction (TPS) rate limit reached

从该日志分析得到发生问题时间点TMM1的SSL transaction TPS达到了处理上限。

var/log/kern：

Jun 12 13:12:10 info kernel: : [19823538.874163] ltm driver: Idle enforcer exiting - tid: 5526 cpu: 1

Jun 12 13:12:10 info kernel: ltm driver: Idle enforcer exiting - tid: 5526 cpu: 1

Jun 12 13:12:10 kernel: : [19823538.945344] ltm driver: Idle enforcer starting - tid: 5527 cpu: 3/3

Jun 12 13:12:10 info kernel: ltm driver: Idle enforcer starting - tid: 5527 cpu: 3/3

从该日志分析得到发生问题时间点偶数核CPU超线程，奇数核CPU协助处理TMM流量。

8.case分析结论

综合以上7点，可以得出以下结论，

1).虽然该设备的的吞吐量，新建连接数等均没有达到硬件设计容量，但是，从var/log/ltm日志中我们可以看到，SSL transaction TPS已经达到或者超过了TMM的SSL TPS处理上限。

2).SSL transaction TPS的超限后，TMM繁忙直接体现在了偶数核CPU使用率达到或者超过80%（统计中看已经基本达到了100%），从var/log/kern日志我们能看到TMM偶数核CPU使用率超过80%后，偶数核CPU超线程，奇数核CPU开始处理TMM流量，由于客户SSL transaction TPS并发请求太大，最终导致奇数核CPU使用率也趋近于100%。

9.建议

因为客户的2000设备上，部署了超过100个SSL业务的Virtual Server，客户端大部分访问请求都是通过VS的443端口（HTTPS）转发到后端服务器，因此客户设备的SSL业务TPS请求数量会很高，当前TMM超线程后，虽然能够处理现有SSL高并发请求，但是设备已经出现了控制平面进程阻塞情况，基于此客户需要及时更换支持高SSL transaction并发请求的设备，以便减少偶数核TMM超线程发生，保证设备最佳运行状态。