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

关注

原创 2023-04-18 14:50:58 829 阅读 AI 写同款· GEO 优化 ›

Cartographer参数调优指南：如何用Lua配置解决建图漂移问题本文深入解析Cartographer SLAM系统的Lua参数调优方法，针对建图漂移问题提供完整解决方案。从运动滤波、扫描匹配到多传感器融合，详细讲解关键参数配置技巧，并给出仓库物流和服务机器人等典型场景的优化方案，帮助开发者实现精准建图。阅读详情

作者：付祥

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

本文来源：原创投稿

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

现象

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

[root@mysql-slaver ~]# top
top - 13:45:43 up 1835 days, 20:52,  2 users,  load average: 0.02, 0.03, 0.05
Tasks: 210 total,   1 running, 208 sleeping,   1 stopped,   0 zombie
%Cpu(s):  0.5 us,  0.6 sy,  0.0 ni, 98.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 32780028 total,   905684 free, 19957900 used, 11916444 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3448260 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                            
 2677 mysql     20   0   20.1g  15.1g   3392 S   0.0 48.2 430:17.58 mysqld                                                             
10549 polkitd   20   0 3277476   3.1g    632 S   0.3  9.9 146:47.24 redis-server                                                       
18183 root      20   0  877308 215868   1892 T   2.7  0.7   2736:45 xxxxxx
  442 root      20   0  160244  93016  88552 S   0.3  0.3 314:14.86 systemd-journal                                                    
32537 root      20   0  731620  58360  54588 S   0.3  0.2  29:09.61 rsyslogd

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

分析

执行 free 命令进一步查看：

[root@MySQL-slaver ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:          32011       19490         881        8762       11639        3366
Swap:             0           0           0

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

shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo, available on kernels 2.6.32, displayed as zero  if  not  avail‐
              able)

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

[root@MySQL-slaver ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G   16K   16G   1% /dev/shm
tmpfs            16G  8.6G  7.1G  55% /run
tmpfs            16G     0   16G   0% /sys/fs/cgroup

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

[root@MySQL-slaver ~]# du -am /run|sort -rn -k1|head -10
8761    /run
7137    /run/systemd
7126    /run/systemd/users
1624    /run/log/journal/89308070e0c04c6a86bf577f4064efca
1624    /run/log/journal
1624    /run/log

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

[root@MySQL-slaver ~]# ls -l /run/systemd/users
total 44
-rw-r--r-- 1 root root 41056 Mar 23 14:14 0

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

[root@MySQL-slaver ~]# find /run/systemd/users|less
/run/systemd/users
/run/systmd/users/0
/run/systemd/users/.#0kRUlqC
/run/systemd/users/.#0Qxvu5J
/run/systemd/users/.#03DvfrF
......

[root@MySQL-slaver ~]# find /run/systemd/users|wc -l
337632

[root@MySQL-slaver ~]# ls -l /run/systemd/users/.#00009iJ
-rw-r--r-- 1 root root 20480 Sep 26  2018 /run/systemd/users/.#00009iJ
[root@MySQL-slaver ~]# ll /run/systemd/users/.#0SEEqoi
-rw-r--r-- 1 root root 20480 Mar 23 14:34 /run/systemd/users/.#0SEEqoi

[root@MySQL-slaver ~]# uptime
 14:45:13 up 1835 days, 21:51,  2 users,  load average: 0.02, 0.08, 0.12

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

[root@MySQL-slaver ~]# less /run/systemd/users/.#03DvfrF

# This is private data. Do not parse.

NAME=root
STATE=active
RUNTIME=/run/user/0
SLICE=user-0.slice
DISPLAY=4231719
REALTIME=1521010223727718
MONOTONIC=79029110787
SESSIONS=4232100 4232099 4232098 ......

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

[root@MySQL-slaver ~]# loginctl list-sessions
   SESSION        UID USER             SEAT            
     24597          0 root                             
    146401          0 root                             
    133160          0 root                             
     82494          0 root                             
     82514          0 root                             
    106049          0 root   
......
[root@MySQL-slaver ~]# loginctl list-sessions|awk '{print $3}'|sort|uniq -c
      1 
      1 listed.
   2131 root
      1 USER

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

[root@MySQL-slaver ~]# loginctl session-status 24597
24597 - root (0)
           Since: Tue 2018-03-27 08:35:01 CST; 4 years 11 months ago
          Leader: 25599
         Service: crond; type unspecified; class background
           State: active
            Unit: session-24597.scope
[root@MySQL-slaver ~]#

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

[root@MySQL-slaver ~]# loginctl session-status 243335
243335 - root (0)
           Since: Sat 2018-07-14 03:29:01 CST; 4 years 8 months ago
          Leader: 28376
         Service: crond; type unspecified; class background
           State: active
            Unit: session-243335.scope
[root@MySQL-slaver ~]#

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

Mar 23 15:20:01 [localhost] CROND[12334]: (root) CMD (sleep 1200)

[root@MySQL-slaver ~]# loginctl session-status 4232206
4232206 - root (0)
           Since: Thu 2023-03-23 15:20:01 CST; 19min ago
          Leader: 12330 (crond)
         Service: crond; type unspecified; class background
           State: opening
            Unit: session-4232206.scope
                  ├─12330 /usr/sbin/CROND -n
                  └─12334 sleep 1200
[root@MySQL-slaver ~]# loginctl session-status 4232206
Failed to get session: No session '4232206' known


[root@MySQL-slaver ~]# lsof -p `pidof dbus-daemon`|grep sessions|wc -l
2126
[root@MySQL-slaver ~]# lsof -p `pidof dbus-daemon`|tail -5
dbus-daem 560 dbus 2139w     FIFO               0,18      0t0  416861417 /run/systemd/sessions/156582.ref
dbus-daem 560 dbus 2140w     FIFO               0,18      0t0  417383549 /run/systemd/sessions/156774.ref
dbus-daem 560 dbus 2141w     FIFO               0,18      0t0  417291412 /run/systemd/sessions/156740.ref
dbus-daem 560 dbus 2142w     FIFO               0,18      0t0  620267085 /run/systemd/sessions/242902.ref
dbus-daem 560 dbus 2143w     FIFO               0,18      0t0  621086290 /run/systemd/sessions/243335.ref
[root@MySQL-slaver ~]#

解决

个人觉得可选解决方案如下：

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处理。

收录于