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@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25362835/viewspace-1058853/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25362835/viewspace-1058853/