AIX emxp_xcr 进程cpu 开销过大导致db 很慢

topas现象:

#powermt version

5.5

FYI:

http://www.aixchina.net/club/thread-97079-1-1.html

这个进程是EMC POWERPATH的一个加密进程,出现占用CPU过高的情况,根治的方法是升级版本,但需要重启分区。。。。。

临时解决办法:

1.     Halt the currently running process with kill -9 <pid no. >

2.     To prevent the emcp_xcryptd daemon from coming back up on a reboot,before the next reboot.

Edit the file /etc/PowerPathExtensions which contains these lines:

mpxext:cfgmpx

gpxext

dmext:cfgdm

vlumdext:cfgvlumd

xcryptext:cfgxcrypt

Remove the last two lines, save the file.

****NOTE**** Do NOT comment out the lines with #. The last two lines must be removed entirely.  Using # to comment out the lines will
cause PowerPath to not configure devices on reboot.

3.     Remove the following line from /etc/inittab and save the file:

rcxcrypt:2:wait:/etc/rc.emcp_xcryptd xcrypt_rc >/dev/null 2>&1

时间: 2024-08-11 05:32:45

AIX emxp_xcr 进程cpu 开销过大导致db 很慢的相关文章

SqlServer查看表、存储过程、耗时查询、当前进程、开销较大的语句

--查看数据库中表的语句 SELECT s2.dbid , DB_NAME(s2.dbid) AS [数据库名] , --s1.sql_handle , ( SELECT TOP 1 SUBSTRING(s2.text, statement_start_offset / 2 + 1, ( ( CASE WHEN statement_end_offset = -1 THEN ( LEN(CONVERT(NVARCHAR(MAX), s2.text)) * 2 ) ELSE statement_en

SQLServer数据库之SqlServer查看表、存储过程、耗时查询、当前进程、开销较大的语句

--查看数据库中表的语句 SELECT s2.dbid , DB_NAME(s2.dbid) AS [数据库名] , --s1.sql_handle , ( SELECT TOP 1 SUBSTRING(s2.text, statement_start_offset / 2 + 1, ( ( CASE WHEN statement_end_offset = -1 THEN ( LEN(CONVERT(NVARCHAR(MAX), s2.text)) * 2 ) ELSE statement_en

偶遇 smon 进程cpu 开销高异常分析

今天突然发现线上一台oracle 数据库 服务器cpu 跑的很高,感觉不是很正常,仔细看了下:发现是smon 进程吃掉了一个cpu. 那么这个smon 进程到底在倒腾啥玩意 对smon 进程开启10046 跟下不就全明了了么 分析trace 文件就这么一个sql语句 ,这玩意在删smon_scn_time delete from smon_scn_time where thread=0 and scn =  (select min(scn) from smon_scn_time where th

MySQL服务器SWAP使用率高导致db很慢很卡

环境介绍: CentOS:6.X MySQL版本:5.5.40 故障原因分析: 物理内存是16G,swap是4G.此时MySQL本身已经占用了14G物理内存,而同时其他应用程序或者系统进程又需要3G内存,这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去,有可能产生swap的操作事件: 产生的主要原因: 1.mysqldump以及mysql import很大的库或者表: 2.数据库层大批量的并发操作的io writer和io read操作: 3.在OS层copy一个大文件,

利用SQL Profiler处理开销较大的查询

原文:利用SQL Profiler处理开销较大的查询 当SQL Server的性能变差时,最可能发生的是以下两件事: 首先,某些查询产生了系统资源上很大的压力.这些查询影响整个系统的性能,因为服务器无法足够快速地服务其他SQL查询. 另外,开销较大的查询阻塞了其他请求相同数据库资源的查询,进一步降低了这些查询的性能.优化开销较大的查询不仅改进它们本身的性能,而且减少数据库阻塞和SQL Server资源压力从而提高了其他查询的性能. 识别开销较大的查询 SQL Server的目标是在最短时间内将结

[MSSQL]服务器端压力过大导致SSMS异常

登陆SSMS时: 编辑表时: 查看事件无重大异常,查看内存接近98%,360提示进程97%. 会不会以为服务器压力过大导致的? 待MSSQL空闲期间,重启测试.结果重启之后正常.

Linux下java进程CPU占用率高分析方法

Linux下java进程CPU占用率高分析方法 在工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况.这种情况发生时,我们怎么去找出原因并解决. 一般解决方法是通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用 1. 通过top命令找到可疑进程PID top - 09:37:18 up 70 days, 16:29, 2 users, load average: 1.13, 1.04, 0.97 Tasks: 105 total, 1 running

java进程CPU高分析

https://blog.csdn.net/moranzi1/article/details/89341480 JVM导致系统CPU高的常见场景内存不足,JVM gc频繁,一般会伴随OOMJVM某个线程死循环或者递归调用 定位和解决1.内存不足,gc频繁可参考我的这遍文章解决.https://blog.csdn.net/moranzi1/article/details/886702042.JVM某个线程死循环或者递归调用.这种情况关键是找到导致CPU高的线程.然后根据具体线程具体分析为什么该线程

Android中获取CPU负载和进程cpu时间

android系统中有一个ProcessStats类,我们可以使用它来获取系统的负载情况及进程时间. 实现原理是读取/proc目录下的.linux系统运行时,内核会去更新 /proc目录下的文件,将PID的运行情况写入相应的文件中.我们主要关注以下文件 1. /proc/stat 该文件包含了从系统启动开始累积到当前时刻的CPU活动信息. 看下我手机的情况,如下 cat /proc/stat cpu  14869 5121 19794 156065 3114 0 26 0 0 0 cpu0 10