阿里云centos服务器长期cpu100%,无法通过top、ps等命

我长期遭受CPU使用率100%的问题，最终发现挖矿木马是罪魁祸首。
木马被删除后，出现了新的模式，问题依然存在。
经调查，该问题是由挖矿木马引起的。
使用Centos7系统时，重启后CPU使用率突然上升到100%，但使用top、atop、htop命令找不到具体进程。
netstat命令显示该进程使用IP地址192.168.1.209，该地址指向矿池地址。
对系统目录的检查显示/lib/udev/rules.c目录中的一个目录，其创建时间与病毒攻击的时间相匹配。
该目录包含四个文件：md、mdx、re和y。
。
进一步分析发现，md文件是挖矿程序，y文件是启动注入程序。
y文件内容显示，该程序执行了清除历史记录、更改系统路径、添加预加载库、运行挖矿程序md等一系列操作，形成了一个连续的挖矿循环。
该程序尝试通过多个池地址进行挖掘。
病毒将挖矿相关文件复制到/usr/local/lib/目录下，并修改/etc/ld.so.preload文件，使程序在启动时自动加载。
最终通过运行特定命令删除病毒文件、恢复系统权限、使用iptables阻止网络连接、杀掉病毒进程等方式解决了该问题。
通过这次经验我们可以得出结论，对于此类病毒，关键是准确识别病毒文件，清理添加的预加载库，使系统恢复正常运行状态即可。
与此同时，必须持续监控系统，以防止病毒再次引入。

阿里云服务器CPU跑满怎么办

您的网站可能遭到攻击，例如DDoS/CC攻击，从而消耗您的服务器资源。
解决方案是购买阿里云高防IP和防火墙。
然而阿里云的价格极其昂贵。
建议您使用百度云加速。
百度云加速是百度推出的一款为网站提供一站式加速、安全防护、搜索引擎优化的产品。
百度云加速是市场占有率最高的云加速产品之一，为近百万个网站、数十万用户提供CDN、网络安全和SEO服务。
每天处理数十亿级光伏流量和数百亿TB数据流量，并提供市场领先的稳定性和抗攻击能力。
百度云加速以部署在骨干网上的数据中心为支撑，结合百度的深度学习技术，为您的网站提供性能和流量优化，并与开发者一起为打造开放、安全的云服务生态系统而努力。
我们希望更多的网站合作伙伴和中小企业能够受益于百度云加速带来的价值和红利，让云生态能够更加健康地发展。
百度云加速为用户提供以下三类功能：1、网站加速节点遍布全国，通过智能DNS解析等技术，为访问网站的用户提供动态并通过静态加速和页面优化技术引导，显着提升网站访问速度和用户体验。
此外，还可以节省网站大量的服务计算和带宽资源。
2、安全防护百度云加速可以同时防护SQL注入、各种DDoS攻击的CC等十余种黑客渗透攻击。
3、SEO的百度蜘蛛DNS同步功能百度云加速可以实时同步DNS信息，通过百度蜘蛛的正常抓取和死链接及站点地图收集网站信息，保证搜索引擎权重的稳定；及时增加网站索引。

阿里云cpu检测进程mysql太高怎么解决

一台服务器解决Mysqlcpu占用100%的问题。
我稍微整理了一下，把我的经验记录在这篇文章中。
最近朋友主机（Windows2003+IIS+PHP+MYSQL）上MySQL服务进程（mysqld-nt.exe）的CPU使用率一直是100%。
该主机大约有10个数据库，分别被10个网站调用。
据朋友测试，mysqld-nt.execpu使用率极高的原因是A网站，一旦在IIS中停止该网站，CPU使用率就会下降。
一旦激活，它就会立即上升。
解决进程MYSQLCPU占用100%今天早上仔细检查了一下。
目前该网站7天日均IP为2000，浏览量约为3万。
A网站使用的数据库目前有39张表，601000条记录，占用45MB空间。
根据这个数据来看，MySQL不可能占用这么高的资源。
于是在服务器上运行命令，将mysql当前的环境变量输出到文件output.txt中：d:\web\mysql>mysqld.exe--help>output.txt发现tmp_table_size的值为默认的32M，所以我修改了My.ini，将tmp_table_size赋值为200M：d:\web\mysql>notepadc:\windows\my.ini[mysqld]tmp_table_size=200M然后重启MySQL服务。
CPU使用率略有下降。
之前的CPU使用率波形在100%时是一条直线，但现在在97%到100%之间波动。
由此可见，调整tmp_table_size参数可以提高MYSQL的性能。
但问题还没有完全解决。
于是进入mysqlshell命令行，调用showprocesslist，查看mysql当前常用的SQL语句：mysql>showprocesslist;反复调用该命令，发现A网站的两条SQL语句经常在processlist中出现，其语法如下：SELECTt1.pid,t2.userid,t3.count,t1.dateFROM_mydataASt1LEFTJOIN_myuserASt3ONt1.userid=t3.useridLEFTJOIN_mydata_bodyASt2ONt1.pid=t3.pidORDERBYt1.pidLIMIT0,15调用showcolumns查看这三个表的结构：mysql>showcolumnsfrom_myuser;mysql>showcolumnsfrom_mydata;mysql>showcolumnsfrom_mydata_body;我终于发现了问题：_mydata表只根据pid创建了primarykey，而没有为userid创建索引。
该SQL语句的第一个LEFTJOINON子句中：LEFTJOIN_myuserASt3ONt1.userid=t3.userid_mydata的userid参与条件比较操作。
所以我根据字段userid为_mydata表创建了一个索引：mysql>ALTERTABLE`_mydata`ADDINDEX(`userid`)。
创建这个索引后，CPU立即下降到80%左右。
看到问题找到了，又检查了showprocesslist中重复出现的另一条SQL语句：SELECTCOUNT(*)FROM_mydataASt1,_mydata_keyASt2WHEREt1.pid=t2.pidandt2.keywords='Peacock'检查了_mydata_key表的结构后发现了只为pid创建了主键，没有为关键字创建索引。
_mydata_key目前有330,000条记录。
奇怪的是，在没有索引的情况下对33万条记录进行文本检索和匹配并没有消耗大量的CPU时间。
看来这个表的检索有问题。
所以我们还根据字段关键字给_mydata_key表添加了索引：mysql>ALTERTABLE`_mydata_key`ADDINDEX(`keywords`)创建这个索引后，CPU立即下降，在50%到70%之间波动。
当再次调用showprosslist时，A网站的sql调用很少出现在结果列表中。
但发现该主机运行了多个Discuz论坛程序，并且Discuz论坛中的多个表也存在此问题。
于是我们一下子解决了，CPU占用率又下降了。
（2007.07.09注：关于discuz论坛的具体优化过程，我后来又写了一篇文章，详细内容参见：数千万记录的Discuz！注意事项优化论坛导致MySQLCPU100%http://www.xiaohui。
com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm)解决MYSQLCPU占用100%的经验总结。
增加tmp_table_size值。
在mysql配置文件中，tmp_table_size默认大小为32M。
如果临时表超过此大小，MySQL会生成Thetabletbl_nameisfull形式的错误。
如果执行许多高级GROUPBY查询，请增加tmp_table_size值。
这是mysql对此选项的官方解释：tmp_table_size该变量确定内存中临时表的最大大小。
如果表变得太大，则会在磁盘上创建MYISAM表。
尽可能通过优化查询来避免临时表，但在不可能的情况下可以，尝试确保临时表始终存储在内存中。
查看需要很长时间才能解决的临时表查询的进程列表可以为您提供tmp_table_size需要升级的早期警告。
请注意，内存也是按线程分配的。
举个例子，该功能的升级适用于更多情况，其中我将其从32MB（默认值）升级到64MB，并立即生效。
更快的解决方案查询的解决方案可以减少任何时候处于活动状态的线程，从而为服务器和可用内存带来全面的好处。
对于WHERE、JOIN、MAX()、MIN()、ORDERBY等子句中条件判断所使用的字段，应根据它们建立索引INDEX。
索引用于快速查找列上具有特定值的行。
如果没有索引，MySQL必须从第一条记录开始，然后读取整个表，直到找到相关行。
表越大，花费的时间就越多。
如果表在查询列上有索引，MySQL可以快速到达搜索数据文件中间的位置，而不必考虑所有数据。
如果一个表有1000行，这至少比顺序读取快100倍。
所有MySQL索引（PRIMARY、UNIQUE和INDEX）都存储在B树中。
根据MySQL开发文档：Index索引用于：快速查找与WHERE子句匹配的行执行联接（JOIN）时从其他表中检索行。
查找特定索引列的MAX()或MIN()值如果对可用键的最左侧前缀（例如ORDERBYkey_part_1、key_part_2）执行排序或分组，则对表进行排序或分组。
如果所有密钥部分都遵循DESC，则按相反顺序读取密钥。
在某些情况下，可以优化查询以检索值，而无需查阅数据文件。
如果某些表的所有使用的列都是数字并且构成某些键的最左边的前缀，则可以从索引树中检索这些值以获得更快的性能。
假设您发出以下SELECT语句：mysql>SELECT*FROMtbl_nameWHEREcol1=val1ANDcol2=val2;如果col1和col2上存在多列索引，则可以直接获取相应的行。
如果col1和col2上存在单独的单列索引，优化器会尝试通过确定哪个索引将找到更少的行并使用该索引获取行来找到限制性更强的索引。
开发人员在设计SQL数据表时，必须仔细考虑一切。