MySQL CPU跑满

原文链接:https://www.cnblogs.com/wyy123/p/9258513.html

用户在使用 MySQL 实例时,会遇到 CPU 使用率过高甚至达到 100% 的情况。本文将介绍造成该状况的常见原因以及解决方法,并通过 CPU 使用率为 100% 的典型场景,来分析引起该状况的原因及其相应的解决方案。

常见原因

系统执行应用提交查询(包括数据修改操作)时需要大量的逻辑读(逻辑 IO,执行查询所需访问的表的数据行数),所以系统需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。

说明:大量行锁冲突、行锁等待或后台任务也有可能会导致实例的 CPU 使用率过高,但这些情况出现的概率非常低,本文不做讨论。

本文通过一个简化的模型来说明系统资源、语句执行成本以及 QPS(Query Per Second 每秒执行的查询数)之间的关系:

  • 条件:应用模型恒定(应用没有修改)。
  • avg_lgc_io:执行每条查询需要的平均逻辑 IO。
  • total_lgc_io:实例的 CPU 资源在单位时间内能够处理的逻辑 IO 总量。
  • 关系公式:total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量

解决方法

数据管理(DMS)工具提供了几种辅助排查并解决实例性能问题的功能,主要有:

  • 实例诊断报告
  • SQL 窗口提供的查询优化建议和查看执行计划
  • 实例会话

其中,实例诊断报告是排查和解决 MySQL 实例性能问题的最佳工具。无论何种原因导致的性能问题,建议您首先参考下实例诊断报告,尤其是诊断报告中的 SQL 优化、会话列表和慢 SQL 汇总分。

另外,如果您需要阿里云的技术支持来解决 CPU 使用率高的状况,请参见 https://market.aliyun.com/store/1682301.html

避免出现 CPU 使用率达到 100% 的一般原则

  • 设置 CPU 使用率告警,实例 CPU 使用率保证一定的冗余度。
  • 应用设计和开发过程中,要考虑查询的优化,遵守 MySQL 优化的一般优化原则,降低查询的逻辑 IO,提高应用可扩展性。
  • 新功能、新模块上线前,要使用生产环境数据进行压力测试(可以考虑使用阿里云 PTS 压力测试工具)。
  • 新功能、新模块上线前,建议使用生产环境数据进行回归测试。
  • 建议经常关注和使用 DMS 中的诊断报告。

    注意:关于如何访问 DMS 中的诊断报告,请参见 RDS 如何访问诊断报告

典型示例

以 CPU 使用率为 100% 的典型场景为例,本文介绍了两个引起该状况的原因及其解决方案,即应用负载(QPS)高和查询执行成本(查询访问表数据行数 avg_lgc_io)高。其中,由于查询执行成本高(查询访问表数据行数多)而导致实例 CPU 使用率高是 MySQL 非常常见的问题。

应用负载(QPS)高

现象描述

  • 特征:实例的 QPS(每秒执行的查询次数)高,查询比较简单、执行效率高、优化余地小。
  • 表现:没有出现慢查询(或者慢查询不是主要原因),且 QPS 和 CPU 使用率曲线变化吻合。
  • 常见场景:该状况常见于应用优化过的在线事务交易系统(例如订单系统)、高读取率的热门 Web 网站应用、第三方压力工具测试(例如 Sysbench)等。

解决方案

对于由应用负载高导致的 CPU 使用率高的状况,使用 SQL 查询进行优化的余地不大,建议您从应用架构、实例规格等方面来解决,例如:

  • 升级实例规格,增加 CPU 资源。
  • 增加只读实例,将对数据一致性不敏感的查询(比如商品种类查询、列车车次查询)转移到只读实例上,分担主实例压力。
  • 使用阿里云 DRDS 产品,自动进行分库分表,将查询压力分担到多个 RDS 实例上。
  • 使用阿里云 Memcache 或者云 Redis 产品,尽量从缓存中获取常用的查询结果,减轻 RDS 实例的压力。
  • 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用,考虑开启查询缓存(Query Cache)。

    注意:能否从开启查询缓存(Query Cache)中获益需要经过测试,具体设置请参见 RDS for MySQL 查询缓存(Query Cache)的设置和使用

  • 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
  • 尽量优化查询,减少查询的执行成本(逻辑 IO,执行需要访问的表数据行数),提高应用可扩展性。

查询执行成本(查询访问表数据行数 avg_lgc_io)高

现象描述

  • 特征:实例的 QPS(每秒执行的查询次数)不高;查询执行效率低、执行时需要扫描大量表中数据、优化余地大。
  • 表现:存在慢查询,QPS 和 CPU 使用率曲线变化不吻合。
  • 原因分析:由于查询执行效率低,为获得预期的结果即需要访问大量的数据(平均逻辑 IO高),在 QPS 并不高的情况下(例如网站访问量不大),就会导致实例的 CPU 使用率高。

解决方案

解决该状况的原则是:定位效率低的查询、优化查询的执行效率、降低查询执行的成本。

操作步骤
  1. 通过如下方式定位效率低的查询:
    • 通过 show processlist; 或 show full processlist; 命令查看当前执行的查询,如下图所示:查看当前执行的查询

      对于查询时间长、运行状态(State 列)是“Sending data”、“Copying to tmp table”、“Copying to tmp table on disk”、“Sorting result”、“Using filesort”等都可能是有性能问题的查询(SQL)。

      注意:

      • 若在 QPS 高导致 CPU 使用率高的场景中,查询执行时间通常比较短,show processlist; 命令或实例会话中可能会不容易捕捉到当前执行的查询。您可以通过执行如下命令进行查询:
        1. explain select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on >= 2015-01-01 and a.detail = b.detail
      • 您可以通过执行类似 kill 101031643; 的命令来终止长时间执行的会话,终止会话请参见 RDS for MySQL 如何终止会话。关于长时间执行会话的管理,请参见 RDS for MySQL 管理长时间运行查询
    • 通过 DMS 查看当前执行的查询,查询步骤如下:
      1. 在 DMS 控制台上登录数据库
      2. 选择性能 > 实例会话,显示结果如下图所示:DMS 查看执行的查询

        从上图可以看出,有 10 个会话在执行下面这个查询:

        1. select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on>= '2015-01-01' and a.detail= b.detail;
      3. 单击 SQL 列中的查询文本,即可显示完整的查询和其执行计划,如下图所示:查询详情

        从上图可以看出,在该查询的执行计划中,系统对两张约为 30 万行的数据表执行了全表扫描。由于两张表是联接操作,这个查询的执行成本(逻辑 IO)约为 298267 x 298839 = 89,133,812,013(大概 900 亿),所以查询会执行相当长的时间并且多个会话会导致实例 CPU 使用率达到 100%(对于同样规格的实例,如果是优化良好的查询,QPS 可以达到 21000;而当前 QPS 仅为 5)。

  2. 得到需要优化的查询后,可以通过如下任意一种方式来获取查询的优化建议:
    • 通过 DMS 的优化查询获取:

      注意:对于 QPS 高和查询效率低的混合模式导致的 CPU 使用率高的问题,建议使用优化查询获取优化建议。

      1. 在 DMS 控制台上登录数据库
      2. 选择 SQL 操作 > SQL 窗口。
      3. 单击优化,即可得到优化建议,如下图所示:优化查询
    • 通过 DMS 控制台上的诊断报告获取:

      说明:诊断报告同样适用于排查历史实例 CPU 使用率高的问题。

      1. 在 DMS 控制台上登录数据库
      2. 选择性能 > 诊断报告。
      3. 单击发起诊断,即可创建一个针对当前实例运行情况的报告,如下图所示:诊断报告
      4. 单击查看报告,查看优化建议。

        注意:对于 CPU 使用率高的问题,建议关注诊断报告的 SQL 优化、会话列表和慢 SQL 汇总部分。

  3. 根据优化建议,添加索引,查询执行成本就会大幅减少(如下图所示,从 900 亿行减小到 30 万行,查询成本降低 30 万倍),实例 CPU 使用率 100% 的问题解决。优化结果

.NET MVC OutputCache

Web.config

<system.web>
<!–页面缓存–>
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<!–缓存5分钟–>
<add name=”indexindex” duration=”300″ varyByParam=”*” location=”Any”/>
</outputCacheProfiles>
</outputCacheSettings>
</caching>
</system.web>

 

Controller

public class IndexController : Controller
    {
        [OutputCache(CacheProfile = "indexindex")]
        // GET: Home
        public string Index()
        {
            return DateTime.Now.ToString();
        }
    }

curl php file_get_contents 400 bad request

开始用PHP的file_get_contents请求,返回400 Bad Request,但是用浏览器或PostMan访问正常。

然后尝试用PHP的curl函数,一样的错误。

修改php.ini的user-agent或者给curl添加user-agent的header,一样的错误。

服务器直接执行curl命令,一样的错误。

经过一番研究,终于找到原因。

解决方案:url中的空格及加号需要替换为%20,执行成功。

str_replace(array(‘ ‘, ‘+’), ‘%20’, $param)

Apache通过htaccess添加权限验证

参考文章:http://www.htaccesstools.com/articles/password-protection/

With .htaccess it is very easy to password protect a folder or directory. The method is called htaccess password protection or htaccess authentication, and works by uploading two files called .htaccess and .htpasswd in the directory you want to password protect. The htaccess file should contain the following:

AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /path/to/.htpasswd
Require valid-user

You only need to change “/path/to/.htpasswd” with the full path to your .htpasswd. Take a look at my article on how to find the full path using PHP. Next you need to upload the .htpasswd file which contains the username and password to enter the password protected folder. The .htpasswd file should contain:

test:dGRkPurkuWmW2

The above code will allow the user “test” to access the password proteced area with the password “test”. The text “dGRkPurkuWmW2” is a encrypted version of the password. You will need to use a htpasswd generator to create another password. Each line in the .htpasswd file contains a username and password combination, so feel free to add as many combinations as you like.
The automatic way – Use the generator
You can also just use the htaccess authentication generator to create a htaccess file for password protection.

React Native webview中video播放MP4格式视频只有音频

参考文章:https://blog.csdn.net/shaobo8910/article/details/81121965?utm_source=blogxgwz8

昨天遇到了这样一个问题,我打算使用HTML5的video标签简单的在网页上插入一个MP4视频,类似这样

<video preload=”none” controls>
<source src=”video.mp4″ type=”video/mp4″>
</video>
但是在网页中我点击播放的时候,却发现只有声音而没有图像。不过我用电脑中的视频播放器播放这段视频还是可以看到图像的。那么问题来了,这个锅谁来背?

问题出在哪

经过一些搜索得知,其实根本的问题是虽然大家都是.mp4后缀的文件,但是编码方式不同,而video标签的标准是用H.264方式编码视频的MP4文件(当然video标签还可以播放WebM和OGG格式的文件,这里就不多说了),而我之前使用的视频文件是Xvid编码的MP4文件,所以只能播放出音频而不能看到图像

解决方法

既然知道了问题出在哪,接下来就要想办法把我现有的视频文件转码成H.264编码的文件。
我使用的是Mac, 而且之前并没有装过什么视频转码的应用,搜索了一下发现Mac自带一个功能叫“编码所选视频文件”,我尝试着使用了一下。发现然并卵,生成的文件就像我在浏览器中播放的一样,只有声音没有图像,大概这个功能更适合吧其他格式的文件转换成MP4吧。
经过进一步搜索,发现了ffmpeg这个神器,使用这个命令行的工具,最终完成了视频编码的转换,下面详细介绍一下转换的方法

安装并使用 ffmpeg

我使用的是Mac,并且安装了homebrew,所以可以直接通过homebrew安装ffmpeg

brew install ffmpeg
其实ffmpeg的指令有很多,想要详细了解可以参见ffmpeg参数中文详细解释,这里我只需要把一个其他编码格式的MP4文件转换成H.264编码的MP4文件,具体指令如下

ffmpeg -i input.mp4 -vcodec h264 output.mp4
自行替换input和output文件名就可以了,其实这里input文件还可以是其他格式的视频文件,ffmpeg可以自动识别转换的方式,非常便利!
经过上述转换,使用输出的文件在Chrome上播放就没有问题了

MySQL的ibdata1文件占用过大瘦身

参考文章:https://blog.csdn.net/qq_32448349/article/details/82965878

处理MySQL的ibdata1文件过大问题

本人在对数据库进行大量的数据插入和删除的时候,发现ibdata1的占了将近一个T

ibdata1文件是什么?

ibdata1是一个用来构建innodb系统表空间的文件,这个文件包含了innodb表的元数据、撤销记录、修改buffer和双写buffer。如果file-per-table选项打开的话,该文件则不一定包含所有表的数据。当innodb_file_per_table选项打开的话,新创建表的数据和索引则不会存在系统表空间中,而是存放在各自表的.ibd文件中.

显然这个文件会越来越大,innodb_autoextend_increment选项则指定了该文件每次自动增长的步进,默认是8M.

是什么原因导致ibdata1文件会越来越大?

ibdata1存放数据,索引和缓存等,是MYSQL的最主要的数据。所以随着数据库越来越大,表也会越大,这个无法避免的。如果时间长了,越来越大,我们在处理日志和空间的时候就不是那么方便了,就不知从何入手了。接下来我们就要处理下这样的情况,分库存储数据。

该如何处理呢?

首先我们把数据库文件备份下来,然后直接删除ibdata文件(为了保险起见最好先全备一次,做到数据安全和完整),然后再重新导入数据库文件即可!

具体操作步骤如下(截图并不完整,但是首先要弄懂大概情况和原理):

第一种方法:

1、停止业务,备份一次全库

mysqldump -uroot -ppassword –all-databases  > all_mysql.sql
2、备份完成,停止数据库

systemctl stop mariadb 或者 service mysqld stop
3、修改配置文件

在[mysqld]下增加下面配置 innodb_file_per_table=1 验证配置是否生效,可以重启mysql后,执行 #service mysqld restart
4、验证

mysql -uroot -ppassword mysql

show variables like ‘%per_table%’;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| innodb_file_per_table | ON |

+———————–+——-+

1 row in set (0.00 sec)

innodb_file_per_table的状态变为ON

5、删除ibdata1文件和日志

rm -rf ibdata1

rm -rf ib_logfile*

6、还原数据库

mysql -uuser -ppassword

source all_mysql.sql

数据文件单独存放(共享表空间改为每个表独立的表空间文件)。

第二种方法:

把数据库的表引擎为InnoDB 的数据表转为MyIsam 后,删除ibdata1,按上面方法修改成独立的表空间,在把改成MyIsam引擎的表改为InnoDB,这个就要衡量那种方法的时间耗时最短,两者取其优。数据的表和库很多的通常不建议这么做,耗时间。

CentOS + Apache2.4 + PHP5.6 FPM报503错误

Service Unavailable 503错误,很可能的原因是服务器过载。

错误提示:

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

服务器使用Apache2.4,fpm方式加载PHP,因此排查解决过程如下。

1. 查看PHP-FPM日志
#tail -f /alidata/server/php56/var/log/php-fpm.log
WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

2. 修改PHP-FPM配置
#vi /alidata/server/php56/etc/php-fpm.conf
pm.max_children = 5
​修改为
pm.max_children = 100

计算依据参考:https://blog.csdn.net/solmyr_biti/article/details/53955141
pm.max_children = Total RAM dedicated to the web server / Max child process size – in my case it was 85MB
The server has 8GB of RAM, so:
pm.max_children = 6144MB / 85MB = 72

JS关闭网页window.close(兼容各类浏览器,包括微信浏览器)

function closePage()

{

var userAgent = navigator.userAgent;

if (userAgent.indexOf(“Firefox”) != -1 || userAgent.indexOf(“Chrome”) !=-1) {// Firefox或Chrome中关闭

  window.location.href = “about:blank”;

} else {

  window.opener = null;

  window.open(“”, “_self”);

  window.close();

}

if (WeixinJSBridge) {// 微信中关闭

WeixinJSBridge.call(‘closeWindow’);

}

}

CentOS Requires: libc.so.6(GLIBC_2.17)(64bit) 升级glibc到2.17

1、原先的系统glibc库的版本是2.12,需要升级到2.17版本。

下载地址:

http://ftp.gnu.org/gnu/glibc/glibc-2.17.tar.gz
这里可以选择你所需要的版本。

2、安装部署

[root@kafzook1 common]# tar -xf glibc-2.17.tar.gz
[root@kafzook1 common]# cd glibc-2.17
[root@kafzook1 glibc-2.17]# mkdir build; cd build
[root@kafzook1 build]# ../configure –prefix=/usr –disable-profile –enable-add-ons –with-headers=/usr/include –with-binutils=/usr/bin
[root@kafzook1 build]# make -j 8
[root@kafzook1 build]# make install
[root@kafzook1 common]# strings /lib64/libc.so.6 | grep GLIBC
会看到下面的结果
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_PRIVATE

我们可以看到部署成功后的glibc的版本为2.17

问题总结:

在上面安装的过程中我们可能会遇到下面的问题

1. Requires: libc.so.6(GLIBC_2.17)(64bit),升级glibc后,通过strings /lib64/libc.so.6 | grep GLIBC可查到GLIBC_2.17,但还是报错。

解决办法:通过yum clean all,yum makecache,yum update解决了

2. 百度了一下这个问题,说是这个变量后面有一个冒号“:”,我们打印一下这个变量查看一下果然有一个冒号。
他人博客地址:glibc问题解决方案

解决方案:找到这一环境变量,把后面的冒号+$LD_LIBRARY_PATH去掉,然后source一下。

我们看到后面的冒号已经没有了。

———————
作者:wyl9527
来源:CSDN
原文:https://blog.csdn.net/wyl9527/article/details/78256066
版权声明:本文为博主原创文章,转载请附上博文链接!

Linux服务器中木马(肉鸡)手工清除方法

参考地址:https://www.cnblogs.com/shiyiwen/p/5191869.html

http://www.bubuko.com/infodetail-1010815.html

补充:

      1. 文档中提到把ps ss netstat等命令上传到/root目录中,估计是需要从网上下载或从镜像中拷贝。没有从网上找到,因此直接执行了文中的chattr  -i -a /bin/ps && rm /bin/ps -f,然后yum install procps,这样即恢复了ps命令。其他命令也是如此。