Linux或其他什么东西正在吞噬我的RAM吗？内存使用没有加起来

Question

我在服务器故障和linuxatemyram.com上阅读了一些关于内存使用的安静主题，但似乎没有人能深入了解我的机器上正在发生的事情。

    top - 17:42:31 up 8 days, 10:23,  3 users,  load average: 1.16, 1.14, 1.19
Tasks: 344 total,   1 running, 343 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.3 us,  2.4 sy,  0.0 ni, 83.4 id,  0.0 wa,  0.0 hi,  0.8 si,  0.0 st
MiB Mem :  15888.2 total,    600.2 free,  14782.2 used,    505.9 buff/cache
MiB Swap:   8192.0 total,   6647.9 free,   1544.1 used.    673.3 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
3959357 howie     20   0 9290724   3.6g 166112 S  44.2  23.2 817:31.05 java
1479873 howie     20   0   20.7g   4.8g  12140 S  14.6  31.1 881:40.81 java
   1513 root      20   0       0      0      0 S   4.7   0.0 395:04.70 napi/eth%d-385
   1516 root      20   0       0      0      0 S   0.3   0.0  48:38.33 napi/eth%d-386
   2548 unifi     20   0 7867536 526756   4416 S   0.3   3.2  36:21.41 java
   2713 root      20   0  493312   2216   1312 S   0.3   0.0   3:25.22 X
   3285 sddm      20   0 1326628  14908   4932 S   0.3   0.1  10:37.51 .sddm-greeter-w
1239489 root      20   0       0      0      0 I   0.3   0.0   0:00.35 kworker/2:2-events
1332415 howie     20   0   11232   2844   2152 S   0.3   0.0   0:01.09 top
      1 root      20   0  168780   5732   3132 S   0.0   0.0   7:48.99 systemd

我的最高进程使用了55-60%的内存。如果有16/15.5G，我希望有大约6G免费或可用。顶部和免费表示我有大约541 1Gb 1GB的免费。(截图是几分钟后拍摄的。)

              total        used        free      shared  buff/cache   available
Mem:          15888       14477         915          34         495         983
Swap:          8191        1544        6647

有没有人建议如何找出是否有东西在吃我的内存？

cat /proc/meminfo
MemTotal:       16269540 kB
MemFree:          469556 kB
MemAvailable:     681988 kB
Buffers:               0 kB
Cached:           579676 kB
SwapCached:       188676 kB
Active:          7583844 kB
Inactive:        2554720 kB
Active(anon):    7248276 kB
Inactive(anon):  2346652 kB
Active(file):     335568 kB
Inactive(file):   208068 kB
Unevictable:       20576 kB
Mlocked:               0 kB
SwapTotal:       8388604 kB
SwapFree:        6809504 kB
Dirty:               364 kB
Writeback:             0 kB
AnonPages:       9559824 kB
Mapped:           419488 kB
Shmem:             36040 kB
KReclaimable:      79620 kB
Slab:             770456 kB
SReclaimable:      79620 kB
SUnreclaim:       690836 kB
KernelStack:       16696 kB
PageTables:        62508 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    16523372 kB
Committed_AS:   14439856 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      306496 kB
VmallocChunk:          0 kB
Percpu:             2512 kB
AnonHugePages:      2048 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:    12745260 kB
DirectMap2M:     3907584 kB

dmesg显示工作中的oom-杀手(只是显示多个条目中的一个.)

dmesg | grep oom-killer
[174151.082274] dockerd invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0

谢谢

Answer 1

meminfo

是的，您的meminfo报告9.1GB的AnonPages总数为15.5GB。

少量的Shmem和文件页。这与执行大量私有分配的应用程序是一致的，而且实际上您正在运行一些java。注意: java不倾向于为JVM目的直接分配共享内存。与数据库相比，数据库通常有共享内存段，当然还有很多文件I/O。

不，你不能把剩下的都用上。MemAvailable是这方面最有用的估计值，您的估计值相对较低，为0.7GB，即占MemTotal的4%。关于这是什么的上游笔记：

MemAvailable --估计有多少内存可用于启动新应用程序，而不进行交换。根据MemFree、SReclaimable、文件LRU列表的大小以及每个区域中的低水印进行计算。估计数考虑到系统需要一些页面缓存才能正常工作，而且由于正在使用的项目，并不是所有可收回的板子都可以收回。这些因素的影响因系统而异。

因此，实际上可以释放内存，并且可以很容易地从文件缓存和内核对象中回收页面。简单的东西。超过这个大小的新内存分配可能会非常缓慢地直接回收，或者激怒oom杀手。

一些很难从meminfo中回收项目是SUnreclaim、KernelStack和PageTables，总计可能是0.8GB。并非不合理，我倾向于假设一个非平凡大小的主机至少需要一两个GB作为内核。

仍然留下5 GB左右，不容易桶。我猜想它在某个时候已经开始使用了，事情就像进程终止一样发生了变化，而内核还没有完成将它恢复为免费的工作。

容量规划估计

对这个应用程序可以使用多少内存做一些粗略的估计。根据您的经验，它的工作规模大约有多大。

Java的内存使用和限制它的旋钮都有很好的文档记录。这里，一个Red开发人员博客尝试了一下.堆是其中的大部分，但是还有更多：JVM memory = Heap memory+ Metaspace + CodeCache + (ThreadStackSize * Number of Threads) + DirectByteBuffers + Jvm-native

还请注意关于集合的建议。“生产堆的大小应至少比测试的最大值高出25%至30%，以便为开销留出空间。”

容器

我觉得奇怪的是，dockerd和其他进程会命中oom杀手，而不是大型java进程。诚然，oom杀手是基于任意启发式的猜测。

容器可以通过cgroup设置内存使用限制，并对不同组进行调优。此外，还可以准确报告每个cgroup的内存使用情况，系统d系统上的一个很好的工具是systemd-cgtop -m。

检查容器的所有内存相关配置，用于停靠器见资源限制文档。(尽管在码头页面上至少有一件事是不正确的:交换率不是百分比。)

可靠地不运行低内存主机宽可能意味着设置每个容器内存限制。如果它们包含一些java线程，则将最大值设置为超出容量规划估计值的值。

在这里猜测，但可能--oom-kill-disable在一个java容器上。在内存压力下，但大用户受到保护，oom杀手可能会删除主机上的其他系统进程。在某些方面，我更希望它去掉大型java线程，因为管理员JVM内存的提示可能需要与可用内存进行比较。

总的来说，这个主机可能需要更多的内存。可以用它所拥有的来解决问题，但是需要更多的容量规划，更仔细地观察什么在运行，什么限制了他们的资源使用。