负载情况

来源:互联网 发布:countif数据最多多少位 编辑:程序博客网 时间:2024/06/09 20:09
由于机器自身也可能影响到负载情况,这边提供如下几个命令的操作截图(root权限下),方便进一步排查。


命令: 
    linux:
        1. 
            A: vmstat 2 10
            B: 第 1 列 r 的值如果长时间大于 CPU 的核心数,说明云主机 CPU 紧张。
            C: 第 17列 st 值如果长时间大于 3,说明物理机 CPU 紧张。


        2. 
            A: top -d 2
            B: 然后按 1, 查看什么程序占用 CPU 高。


        3. 
            A: sar -n DEV 2 10


        4.
            A. iostat -xmt 2 10
            B. free -m

            C. 其中的 await 值如果长时间大于 10ms 或者 %util 长时间大于 70% 时,说明磁盘 IO 紧张。使用 iotop -d 2 查看什么程序占用了 IO,如果占用 IO 的应用类型是 DB 之类的,建议用户使用 UDB。如果占用 IO 的应用类型是 hadoop、hbase 之类,建议用户使用大数据机型或 UDDP。


df -hl 
查看磁盘情况



开启慢查询

方法一:在服务器上找到mysql的配置文件my.cnf , 然后再mysqld模块里追加一下内容

log_slow_queries = NO
log-slow-queries = /var/run/mysqld/slow_querys.log 
long_query_time = 3 
log-queries-not-using-indexes 
log-slow-admin-statements

然后重启mysql服务器即可,这是通过一下命令看一下慢查询日志的情况:

tail -f /var/run/mysqld/slow_querys.log

方法二:通过修改myssql的全局变量来处理,这样做的好处是,不用重启mysql服务器,登陆到mysql上执行一下sql脚本即可

set global slow_query_log=ON;

set global long_query_time=3;

然后通过一下命令查看是否成功

mysql> show variables like 'long%';
+-----------------+-----------+
| Variable_name  | Value    |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
 
 
mysql> show variables like 'slow%';
+---------------------+---------------+
| Variable_name      | Value        |
+---------------------+---------------+
| slow_launch_time    | 2            |
| slow_query_log      | ON            |
| slow_query_log_file | /tmp/slow.log |
+---------------------+---------------+
rows in set (0.00 sec)

分析慢查询日志

方法一:通过查看mysql的慢查询日志分析,比如我们可以tail -f  slow_query.log查看里面的内容,字段意义

# Time: 110107 16:22:11 
# User@Host: root[root] @ localhost [] 
# Query_time: 9.869362 Lock_time: 0.000035 Rows_sent: 1 Rows_examined: 6261774 
SET timestamp=1294388531; 
select count(*) from ep_friends; 
第一行,SQL查询执行的时间 
第二行,执行SQL查询的连接信息 
第三行记录了一些我们比较有用的信息 
Query_time SQL执行的时间,越长则越慢 
Lock_time 在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间 
Rows_sent 查询返回的行数 
Rows_examined 查询检查的行数

方法二:使用mysqldumpslow命令分析,例如

mysqldumpslow -s c -t 10 /tmp/slow-log

这会输出记录次数最多的10条SQL语句,其中:

-s, 是表示按照何种方式排序,c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序,ac、at、al、ar,表示相应的倒叙; -t, 是top n的意思,即为返回前面多少条的数据; -g, 后边可以写一个正则匹配模式,大小写不敏感的;

比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回记录集最多的10个查询。
/path/mysqldumpslow -s t -t 10 -g “left join” /tmp/slow-log
得到按照时间排序的前10条里面含有左连接的查询语句。

慢查询日志的不足

虽然记录了slow query能够帮助你优化产品。但是MySQL目前版本,还有几大蹩足的地方。
1.MySQL5.0版本, long_query_time时间粒度不够细,最小值为1秒。对于高并发性能的网页脚本而言,1秒出现的意义不大。即出现1秒的查询比较少。直到mysql5.1.21才提供更细粒度的long_query_time设定.


2.不能将服务器执行的所有查询记录到慢速日志中。虽然MySQL普通日志记录了所有查询,但是它们是解析查询之前就记录下来了。这意味着普通日志没办法包含诸如执行时间,锁表时间,检查行数等信息。


3.如果开启了log_queries_not_using_indexes选项,slow query日志会充满过多的垃圾日志记录,这些快且高效的全表扫描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。开启了log_queries_not_using_indexes选项,slow query日志会充满过多的垃圾日志记录,这些快且高效的全表扫描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。



0 0