首页 > 数据库 >mysql高负载

mysql高负载

时间：2022-11-25 14:14:46浏览次数：41  
标签：负载 fpm www poo innodb mysql php pool

MySQL数据库负载很高的解决办法

一、应急解决办法

在MySQL数据库连接数很多,而且大多属于活跃的状态时MySQL机器基本上负载很高,属于基本上快要死去的状态了. 这时怎么办呢?

有可能两个办法.

第一: 先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果 非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务. 处理方法:

set global innodb_thread_concurrency=16;

第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了. DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的. 限制单用户连接数在500以下. 如:

set global max_user_connections=500;

(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因) 另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数 innodb_stats_on_metadata=0

set global innodb_stats_on_metadata=0;

这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也可以考虑禁用该参数)

二、问题分析

思路：
1、确定高负载的类型 htop，dstat命令看负载高是CPU还是IO
2、监控具体的sql语句，是insert update 还是 delete导致高负载
3、检查mysql日志
4、检查硬件问题

dstat

可以看到具体是哪个用户哪个进程占用了相关系统资源，当前CPU、内存谁在使用

  1. [root@cc ~]# dstat -l -m -r -c --top-io --top-mem --top-cpu
  3. --io/total- ------memory-usage----- --most-expensive- ----most-expensive---- -most-expensive-
  4. read writ| used buff cach free| memory process | i/o process | cpu process
  5. 1.90 267 |3399M 178M 3892M 400M|php-fpm: poo 372M|init 1682k 647k|flush-202:0 0.1
  6. 0 72.0 |3399M 178M 3892M 400M|php-fpm: poo 372M|php-fpm: po 10k 143k|php-fpm: pool2.0
  7. 0 8.00 |3399M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 228k 229k|php-fpm: pool0.5
  8. 0 88.0 |3399M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 102k 166k|php-fpm: pool 11
  9. 0 38.0 |3399M 178M 3892M 399M|php-fpm: poo 372M|php-fpm: po 787k 650B|php-fpm: pool4.8
  10. 0 0 |3399M 178M 3892M 399M|php-fpm: poo 372M|php-fpm: po 788k 723B|php-fpm: pool1.8
  11. 0 140 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 38k 154k|php-fpm: pool1.2
  12. 0 12.0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 178k 364k|php-fpm: pool1.5
  13. 0 0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 758k 639k|php-fpm: pool1.5
  14. 0 12.0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 773k 616k|php-fpm: pool2.0
  15. 6.00 0 |3401M 178M 3892M 398M|php-fpm: poo 372M|nginx: work 994k 688k|nginx: worker1.5
  16. 0 272 |3401M 178M 3892M 398M|php-fpm: poo 372M|nginx: work 388k 422k|php-fpm: pool1.5
  17. 0 0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 483k 548k|php-fpm: pool1.8
  18. 0 4.00 |3400M 178M 3893M 398M|php-fpm: poo 372M|php-fpm: po 787k 650B|php-fpm: pool1.5
  19. 0 12.0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 223k 323k|php-fpm: pool1.5
  20. 0 0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 371k 474k|php-fpm: pool7.8

htop

htop是top的增强版，更直观

  1. [root@cc ~]# htop
  3. 1 [||||||||||| 12.4%]
  4. 2 [||||||||| 9.5%]
  5. 3 [| 1.0%]
  6. 4 [|| 1.9%]
  7. Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||3394/7869MB]
  8. Swp[|||||||||||||| 75/478MB]
  10. Tasks: 71, 12 thr; 2 running
  11. Load average: 0.39 0.39 0.31
  12. Uptime: 526 days(!), 17:36:38
  14. PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
  15. 1 root 20 0 19232 396 248 S 0.0 0.0 0:01.86 /sbin/init
  16. 30752 root 20 0 52532 72 56 S 0.0 0.0 0:00.16 ├─ /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
  17. 24301 root 20 0 193M 3268 1600 S 0.0 0.0 1:41.43 ├─ /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid
  18. 21361 root 20 0 902M 6500 1308 S 0.0 0.1 0:07.16 ├─ php-fpm: master process (/etc/php-fpm.conf)
  19. 28627 www 20 0 962M 202M 138M S 0.0 2.6 0:34.46 │ ├─ php-fpm: pool www-c
  20. 27537 www 20 0 965M 236M 171M R 1.4 3.0 1:19.64 │ ├─ php-fpm: pool www-c
  21. 27449 www 20 0 961M 251M 189M S 0.0 3.2 1:35.54 │ ├─ php-fpm: pool www-a
  22. 26442 www 20 0 962M 280M 217M S 0.0 3.6 2:29.71 │ ├─ php-fpm: pool www-a
  23. 26310 www 20 0 917M 251M 234M S 1.9 3.2 2:46.45 │ ├─ php-fpm: pool www-a
  24. 26162 www 20 0 962M 297M 233M S 0.0 3.8 2:37.50 │ ├─ php-fpm: pool www-b
  25. 26147 www 20 0 924M 258M 233M S 0.0 3.3 2:38.37 │ ├─ php-fpm: pool www-c
  26. 25717 www 20 0 965M 302M 238M S 0.0 3.8 2:54.50 │ ├─ php-fpm: pool www-c
  27. 24585 www 20 0 964M 324M 260M S 0.0 4.1 4:15.20 │ ├─ php-fpm: pool www-b

tcpdump

抓取mysql包分析，一般抓3306端口的数据

[root@cc ~]# tcpdump -i eth0 -A -s 3000 port 3306 > ~/sql.log

然后使用awk,sort,wc 等命令进行分析

或者

  1. [root@cc ~]# tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | perl -e '
  2. while(<>) { chomp; next if /^[^ ]+[ ]*$/;
  3. if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER)/i) {
  4. if (defined $q) { print "$qn"; }
  5. $q=$_;
  6. } else {
  7. $_ =~ s/^[ t]+//; $q.=" $_";
  8. }
  9. }'

就可以看出最繁忙的sql语句了

strace 或 pstack

查看系统调用是否有问题，进程是否堵塞，是否有Broken pipe

[root@cc ~]# strace -p 26578

[root@cc ~]# pstack 26356

pt-query-digest

分析mysql慢日志，查看哪些sql语句最耗时

  1. [root@cc ~]# pt-query-digest slow.logs
  3. # 390ms USER TIME, 10ms system TIME, 15.67M rss, 105.84M vsz
  4. # CURRENT DATE: Thu DEC 29 13:22:42 2014
  5. # Hostname: test
  6. # Files: slow.log
  7. # Overall: 776 total, 11 UNIQUE, 0.00 QPS, 0.00x concurrency _____________
  8. # TIME range: 2011-09-10 04:03:19 TO 2011-12-29 05:02:51
  9. # Attribute total MIN MAX avg 95% stddev median
  10. # ============ ======= ======= ======= ======= ======= ======= =======
  11. # EXEC TIME 5657s 2s 33s 7s 23s 6s 5s
  12. # LOCK TIME 33s 0 19s 43ms 98us 715ms 38us
  13. # ROWS sent 323.38k 0 107.36k 426.73 0.99 6.35k 0
  14. # ROWS examine 323.39k 0 107.36k 426.74 0 6.35k 0
  15. # Query SIZE 217.95k 38 562 287.61 420.77 81.78 284.79

show processlist

查看系统到底在干什么

  2. mysql> show full processlist;
  3. +-----------+---------------+---------------------+---------------------+---------+------+---------------+---------------------------+
  4. | Id | User | Host | db | Command | Time | State | Info |
  5. +-----------+---------------+---------------------+---------------------+---------+------+---------------+---------------------------+
  6. | 184498848 | testdb_rr1356 | 10.11.211.120:61343 | testdb_rr1356_db121 | Sleep | 1384 | | NULL |
  7. | 184508740 | testdb_rr1356 | 10.11.211.120:11809 | testdb_rr1356_db121 | Sleep | 87 | | NULL |
  8. | 184509415 | testdb_rr1356 | 10.11.211.120:12760 | testdb_rr1356_db121 | Query | 0 | NULL | show full processlist |
  9. | 184509451 | testdb_rr1356 | 10.11.211.120:12804 | testdb_rr1356_db121 | Sleep | 10 | | NULL |
  10. | 184509528 | testdb_rr1356 | 10.11.211.120:12919 | testdb_rr1356_db121 | Query | 0 | freeing items | DESCRIBE test_channel |

检查mysql配置参数是否有问题，引起大量的IO或者高CPU操作

innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要参数

  1. mysql> show variables like '%innodb%';
  2. +---------------------------------+----------------------------+
  3. | Variable_name | Value |
  4. +---------------------------------+----------------------------+
  5. | have_innodb | YES |
  6. | ignore_builtin_innodb | ON |
  7. | innodb_adaptive_flushing | ON |
  8. | innodb_adaptive_hash_index | ON |
  9. | innodb_additional_mem_pool_size | 2097152 |
  10. | innodb_autoextend_increment | 8 |
  11. | innodb_autoinc_lock_mode | 1 |
  12. | innodb_buffer_pool_size | 2013265920 |
  13. | innodb_change_buffering | inserts |
  14. | innodb_checksums | ON |

通过show engine innodb status查看当前事务，内存使用

  1. mysql> show engine innodb status \G
  3. LATEST DETECTED DEADLOCK
  4. ------------------------
  5. 150731 10:36:50
  6. *** (1) TRANSACTION:
  7. TRANSACTION EBFBBEC, ACTIVE 0 sec, process no 20691, OS thread id 47345217033984 inserting
  8. mysql tables in use 1, locked 1
  9. LOCK WAIT 5 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 2
  10. MySQL thread id 143249904, query id 1286731854 10.135.21.120 tybuser2014 update
  12. #此处具体sql省略
  14. ----------------------
  15. BUFFER POOL AND MEMORY
  16. ----------------------
  17. Total memory allocated 2058485760; in additional pool allocated 0
  18. Dictionary memory allocated 819282
  19. Buffer pool size 122879
  20. Free buffers 97599
  21. Database pages 24313
  22. Old database pages 8954
  23. Modified db pages 7
  24. Pending reads 0
  25. Pending writes: LRU 0, flush list 0, single page 0
  26. Pages made young 6, not young 0
  27. 0.00 youngs/s, 0.00 non-youngs/s
  28. Pages read 1049, created 41853, written 30401604
  29. 0.00 reads/s, 0.00 creates/s, 1.75 writes/s
  30. Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
  31. Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
  32. LRU len: 24313, unzip_LRU len: 0
  33. I/O sum[45]:cur[0], unzip sum[0]:cur[0]

最后通过zabbix或者cacti等监控来查看IO、CPU、MEMORY、磁盘等是否有异常

这样基本上就可以把问题找出来了

标签：负载,fpm,www,poo,innodb,mysql,php,pool
From： https://www.cnblogs.com/Lqdream/p/16924903.html

相关文章

  • MySql语句性能问题定位--从sql语句到磁盘IO检查
    MySql语句性能问题定位--从sql语句到磁盘IO检查一、背景  本文只针对IO导致MySql性能问题的定位，其他如CPU、MySql参数配置、程序自身等问题需要进一步补充。原因某条......
  • MySQL高可用主从切换工具replication-manager
    MySQL高可用主从切换工具replication-manager MySQL高可用工具，一直以来MHA使用的比较多，自从MySQL开启GTID之后，又出现了Orchestrator以及replication-manager这类新的高......
  • MySQL调优之innodb_buffer_pool_size大小设置
    MySQL调优之innodb_buffer_pool_size大小设置sunny052962017-12-2721:42:0443421收藏9展开 MySQL调优之innodb_buffer_pool_size大小设置 相关查看命令sql>......
  • mysql参数优化
    MySQL性能优化之参数配置 1、目的：通过根据服务器目前状况，修改Mysql的系统参数，达到合理利用服务器现有资源，最大合理的提高MySQL性能。 2、服务器参数：32G内存、4个CP......
  • 解析负载均衡原理
    不能狭义地理解为分配给所有实际服务器一样多的工作量，因为多台服务器的承载能力各不相同，这可能体现在硬件配置、网络带宽的差异，也可能因为某台服务器身兼多职，我们所说的“均......
  • Mysql主从同步的实现原理与配置
    1、什么是mysql主从同步？当master(主)库的数据发生变化的时候，变化会实时的同步到slave(从)库。 2、主从同步有什么好处？水平扩展数据库的负载能力。容错，高可用。Failover(失......
  • Go 操作 MySQL 数据库
    这一期讲一讲如何使用Go操作MySQL数据库，这里就不讲MySQL的安装以及配置了，但要记得开启MySQL服务，我这里使用的是MySQL8.0.20版本。加载数据库驱动想要连接到数据......
  • Go 的 MySQL 预处理、MySQL 事务
    预处理是什么在普通SQL语句执行过程中，客户端会对SQL语句进行占位符替换，从而得到要执行的完整SQL语句，客户端再将此SQL语句发送到服务端执行，服务端最后把结果返回给客......
  • 【MySQL数据库开发之三】MySQL 获得数据库和表的信息、日期计算、对表的删除修改等操
    本站文章均为​​ 李华明Himi ​​​原创,转载务必在明显处注明通过上一篇的介绍，大家可以创建自己的数据库和表以及插入表中数据等等，本章继续介绍更多的数据库的相关操作；......
  • 【MySQL数据库开发之二】MySQL 基础语句的书写与一些数据库操作（创建使用数据库、表）！
    本站文章均为​​ 李华明Himi ​​​原创,转载务必在明显处注明本篇Himi简单介绍一些MySQL数据库的基础操作；注：mysql语句对大小写不敏感，语句以分号“;”标识语句结束；1. ......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99