cpu瓶頸 top的核心sy佔用較高

反應伺服器的應用連線較慢，由於應用和資料庫在同一臺伺服器上。先從os上top檢視下

[oracle@server115 ~]$ top -c

top - 11:58:28 up 31 days, 1:53, 5 users, load average: 1.55, 1.51, 1.51

Tasks: 247 total, 1 running, 226 sleeping, 1 stopped, 19 zombie

Cpu(s): 0.1%us, 25.2%sy, 0.0%ni, 71.5%id, 3.2%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 32935076k total, 31446084k used, 1488992k free, 261712k buffers

Swap: 33547688k total, 48112k used, 33499576k free, 27773788k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

8459 root 18 0 6394m 1.2g 13m S 99.9 3.9 2:45.50 /usr/java/j2sdk/bin/java -Dwebapp=cobra.tomcat -Dfile.encoding=GBK -Xmx6000m -Xms2048m -Djava.endorsed.dirs

8566 oracle 15 0 12736 1196 812 R 0.7 0.0 0:01.03 top -c

3544 root 34 19 0 0 0 S 0.3 0.0 210:59.33 [kipmi0]

5202 oracle 15 0 16.1g 1.1g 1.1g S 0.3 3.4 0:36.75 oraclebenguo (LOCAL=NO)

6662 oracle 15 0 16.1g 183m 179m S 0.3 0.6 2:10.65 oraclebenguo (LOCAL=NO)

1 root 15 0 10344 596 556 S 0.0 0.0 5:09.37 init [5]

關注系統的sy核心執行教程較多，而IO等待佔用的cpu並不是很多，檢視下資料庫的等待事件。

SQL> select event,count(*) from v$session group by event;

EVENT COUNT(*)

---------------------------------------------------------------- ----------

SQL*Net message from client 57

control file parallel write 1

db file sequential read 2

jobq slave wait 1

rdbms ipc message 8

smon timer 1

pmon timer 1

Streams AQ: qmn slave idle wait 1

SQL*Net message to client 3

Streams AQ: waiting for time management or cleanup tasks 1

Streams AQ: qmn coordinator idle wait 1

觀察發現資料庫壓力還是很小的，根據sy佔用較多，以前只碰過一個ckpt未完成和大量session fts造成的sy佔用較高，由於應用和資料庫都在同一個伺服器上，可能是系統的負載太大，cpu存在瓶頸，檢視下cpu的配置。

[oracle@server115 ~]$ cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU E5502 @ 1.87GHz

stepping : 5

cpu MHz : 1862.000

cache size : 4096 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 2

apicid : 0

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm

bogomips : 3736.48

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management:

processor : 1

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU E5502 @ 1.87GHz

stepping : 5

cpu MHz : 1596.000

cache size : 4096 KB

physical id : 0

siblings : 2

core id : 2

cpu cores : 2

apicid : 4

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm

bogomips : 3733.39

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management:

processor : 2

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU E5502 @ 1.87GHz

stepping : 5

cpu MHz : 1596.000

cache size : 4096 KB

physical id : 1

siblings : 2

core id : 0

cpu cores : 2

apicid : 16

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm

bogomips : 3733.64

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management:

processor : 3

vendor_id : GenuineIntel

cpu family : 6

model : 26

model name : Intel(R) Xeon(R) CPU E5502 @ 1.87GHz

stepping : 5

cpu MHz : 1862.000

cache size : 4096 KB

physical id : 1

siblings : 2

core id : 2

cpu cores : 2

apicid : 20

fpu : yes

fpu_exception : yes

cpuid level : 11

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr popcnt lahf_lm

bogomips : 3733.43

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management:

根據sy佔用較多，檢視cpu配置後的一點分析：

[oracle@server115 ~]$ cat /proc/cpuinfo |grep 'physical id' sort|uniq

physical id : 0

physical id : 1

[oracle@server115 ~]$ cat /proc/cpuinfo |grep 'cpu cores'|sort|uniq

cpu cores : 2

物理的cpu只有2顆而已，每顆cpu有雙核，透過cpu cores能看出，而檢視siblings也就是每顆cpu的邏輯處理單位也是2，說明每顆每核的cpu只是單執行緒的，並不是超執行緒的（每顆每核cpu可以完成兩個邏輯處理的是超執行緒）。而且cpu是E5502 的1.87GHz！

這個配置有點out了！

那麼整個cpu processes也只是4個，對於上面跑的一個tomcat和oracle的資料庫是完全不夠用的，那麼這個案例也就分析明白了，cpu出現瓶頸導致系統負載較高！

採取的措施要不對硬體做相應的提升，要不分離應用和資料庫到不同的伺服器上，或者做個rac來對系統負載均衡，不過rac在這種情況下不一定是最明智的，由於直接遷移tomcat應用是最簡單的！

[@more@]