2018-08-21: 内存升到44G了,看不下去了,决定手动清理
1
2
| sync
echo 2 > /proc/sys/vm/drop_caches
|
又看了很多文章,每打开一个文件就会增加 dentry 这个程序有大量的 Curl 请求以及多进程的任务组。这个应该就是问题了吧。
项目服务器是 8H64G 的 EC2,因为项目数据量很大,监控程序一直显示真实内存占用在 47G 左右,本以为是Mysql占用过大导致的。htop图显示如下:
图中显示 Mysql 内存占用 2.1%,但是出现了很多列,肤浅的我错误的认为这些都是 Mysql,以 n*2.1 来计算 Mysql 的占用,经过V2er们的指点,得知了在 htop 中默认是以线程展示数据的,Mysql是多线程程序,多个线程之间的内存是共享的,通过 H 指令切换到非线程模式。
内存占用最高的还是 Mysql 不过他的内存占用也只有 2.4%。但是内存使用显示已经用了 48G 的内存。
首先有人提到了 tmpfs ,系统分配了 31G 的 tmpfs,本以为确实是这里占用掉了内存,但是查完资料发现 tmpfs 不使用的话是不会占用内存的,有人让我贴出了 cat /proc/meminfo：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| cat /proc/meminfo
MemTotal: 62919396 kB
MemFree: 2228000 kB
MemAvailable: 60639408 kB
Buffers: 327824 kB
Cached: 10384060 kB
SwapCached: 0 kB
Active: 8945140 kB
Inactive: 3568212 kB
Active(anon): 1801992 kB
Inactive(anon): 9432 kB
Active(file): 7143148 kB
Inactive(file): 3558780 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 76 kB
Writeback: 0 kB
AnonPages: 1801496 kB
Mapped: 52352 kB
Shmem: 9940 kB
Slab: 48031092 kB
SReclaimable: 47962884 kB
SUnreclaim: 68208 kB
KernelStack: 3376 kB
PageTables: 14700 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 31459696 kB
Committed_AS: 3442324 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
AnonHugePages: 26624 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 12288 kB
DirectMap2M: 63987712 kB
|
这位朋友提出了 “Google Slab 占用高” 的建议,通过 Google 得到了 slabtop 这条命令执行之后发现占用最高的是 dentry, google 后得到了这篇文章 记一次内存使用率过高的报警 从文中得知 nss-softokn 的 bug 导致 curl 大量请求后, dentry 缓存飙升
服务器的监控模块,第三方接口对接的实现都是根据 curl 实现的,curl 的使用确实很多。 根据文中的方法进行排查与修复,当时内存占用还是在 47G ,因为dentry是会自动清理的,所以没有进行手动了清理。现在内存使用已经下降到了 36G。
通过这次事件,深深的感受到了没有运维的痛苦之处,毕竟不是专业搞运维的。当然,下次遇到同样的情况的话也就会往这方面考虑了,遇到问题,解决问题,理解问题,在问题中得到提升。当然,再次感慨社区的力量与人性的善。