故障分析 | 数据库服务器内存不足一例分析

　　作者：付祥

　　现居珠海，主要负责 Oracle、MySQL、mongoDB 和 Redis 维护工作。

　　本文来源：原创投稿

　　* 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

　　监控告警某台机器空闲内存低于10%，执行top命令，按内存降序排序，部分输出如下：

　　total=32G,used=19G,buff/cache=11G,available=3G，最耗内存进程为 MySQL、Redis，总计约18.2G，其他进程占用内存都比较低，buff/cache 内存中只有3G是有效的，剩余8G内存去哪里？

　　执行 free 命令进一步查看：

　　其中shared占用竟然占用了8G内存，通过man查看帮助：

　　shared Memory来源于/proc/meminfo中Shmem，被tmpfs使用，df -h查看：

　　目录/run使用了8.6G内存，和shared占用内存一致，内存都消耗到哪些子目录了？

　　内存主要消耗在/run/systemd/users和/run/log/journal目录，占用内存分别为7126M、1624M，较为异常的是/run/systemd/users占用内存过高，继续分析这个目录下有哪些文件

　　乍一看，只有一个文件占用约40k，这和du统计的差异也太大了吧，是不是有隐藏文件：

　　不看不知道，一看吓一跳，隐藏文件数高达30w+，最早的文件有2018年的，最新的文件今天产生的，随便打开一个文件看看：

　　保存的是root用户session信息，loginctl查看session信息：

　　root用户session数竟然高达2131个，随便拿一个session看看：

　　crond产生的session，这些session都没有分配相关进程，当前状态为active，按session排序后，挑选最近的session查看，都是2018年产生的：

　　做了一个定时任务测试，session能正常分配进程，任务完成后session关闭：

　　个人觉得可选解决方案如下：1、服务器上主要服务为MySQL和Redis，MySQL作为从库使用，未承载业务读流量，Redis近期将会迁移，/run/systemd/users目录占用内存虽然在增长，5年了也只占用8G，增量很缓慢，故可以在线收缩MySQL innodb_buffer_pool_size使用内存，释放一部分内存给操作系统，等Redis迁移了再做机器重启处理。2、假设主机不可以重启，通过lsof可知这些隐藏文件当前未被使用，故可以迁移到其他磁盘目录，看看是否能达到释放内存目的，且这些session都是crond 2018年产生的，并未分配相关进程，故通过loginctl kill-session ID干掉。目前采取方案1处理。

　　本文关键字：#memory# #tmpfs# #crond#

　　文章推荐：

　　MySQL 相同 SQL 不同环境执行时间不一样案例分析

　　MySQL 从机故障重启后主从同步报错案例分析mysql 5.6 升级到 8.0 失败一例处理

　　关于SQLE爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。

　　SQLE 获取类型地址版本库https://github.com/actiontech/sqle文档https://actiontech.github.io/sqle-docs-cn/发布信息https://github.com/actiontech/sqle/releases数据审核插件开发文档https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html更多关于 SQLE 的信息和交流，请加入官方QQ交流群：637150065...