我们正面临着100％CPU利用率的间歇期。
服务器configuration：
HP DL580 G7（4个处理器，每个8个内核; 128GB内存。）
操作系统：Solaris 10_x86更新9
应用程序：Oracle 10 R2; ASM磁盘pipe理。 数据库大小5TB; SGA 78GB
存储子系统：HP MSA2312sa双控制器SAS直连存储
在正常的一天（CPU利用率20％）下面提供了vmstat输出
kthr内存页面磁盘故障cpu
rbw交换免费重新loginfr sr s0 s1 s2 s3在系统我们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％，但是从过去一周以来，我们正在经历100％CPU利用率的短暂突发。
你的虚拟机拥有和主机系统相同数量的处理器吗？ 如果是这样，这是一件坏事，它可以防止调度程序正常工作。 IE如果你有一个8核心系统，那么该盒子上的任何系统都不应该有8个核心分配给它。 你可以有20个虚拟机的4个核心分配，这不是一个问题，但1个8核心分配的盒子可能会导致负载下的问题。
您是否在所有32个CPU内核上都有100％的利用率？ 我不能真正地说出你已经发布的数据，因为这些数据是相当难以理解的，而是试着对你正在经历的事情给出一些一般的答案：
阻塞/掉出过程有时，服务器操作系统上的进程将绑定到特定的CPU核心，只需使用该核心来执行任何操作，而忽略所有其他核心。 对于没有devise成在多核系统中运行的较老的软件，这通常是一个问题。 最终的结果是，如果你有几个进程在这样做，他们决定使用相同的核心，他们将不断阻塞和交换彼此做他们需要做的事情，而你有其他核心闲置不做任何事情。 有时你可以configuration软件来select特定的内核，并手动“平衡”CPU上的进程（类似于当天的手动IRQ设置），但是这显然是不可取的，因为它需要手动重新configuration可能会让事情变得更糟。 找出哪些进程阻塞彼此，并关注这些进程。 我怀疑你有32核心的CPU瓶颈，但我也无法确定。 阅读有关stream程/软件的文档，了解供应商build议的内容，以及是否可以configurationstream程来执行此操作。
被阻塞/被换出的进程比运行进程更高可能发生的情况是，每当进程被阻塞/换出并且没有显示CURRENT被阻止/交换的进程时，你的性能计数器就会正常运行，所以这应该总是高于正在运行的进程（这正是它所说的 – 系统上当前正在运行的进程的数量）。 这不应该是一个问题。
乍看之下，你的系统过去有严重的RAM短缺。 上次启动后的平均扫描速率是117，而在有足够内存的系统上它应该是0或接近它。 这似乎是由你的31 w列确认的，这可能意味着31个守护进程在ram短缺事件中被换出，并且不会再被使用。
你有任何自动化的备份过程或者什么东西会颠簸磁盘？ 这听起来很模糊，就像你有IOwait的问题。 当你的服务器不高兴时，你能得到一个mpstat的快照吗？ 你可以通过在磁盘上进行小的5GB写操作或者在DIRECT_IO模式下来解决磁盘I / O问题（为了解决这个问题，你可以把一半的空间caching在该服务器的可用内存中）。 另外，您是否尝试过（如果可以的话）在此期间检查您的查询？ 也许有人用一堆全索引扫描或其他东西来抨击你？