在 RHEL7 内核 3.10.0-1062 上运行 Apache 2.4，4 CPU VMWare 实例，使用 WebLogic 代理插件对 WebLogic 后端进行非常基本的反向代理。服务器仅以每秒 1 MByte 的速度推送数百个用户，监听 SSL 并通过 SSL 与 WebLogic 通信。Apache 配置非常简单，只有几行 RewriteRule 或其他典型的性能消耗。VMWare 统计数据显示没有过度使用，但也显示客户机 CPU 利用率为 100%。
从 Linux 的角度来看，服务器的 CPU 利用率达到 100%，运行队列超过 16 个，Apache 占用了所有 CPU 时间。运行“perf record -a -g”一分钟并创建火焰图显示，在 httpd 进程中（每个火焰图使用 97% 的所有 CPU），我们有这些令人惊讶的时间使用情况：
- ktime_get_ts64 -> read_tsc - 所有 CPU 样本的 20.5%，似乎只是运行 rdtsc 指令
- system_call_after_swapgs - 占所有 CPU 样本的 13.24%，似乎指的是相当简洁的代码https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kernel/entry_64.S?h=linux-3.10.y#n625
基本上，除了这两个显著的异常值之外，所有运行时间都花在两个 libc 调用 poll_nocancel 和 read_nocancel 上，这两个调用来自 apache 的监听循环和 WebLogic 插件的传出流量，从而导致了 swapgs 和 readtsc 调用等。
底层硬件似乎没问题，Linux 内核参数似乎没问题，但感觉这台服务器上每秒执行的实际指令非常慢。有没有关于使用“perf”工具进行进一步分析的建议？我无法访问服务器，因此只能建议其他人运行命令。
答案1
你的火焰图是静态格式的，已被裁剪以删除瘦深堆栈：
是的，许多 CPU 上的样本与系统调用有关。许多 poll() 和由此产生的 read_tsc()、一些 read()，显然还有一些系统调用开销，因为时间花在了 system_call_after_swapgs() 上。
现在这变成了寻找性能缺陷和效率低下的问题全部基础设施的各层。以下是一些不完整的建议：
虚拟机管理程序
有关 VMware 上的 TSC，请参阅知识库 65186
错误地检测 TSC 不同步时的性能问题 (65186)
症状 在启动期间，vmkernel 会记录一条消息，其中包含短语“TSC 作为参考计时器被禁用：多个时钟域”或“TSC 作为参考计时器被禁用：发散 NUMA TSC”。
随后，虚拟机在执行 rdtsc 指令时表现出异常糟糕的性能。
原因 在大多数现代 x86 兼容机器上，硬件确保所有逻辑 CPU 的 TSC（时间戳计数器）寄存器在启动时同步，并且除非软件更改，否则始终保持同步，因此 TSC 可以被视为单个全局参考计时器。ESXi 在具有此类同步 TSC 的机器上运行最佳。ESXi 还支持具有不同步 TSC 的机器，但性能会受到很大影响。特别是，如果主机具有不同步的 TSC，则在虚拟机中执行 rdtsc 指令的速度可能会慢 100 倍。
在少数当前机器上，由于对固件提供的某些 ACPI 表字段的解释存在差异，ESXi 会错误地将主机 TSC 检测为不同步。目前，大多数 HPE Superdome 系列机器都受到此问题的影响。
解决方案目前该问题尚无解决方案。
解决方法注意事项：不要将此设置应用于实际上没有同步 TSC 的机器。如果这样做，当 TSC 相差太大时，机器最终会崩溃，并且在崩溃之前可能会出现令人困惑的症状。
如果主机确实具有同步的 TSC，则可以使用以下启动选项强制 vmkernel 使用 TSC 作为全局参考计时器：
esxcli system settings kernel set
--setting=timerForceTSC --value=TRUE
作为强制 TSC 解决方法的替代方案，请考虑在备用虚拟机管理程序上测试主机。例如 KVM、Hyper-V 或裸机。无论如何，缓解此问题应该是显而易见的，因为在 TSC 功能上花费的时间减少了 100 倍。
应用
wl_ssl_conn_recv80% 的时间都在堆栈中。它肯定是一个 WebLogic 函数，因为我在 httpd 源代码中没有找到它。
它所花费的时间最终与 poll() 和 TSC 有关，因此首先检查同步的 TSC 可能会更快。不过，看看调整 WebLogic 性能。
HTTPS 对话
还要分析网络上的协议对话。即 https 的表现如何。尝试数据包捕获和分析，看看响应时间是什么样的。量化连接速率，每秒 30 个与 300 个有很大不同。
也许实现 HTTP/2 会提高效率，但我不知道如何在 WebLogic 中做到这一点。
安全补丁
您的 CPU 时间中很大一部分与系统调用有关。评估您已启用哪些补丁和缓解措施幽灵/崩溃 和骨髓增生异常综合征。已知这些措施在系统调用繁重的工作负载下对性能的影响相对较大。测试各种级别的缓解措施，并根据您的整体安全控制进行风险评估。
容量规划
也许 4 个 CPU 根本不够，至少这个系统目前是这样调校的。用更多实例或更多 CPU 来解决问题可能效率不高，但至少你可以在调整其他东西的同时保持响应速度。