登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评论 > 正文

澳门金沙在线娱乐

2018-07-25 10:41    it168网站 原创  作者: 田晓旭 编辑: 田晓旭

  【IT168 评论】故障排除对于所有人来说都不会是一件有趣的事情,尤其是在没有崩溃报告的情况下。如果MySQL因内存不足而崩溃时应该怎么办?Peter Zaitsev曾在2012年写过的一篇博客中给出了许多有用的提示,而利用新版本的MySQL的(5.7及以上)和performance_schema,我们可以更轻松地解决MySQL的内存分配问题。

故障排除指南:MySQL的运行内存不足怎么办?

  本文将向大家介绍如何解决MySQL的内存分配问题。

  首先,我们先来看一下在哪些情况下的MySQL会因内存不足而崩溃:

  当MySQL的尝试分配比可用内存更多的内存时,例如没有正确设置innodb_buffer_pool_size;

  服务器上还有一些其他进程可以分配内存,比如它应用程序(使用Java,Python,PHP),网络服务器,或者是备份(即mysqldump的)。

  MySQL的中的内存泄漏。这是最糟糕的情况,我们需要进行故障排除。

  以上,就是常见的三种MySQL的因内存不足而崩溃的情况,其中前两种情况比较好解决,而第三种情况就比较棘手。

  从哪里开始排除MySQL的内存泄漏问题

  假设这是一个Linux的服务器,我们首先要 检查的Linux操作系统和配置 ,

  1.检查mysql错误日志和Linux日志文件(即/ var / log / messages或/ var / log / syslog)来识别崩溃。你可能会看到OOM Killer杀死MySQL的条目,可以使用“dmesg”来显示相关的详细信息。

  2.检查可用的RAM: free -g cat / proc / meminfo

  3.检查哪些应用程序正在使用RAM: “top”或“htop”

  4.检查mysql配置: /etc/my.cnf或一般/ etc / my *(包括/ etc / mysql / *等文件),MySQL可能正在运行不同的my.cnf(运行ps ax | grep mysql)

  5.运行vmstat 5 5以查看系统是否正在通过虚拟内存进行读/写以及是否正在进行交换

  6.对于非生产环境,我们可以使用其他工具(如Valgrind的,GDB等)来检查的MySQL的使用情况。

  检查MySQL的内部

  我们也可以通过检查MySQL的内部来发现潜在的MySQL的内存泄露.MySQL在很多地方都会有内存分配,尤其是在以下情况下:

  1.表缓存

  2.Performance_schema(运行:show engine performance_schema status,并查看最后一行)。

  3.InnoDB(运行show engine innodb status并检查缓冲池部分,为buffer_pool和相关缓存分配的内存)

  4.RAM中的临时表(select * from information_schema .tables where engine ='MEMORY')

  5.准备语句。

  不过,从MySQL 5.7版本开始,我们就可以在performance_schema中查看内存分配。那么,如何使用呢?

  首先,我们需要启用收集内存指标.RUN:

  UPDATE setup_instruments SET ENABLED ='YES'名称在哪里'记忆/%';

  sys schema 运行 报告 :

  select event_name,current_alloc,high_alloc来自sys.memory_global_by_current_bytes其中current_count> 0;

  通常,分配内存时会提供代码,所以在某些情况下搜索某些错误时,我们可能需要检查 MySQL的 源代码例如,对于在触发器中过度分配内存的错误:

  某些情况下搜索某些错误时,我们可能需要检查MySQL的源代码例如,对于在触发器中过度分配内存的错误:

  mysql> select memory_name,current_alloc,high_alloc from memory_global_by_current_bytes where current_count> 0;+ ------------------------------------------------- ------------------------------- + --------------- +- ----------- +| event_name | current_alloc | high_alloc |+ ------------------------------------------------- ------------------------------- + --------------- +- ----------- +| 记忆/ innodb / buf_buf_pool | 7.29 GiB | 7.29 GiB || memory / sql / sp_head :: main_mem_root | 3.21 GiB | 3.62 GiB

  RAM中最大的块通常是缓冲池,但存储过程中的3G似乎也太高了。

  根据MySQL的源代码文档,SPHead表示存储程序的一个实例,该程序可能是任何类型(存储过程,函数,触发器,事件)。在这种情况下,就会有潜在的内存泄漏。此外,如果我们想要更清楚的知道MySQL的内存情况,还可以得到一个更高级别的总报告。

  mysql> select substring_index( - > substring_index(event_name,'/',2), - >'/', - > -1 - >)作为event_type, - > round(sum(CURRENT_NUMBER_OF_BYTES_USED)/ 1024/1024,2)为MB_CURRENTLY_USED - > from performance_schema.memory_summary_global_by_event_name - >按event_type分组 - > MB_CURRENTLY_USED> 0;+ -------------------- + ------------------- +| event_type | MB_CURRENTLY_USED |+ -------------------- + ------------------- +| innodb | 0.61 || 记忆| 0.21 || performance_schema | 106.26 || sql | 0.79 |+ -------------------- + ------------------- +4行(0.00秒)

关键字: MySQL
分享到:
0 个人觉得赞+1
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部