☰

CPU 利用率低，但换出进程和阻塞进程较高

tag-icon • tag-icon oracle performance-monitoring solaris-10
CPU 利用率低，但换出进程和阻塞进程较高

我们正面临 CPU 利用率间歇性达到 100% 的情况。

服务器配置：
HP DL580 G7（4 个处理器，每个处理器有 8 个核心；128GB 内存。）
操作系统：Solaris 10_x86 update 9
应用程序：Oracle 10 R2；用于磁盘管理的 ASM。数据库大小 5TB；SGA 78GB
存储子系统：HP MSA2312sa 双控制器 SAS 直接连接存储

在正常情况下（CPU 利用率 20%）状态监测输出如下
kthr 内存 页 磁盘 故障 cpu
rbw 交换免费 re mf pi po fr de sr s0 s1 s2 s3 in sy cs us sy id
0 27 26 128133040 6469184 362 4937 829 3 22 0 117 -0 4 0 97 85888 383138 19238 19 2 79
0 20 31 129089972 4009408 294 4341 28 0 0 0 0 0 2 0 96 144240 363898 27797 12 5 82
1 17 31 128869152 3731692 243 4437 0 0 0 0 0 0 6 0 88 142738 385237 26503 10 5 84
1 21 31 128803936 3665112 283 5545 111 0 0 0 0 0 3 0 102 157962 347356 26940 12 5 82
2 20 31 128556548 3515596 274 10806 0 0 0 0 0 0 6 0 99 253881 391554 34754 13 7 80

流程摘要：
运行队列进程 - 0~2 阻塞进程 - 17~27 交换进程 - 31
CPU 利用率摘要：
用户- 10%~20% 系统- 2%~7% 空闲- 79%~85%

造成这种不正常的 CPU 行为的原因是什么？
为什么阻塞进程 (b) 和换出进程 (w) 比正在运行的进程 (r) 高得多？
我们是在查看 CPU 瓶颈、内存瓶颈还是 IO 瓶颈？

我们确实运行 Oracle RMAN 备份，但备份每天凌晨 4 点完成。

而在正常工作时间（上午 10 点到下午 6 点）内 CPU 利用率会飙升至 100%，但在此期间不会运行任何后台备份。

至于大型查询，我们确实会运行相当长且复杂的查询。这些查询每天都会运行，CPU 利用率几乎不超过 40%，但从过去一周开始，我们经历了 CPU 利用率短时间达到 100% 的突发情况。

答案1

您的虚拟机是否拥有与主机系统相同数量的处理器？如果是，这是一件坏事，并且会阻止调度程序正常工作。例如，如果您有一个 8 核系统，那么该机箱上的任何系统都不应分配 8 个核心。您可以拥有 20 个分配了 4 个核心的虚拟机，这不是问题，但 1 个分配了 8 个核心的机箱在负载下可能会引起问题。

答案2

您是否遇到了 32 个 CPU 核心或只有几个核心的 100% 利用率？我无法真正谈论您发布的统计数据，因为它们相当难以阅读，但我会尝试针对您所遇到的问题给出一些一般性答案：

阻塞/交换进程 有时，服务器操作系统上的进程会绑定到特定的 CPU 核心，并且只使用该核心执行其需要执行的操作，而忽略所有其他核心。这通常是旧软件的问题，因为这些软件并非设计用于在多核系统中运行。最终结果是，如果您有几个进程在执行此操作，并且它们决定使用同一个核心，那么它们将不断相互阻塞并交换以执行它们需要执行的操作，而其他核心则处于空闲状态，不执行任何操作。有时，您可以配置软件以选择特定核心并手动“负载平衡”各个 CPU 之间的进程（类似于过去的手动 IRQ 设置），但这显然是不可取的，因为它需要您手动重新配置，最终可能会使情况变得更糟。找出哪些进程相互阻塞并专注于这些进程。我怀疑 32 个核心的 CPU 瓶颈，但我也不能确定。阅读有关进程/软件的文档，了解供应商的建议，以及您是否甚至可以配置进程来执行此操作。

阻塞/换出进程高于正在运行的进程 可能发生的情况是，每次进程被阻止/交换出时，性能计数器都会滴答作响，并且不会显示当前被阻止/交换的进程，因此该计数器应该始终高于正在运行的进程（顾名思义 - 系统上当前正在运行的进程数）。这不应该成为问题。

答案3

乍一看，您的系统过去曾严重缺乏 RAM。自上次启动以来的平均扫描率为 117，而在具有足够 RAM 的系统中，该值应为 0 或接近 0。您的 31 w 列似乎证实了这一点，这可能意味着在 RAM 短缺事件期间有 31 个守护进程被换出，并且再也没有被闲置。

答案4

您是否有任何自动备份过程或会破坏磁盘的东西？听起来您似乎遇到了 IOwait 问题。当服务器不正常时，您可以获取 mpstat 的快照吗？您可能可以通过在 DIRECT_IO 模式下对磁盘执行 5GB 的小写入或执行其他操作来排除磁盘 i/o 问题（以解决您可以在该服务器上的可用内存中缓存地球一半的事实）。此外，您是否尝试过（如果可以的话）在此期间检查您的查询？也许有人用一堆全索引扫描之类的东西来打击您？

相关内容