flash占用CPU过高问题（QQ农场等）

Posted 2023-05-01

一直使用的好好的，突然有一天开始，只要开flash类的就很占cpu及内存。以为是电脑本身问题，各方面查看后都没问题。因为实在受不了这样就重装了系统。重装后立刻开了qq农场等，都没有问题。但是一天后，又变成原样了。到底怎么解决才行？

 如果因为flash版本过低，或者其它flash的问题，导致网页加载不正常，网页视频不能看等情况的话
你可以使用电脑管家的电脑诊所来一键修复一下

附：手动修复步骤（来源：腾讯电脑管家电脑诊所，自动修复请点击上方的【立即修复】）

方案一：安装或升级flash
打开【电脑管家】→点击【软件管理】，在搜索框中输入"flash"→找到相应版本点击【安装】或【升级】（如果以安装请点击下箭头后选择修复，如此步骤无法成功修复，可继续执行第二步骤再进行此步骤)

2. 打开文件夹C:\\Windows\\System32\\Macromed\\Flash 将名为"Flash32_版本号.ocx" 文件删除(如果无法删除请右键文件点击【属性】→【安全】→【高级】→【更改权限】→将前两项拒绝权限删除后点击【确定】后，再将QQ、腾讯电脑管家、浏览器关闭后即可删除文件)：

方案二：注册IE组件
点击【开始】菜单→在搜索框中输入"cmd"→按键盘enter(回车)键：

在弹出的黑色窗口中，按顺序输入以下内容，按键盘enter(回车)键，再逐一完成以下全部部件注册：

　　regsvr32 atl.dll
　　regsvr32 shdocvw.dll
　　regsvr32 urlmon.dll
　　regsvr32 browseui.dll
　　regsvr32 oleaut32.dll
　　regsvr32 shell32.dll
　　regsvr32 jscript.dll
　　regsvr32 vbscript.dll
　　regsvr32 mshtmled.dll
　　regsvr32 CLBCATQ.DLL
　　regsvr32 cscui.dll
　　regsvr32 MLANG.dll
　　regsvr32 stobject.dll
　　regsvr32 WINHTTP.dll
　　regsvr32 msxml3.dll
　　regsvr32 query.dll
　　regsvr32 jscript9.dll
　　regsvr32 hlink.dll

如果以上诉步骤未能生效，再进入后续步骤：
方案三：重置IE
（说明：如果您使用网络代理或者对浏览器有特殊设置，请保存设置后再进行操作）
打开IE浏览器 → 点击【工具】→【Internet 选项】
点击【高级】→点击【重置】→勾选【删除个性化设置】→点击【确定】→【确定】：

方案四：安装其他浏览器后设置其他浏览器为默认浏览器
打开电脑管家→点击【软件管理】，在搜索框中输入"谷歌浏览器"→找到软件后点击安装
打开电脑管家→点击【工具箱】，点击【默认程序设置】→在上网浏览器列表中选择【谷歌浏览器】→点击【确认】：

注：腾讯电脑管家为Flash版本过低问题定制部分修复步骤，因为操作过于繁杂，故未全部列出。若问题仍未解决，建议点击本回答上侧的【立即修复】按钮，进行深度修复。

本回答如有不清楚或其他疑问，请继续追问
谢谢！

参考技术A 我在多个地段使用双核，2.6GHZ或者3.0GHZ的CPU、4GB的内存，主流独立显卡的电脑玩QQ农场也是很卡，不是网速问题，测试也很正常，进入QQ空间也很快，但是一进入QQ农场CPU占用率直线上升到80%左右，这个配置即使玩英雄联盟也不卡，但是玩QQ农场就不行了。这是普遍现象，不知道是QQ服务器问题还是农场过于复杂所以占用CPU。而且进入农场有时很快有时很慢，说明了农场的设计技术存在问题。最近同时开4个农场就难以收菜了，因为农场现在越搞越复杂，花样太多，大量占用内存和CPU。 参考技术B 你不开qq农场cpu温度正常吗，如果是仅仅开qq农场温度过高，你可以打开你的任务管理器，看看是不是ie的cpu占用率很高，如果是说明你的ie加载flash插件可能有本回答被提问者采纳 参考技术C 换个CPU吧，flash吃CPU是相当正常的 参考技术D 你试试flash10.3版本。

MySQL CPU占用过高怎么办

通过以前对mysql的操作经验，先将mysql的配置问题排除了，查看msyql是否运行正常，通过查看mysql data目录里面的*.err文件(将扩展名改为.txt)记事本查看即可。如果过大不建议用记事本了，容易死掉，可以用editplus等工具。

简单的分为下面几个步骤来解决这个问题：

1、mysql运行正常，也有可能是同步设置问题导致

2、如果mysql运行正常，那就是php的一些sql语句导致问题发现，用root用户进入mysql管理

mysql -u root -p

输入密码

mysql:show processlist 语句，查找负荷最重的 SQL 语句，优化该SQL，比如适当建立某字段的索引。

通过这个命令我看到原来是有人恶意刷搜索，因为dedecms搜索后面调用搜索最高的词，导致很多人用工具刷这个，而且是定时有间隔的，所以将这个php程序改名跳转都方法解决了。

当然如果你的确实是sql语句用了大量的group by等语句，union联合查询等肯定会将mysql的占用率提高。所以就需要优化sql语句，网站尽量生成静态的，一般4W ip的静态网站，mysql占用率几乎为0的。所以这对于程序员的经验是个考虑。尽量提高mysql性能 (MySQL 性能优化的最佳20多条经验分享)

下面是豆芽收集的文章，大家都可以参考下

MYSQL CPU 占用 100% 的现象描述

早上帮朋友一台服务器解决了 Mysql cpu 占用 100% 的问题。稍整理了一下，将经验记录在这篇文章里

朋友主机(Windows 2003 + IIS + PHP + MYSQL )近来 MySQL 服务进程 (mysqld-nt.exe) CPU 占用率总为 100% 高居不下。此主机有10个左右的 database, 分别给十个网站调用。据朋友测试，导致 mysqld-nt.exe cpu 占用奇高的是网站A，一旦在 IIS 中将此网站停止服务，CPU 占用就降下来了。一启用，则马上上升。

MYSQL CPU 占用 100% 的解决过程

今天早上仔细检查了一下。目前此网站的七日平均日 IP 为2000，PageView 为 3万左右。网站A 用的 database 目前有39个表，记录数 60.1万条，占空间 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> notepad c:\windows\my.ini

[mysqld]

tmp_table_size=200M

然后重启 MySQL 服务。CPU 占用有轻微下降，以前的CPU 占用波形图是 100% 一根直线，现在则在 97%~100%之间起伏。这表明调整 tmp_table_size 参数对 MYSQL 性能提升有改善作用。但问题还没有完全解决。

于是进入 mysql 的 shell 命令行，调用 show processlist, 查看当前 mysql 使用频繁的 sql 语句：

mysql> show processlist;

反复调用此命令，发现网站 A 的两个 SQL 语句经常在 process list 中出现，其语法如下：

SELECT t1.pid, t2.userid, t3.count, t1.date

FROM _mydata AS t1

LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid

LEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pid

ORDER BY t1.pid

LIMIT 0,15

调用 show columns 检查这三个表的结构 :

mysql> show columns from _myuser;

mysql> show columns from _mydata;

mysql> show columns from _mydata_body;

终于发现了问题所在：_mydata 表，只根据 pid 建立了一个 primary key，但并没有为 userid 建立索引。而在这个 SQL 语句的第一个 LEFT JOIN ON 子句中：

LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid

_mydata 的 userid 被参与了条件比较运算。于是我为给 _mydata 表根据字段 userid 建立了一个索引：

mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )

建立此索引之后，CPU 马上降到了 80% 左右。看到找到了问题所在，于是检查另一个反复出现在 show processlist 中的 sql 语句：

SELECT COUNT(*)

FROM _mydata AS t1, _mydata_key AS t2

WHERE t1.pid=t2.pid and t2.keywords = '孔雀'

经检查 _mydata_key 表的结构，发现它只为 pid 建了了 primary key, 没有为 keywords 建立 index。_mydata_key 目前有 33 万条记录，在没有索引的情况下对33万条记录进行文本检索匹配，不耗费大量的 cpu 时间才怪。看来就是针对这个表的检索出问题了。于是同样为 _mydata_key 表根据字段 keywords 加上索引:

mysql> ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )

建立此索引之后，CPU立刻降了下来，在 50%~70%之间震荡。

再次调用 show prosslist，网站A 的sql 调用就很少出现在结果列表中了。但发现此主机运行了几个 Discuz 的论坛程序， Discuz 论坛的好几个表也存在着这个问题。于是顺手一并解决，cpu占用再次降下来了。(2007.07.09 附注：关于 discuz 论坛的具体优化过程，我后来另写了一篇文章，详见：千万级记录的 Discuz! 论坛导致 MySQL CPU 100% 的 优化笔记 )

解决 MYSQL CPU 占用 100% 的经验总结

增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。

对 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的条件判断中用到的字段,应该根据其建立索引 INDEX。索引被用来快速找出在一个列上用一特定值的行。没有索引，MySQL不得不首先以第一条记录开始并然后读完整个表直到它找出相关的行。表越大，花费时间越多。如果表对于查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要考虑所有数据。如果一个表有1000行，这比顺序读取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B树中存储。

根据 mysql 的开发文档:

索引 index 用于：

快速找出匹配一个WHERE子句的行

当执行联结(JOIN)时，从其他表检索行。

对特定的索引列找出MAX()或MIN()值

如果排序或分组在一个可用键的最左面前缀上进行(例如，ORDER BY key_part_1,key_part_2)，排序或分组一个表。如果所有键值部分跟随DESC，键以倒序被读取。

在一些情况中，一个查询能被优化来检索值，不用咨询数据文件。如果对某些表的所有使用的列是数字型的并且构成某些键的最左面前缀，为了更快，值可以从索引树被检索出来。

假定你发出下列SELECT语句：

mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2；

如果一个多列索引存在于col1和col2上，适当的行可以直接被取出。如果分开的单行列索引存在于col1和col2上，优化器试图通过决定哪个索引将找到更少的行并来找出更具限制性的索引并且使用该索引取行。 参考技术A 先 找到 CPU 高的线程，如果 CPU 高的线程号一直在变，那可能不是单个 SQL 引起的 CPU 消耗，需要用其他方法来辅助分析。找到线程任务processlist 。
可以看到很多有用的信息：
1. 可以看到 processlist 中对应这根线程的信息
2. 可以找到其在 processlist 中的 ID，这样我们就可以下 kill 命令来结束 SQL
小贴士：
使用 performance_schema 时，需要大家注意 MySQL 使用了多个线程编号，源自于不同视角：
1. PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者可以直接用 kill 命令。
2. THREAD_ID：是 MySQL 内部使用的线程编号，是 MySQL 内部视角的编号。
3. THREAD_OS_ID：是在操作系统上，对应的线程编号，是操作系统视角的编号。
大家使用时需要区分好，不要 kill 错了 SQL。
其他有用的信息，可以看到 SQL 执行的开始时间，正在使用了一张临时磁盘表。
如果开启了 performance_schema 的其他监控项，通过 Thread_ID 关联，可以找到更多信息。
当然，眼下这么明显的坑 SQL，我们 kill 掉就是了。