生产环境mysql内存溢出重启简单分析

简介:

思路

1. 查看数据库日志

2. 查看慢查询

3. 查看系统日志

4. 查看监控

 

2017-01-03 03:03:48 0 170103 03:03:45 mysqld_safe Number of processes running now: 0

170103 03:03:45 mysqld_safe mysqld restarted   --异常重启

[Note] /usr/sbin/mysqld (mysqld 5.6.25-log) starting as process 104767 ...

2017-01-03 03:03:48 7f9bcd3f4720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the opt

ion innodb_use_sys_malloc and with the InnoDB's internal memory allocator.

2017-01-03 03:03:48 104767 [Note] InnoDB: Using atomics to ref count buffer pool pages

2017-01-03 03:03:48 104767 [Note] InnoDB: The InnoDB memory heap is disabled

2017-01-03 03:03:48 104767 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

2017-01-03 03:03:48 104767 [Note] InnoDB: Memory barrier is not used

2017-01-03 03:03:48 104767 [Note] InnoDB: Compressed tables use zlib 1.2.3

2017-01-03 03:03:48 104767 [Note] InnoDB: Using Linux native AIO

2017-01-03 03:03:48 104767 [Note] InnoDB: Using CPU crc32 instructions

2017-01-03 03:03:48 104767 [Note] InnoDB: Initializing buffer pool, size = 4.0G

2017-01-03 03:03:48 104767 [Note] InnoDB: Completed initialization of buffer pool

2017-01-03 03:03:48 104767 [Note] InnoDB: Highest supported file format is Barracuda.

2017-01-03 03:03:48 104767 [Note] InnoDB: Log scan progressed past the checkpoint lsn 3021323914038

2017-01-03 03:03:48 104767 [Note] InnoDB: Database was not shutdown normally!

2017-01-03 03:03:48 104767 [Note] InnoDB: Starting crash recovery.

 

通过查看open-falcon 监控,发现数据库重启的时间内存使用率100%mysqld_safe具有安全保护机制,对于异常的关闭数据库,mysqld_safe 进程可以把mysqld 进程拉起来。我们当时的情况是,数据库被拉起来了,但是主库参数设置的是只读,影响了部分业务。后续调整了参数,把主库的只读参数设置为read_only=off。当然罪魁祸首是因为慢查询引起的。找到慢查询,提交给开发同事,修改sql之后,稳定下来,不过内存也确实太紧张了,没法再挺着了,准备扩一点内存,这个费用没法再节省了。










本文转自 roidba 51CTO博客,原文链接:http://blog.51cto.com/roidba/1890527,如需转载请自行联系原作者
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
SQL 存储 关系型数据库
MySQL内存引擎:Memory存储引擎的适用场景
MySQL Memory存储引擎将数据存储在内存中,提供极速读写性能,适用于会话存储、临时数据处理、高速缓存和实时统计等场景。但其数据在服务器重启后会丢失,不适合持久化存储、大容量数据及高并发写入场景。本文深入解析其特性、原理、适用场景与限制,并提供性能优化技巧及替代方案比较,助你合理利用这一“内存闪电”。
|
存储 弹性计算 缓存
阿里云服务器ECS经济型、通用算力、计算型、通用和内存型选购指南及使用场景分析
本文详细解析阿里云ECS服务器的经济型、通用算力型、计算型、通用型和内存型实例的区别及适用场景,涵盖性能特点、配置比例与实际应用,助你根据业务需求精准选型,提升资源利用率并降低成本。
869 3
|
11月前
|
设计模式 缓存 Java
【JUC】(4)从JMM内存模型的角度来分析CAS并发性问题
本篇文章将从JMM内存模型的角度来分析CAS并发性问题; 内容包含:介绍JMM、CAS、balking犹豫模式、二次检查锁、指令重排问题
291 1
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
988 4
AI代理内存消耗过大?9种优化策略对比分析
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
|
JavaScript
如何使用内存快照分析工具来分析Node.js应用的内存问题?
需要注意的是,不同的内存快照分析工具可能具有不同的功能和操作方式,在使用时需要根据具体工具的说明和特点进行灵活运用。
808 159
|
SQL Oracle 关系型数据库
在MySQL Shell里 重启MySQL 8.4实例
在MySQL Shell里 重启MySQL 8.4实例
575 2
|
存储 Java
课时4:对象内存分析
接下来对对象实例化操作展开初步分析。在整个课程学习中,对象使用环节往往是最棘手的问题所在。
210 4
|
SQL 关系型数据库 MySQL
MySQL生产环境迁移至YashanDB数据库深度体验
这篇文章是作者将 MySQL 生产环境迁移至 YashanDB 数据库的深度体验。介绍了 YashanDB 迁移平台 YMP 的产品相关信息、安装步骤、迁移中遇到的各种兼容问题及解决方案,最后总结了迁移体验,包括工具部署和操作特点,也指出功能有优化空间及暂不支持的部分,期待其不断优化。

推荐镜像

更多