多个kswapd进程cpu 100%导致系统整体cpu100%

群里接到通知，10:05:02，发现65.15节点cpu使用率达到98.9%，但65.16/17节点cpu资源正常。

65.15节点cpu使用高达98.9%，其中系统使用96.9%，有三个kswapd进程，该进程是系统使用交换分回收管理的。

内核线程kswapd用来处理页面的交换，它可以在内存不足时，将一些进程的页面交换到swap空间之中。

kswapd进程的解释：
a.Linux uses kswapd for virtual memory management such that pages that have been recently accessed are kept in memory

and less active pages are paged out to disk.
b.系统每过一定时间就会唤醒kswapd进程，查看内存资源是否紧张，如果不紧张，则继续睡眠，在kswapd中，有2个阀值,pages_hige和pages_low,

当空闲内存页的数量低于pages_low的时候,kswapd进程就会扫描内存并且每次释放出 32个free pages,直到free page的数量到达pages_high.kswapd

进程导致系统故障的案例为数不少，有些是Bug导致的

网上有大量类似进程导致系统宕机发生。

2.问题处理，10：17群众通知重启15数据库集群，10:25后，显示数据库资源正常，其他连个节点正常，但业务不能正常访问。

集群重启无法达到系统可用目标，因看到是系统交换分区异常，因此考虑重启三个节点主机。

10:33再次重启三个节点，10:45数据库65.15节点起来，业务恢复正常。

3.监控软件信息：另外从智能网管平台监控软件上看到，在今天早上7：40左右内存使用逐渐上升，同时cpu使用率也在逐渐上升，

大约在9：40左右，内存使用率达到70%，这时，cpu有个短暂的下降，swap突然上升，内存使用率达到80%，

cpu达到99.48%，交换分区达到86%。

4.数据库统计报告，统计了10点前一个小时的统计信息

a.有两大量的temp的读写操作，这两类读写官方这样介绍：

说实施这两个等待事件，先说说产生的原理：
1.大量的磁盘排序操作，order by, group by, union, distinct, rollup,max() 无法在PGA中完成排序，
需要利用temp表空间进行排序,当从临时表空间中读取排序结果时，会产生direct path read.
　　2. 大量的Hash Join操作，利用temp表空间保存hash区。
　　3. SQL语句的并行处理
　　4. 大表的全表扫描，在10g开始，全表扫描的算法有新的变化，根据表的大小、高速缓存的大小等信息，决
定是否绕过SGA直接从磁盘读Oracle11g取数据。而10g则是全部通过高速缓存读取数据，称为table scan
(large)。11g认为大表全表时使用直接路径读，可能比10g中的数据文件散列读(db file scattered
reads)速度更快，使用的latch也更少。