Oracle CPU高的问题及分析，
目录
- 一、CPU高分析
- 1.CPU负载分析
- 2.数据写入进程分析
- 3.日志分析
- 4.连接分析
- 5.日志产生量分析
- 6.日志切换分析
- 7.业务高峰日志分析
- 8.SQL分析
- 9.内存分析
- 二、总结与优化建议
- 1.CPU使用情况
- 2.优化建议
- 三、该节点MySQL内存分析
- 总结
一、CPU高分析
1.CPU负载分析
CPU总体使用率：最高时12%。Cpu(s):12%us. 当前是：Cpu(s):8.4%us。
这个值在70%以下，都是合理的。%CPU列是单个CPU核占用的CPU百分比。
当前系统24核，48CPU。CPU%列的所有值累计不超过4800*70%=3360.
当前是：96.5+53.1+44.8+44.5+39.9+37.2+29+26+19.4+11
我们计算出来的值是：8.3625%，与图中CPU的总体使用 Cpu(s):8.4%us相吻合。
由此可知，当前CPU总体使用率8.4%,小于CPU的瓶颈值Cpu(s):70%us.所以即使有单个CPU占用100%，我们认为是正常的，当SQL正在运行时会出现CPU%列100%的情形。
2.数据写入进程分析
当前数据库有6个数据写入进程，并发向数据文件写入数据。这6个进程对应操作系统6个oracle进程。
再加上一个日志写入进程，还有其他的用户进程，就会出现多个进程占用CPU较高的现象。
3.日志分析
由上图可以看到，日志文件大小100M过小，日志只有三个组，1s内有6次切换，日志切换非常频繁，需要增加日志文件的大小，同时增加日志的组数。
一般建议的日志每10~15分钟切换一次较为合理，且最大大小一般不超过4G。日志切换也需要消耗一定的资源，影响数据库的性能，建议先将日志文件增加到至少5组，每组大小设置为1G。
同时可以由归档情况可以推测，在夜晚跑批时：400M/每秒 的日志产生量。
4.连接分析
由该图可以看到日志写入进程只有一个。
由进程数可推断同时在线有309人,或者中间件连接池设置为300左右。
中间件连接池一个连接对应于操作系统后台一个LOCAL=NO的连接。
5.日志产生量分析
由上图可以知道白天业务时间，大约 300KB/s 的日志产生量。日志缓冲区(log_buffer)的大小是60M。
6.日志切换分析
晚上数据库跑批时，产生的日志量是：361M/s
7.业务高峰日志分析
晚上数据库跑批时，产生的日志量是：361M/s ,日志缓冲区会频繁刷盘,由于日志缓冲区1/3满就会刷入到磁盘，由此可见夜晚跑批时，每秒刷盘：360M/(60*1/3)=360/20=18次。
日志缓冲区存在的目的就是为了减少刷入磁盘的次数，写入较多的日志时，一次刷入。内存写入效率高，磁盘写入效率低。要减少刷盘的次数，可以适当增加日志缓冲区的大小。
当前日志缓冲区60M,可以调整为254M。
8.SQL分析
上图是今天9:30-9:45分数据库AWR报告抓取情况。由图可以知道，SQL运行正常，无慢SQL。
9.内存分析
由图可以，内核参数中设置的共享内存段的值是：37.7G。缓存中剩余内存26G。交换内存使用9.2G。一旦使用交换内存SWAP分区较多，则认为内存遇到瓶颈，我们认为系统内存不足。可适当增加内存。
由于系统内存不足，当需要内存用于计算时会将部分缓冲的内容移动到SWAP分区，从SWAP分区中访问或者重新交换到内存，这样明显降低系统运行效率。访问SWAP分区，相当于访问磁盘，效率极低。
二、总结与优化建议
1.CPU使用情况
CPU使用率合理。
2.优化建议
2.1如果条件允许可以将内存换成128G的。
2.2日志文件和日志缓冲区的大小可以设当调整。
日志文件建议：5-10组，每组1G，日志缓冲区设置为：254M。
建议先修改日志文件大小和组数，观察性能是否有大的提升。如果有较大提升则不改日志缓冲区。如果性能提升较小，再适当调整日志缓冲区大小，再观察性能是否提升。
三、该节点MySQL内存分析
innodb_buffer_pool_size=21474836480=20G . Total large memory allocated 21988638720 =20G . Dictionary memory allocated 47611400=45M . Buffer pool size 1310720=页的总数，合计：20G。 Free buffers 1023=Free列表页的数量=16M Database pages 1282153==19.56G=LRU列表页的数量 Old database pages 473275=7.2G -------------- ROW OPERATIONS -------------- 0 queries inside InnoDB, 0 queries in queue 0 read views open inside InnoDB Process ID=22709, Main thread ID=139831373981440, state: sleeping Number of rows inserted 1437766525, updated 39527145, deleted 503811945, read 372358523033 0.00 inserts/s, 0.11 updates/s, 0.00 deletes/s, 19263.64 reads/s
当前MySQL数据库innodb存储引擎的情况。缓冲池设置为20G，数据库的缓存也差不多有20G左右，缓冲池充分缓存了热点数据。
且由最下方的行操作可知mysql数据库作为CDP 平台的元数据库，读多写少。每秒有接近2W行数据的读取。
当前数据库有360个左右的连接，且几乎处于休眠状态。MySQL内存占用的20G，不影响Oracle数据库的内存。
Oracle使用的内存由内核参数：kernel.shmmax=39G(不到40G)和oracle SGA 共同决定。Oracle和MySQL共同瓜分了操作系统的内存，整体上内存不足。但是不影响MySQL。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持PHP之友。
您可能感兴趣的文章:- [Oracle] CPU/PSU补丁安装详细教程
- [Oracle] Data Guard CPU/PSU补丁安装详细教程
- 如何查询占CPU高的oracle进程
- Oracle捕获问题SQL解决CPU过渡消耗
- 用Oracle并行查询发挥多CPU的威力