高 SLAB 值

Question

目前我的一些 Debian 10 服务器存在问题。几台服务器的 SLAB 使用率极高（大部分 50% 的内存都被 slab 使用）。我不知道问题出在哪里。

也许你们中有人有一个想法？

在顶上

ATOP - mail                                        2019/10/14  13:00:03                                        --------------                                        10m0s elapsed
PRC | sys   31.00s  | user  30.65s |               |  #proc    277 | #trun      1  | #tslpi   728 |  #tslpu     0 | #zombie    0  | clones  1515  |              |  #exit   1396 |
CPU | sys       5%  | user      5% |  irq       0% |  idle    189% | wait      0%  | steal     0% |  guest     0% | ipc     0.95  | cycl   81MHz  | curf 2.10GHz |  curscal   ?% |
cpu | sys       3%  | user      3% |  irq       0% |  idle     94% | cpu000 w  0%  | steal     0% |  guest     0% | ipc     0.96  | cycl   83MHz  | curf 2.10GHz |  curscal   ?% |
cpu | sys       3%  | user      2% |  irq       0% |  idle     95% | cpu001 w  0%  | steal     0% |  guest     0% | ipc     0.93  | cycl   80MHz  | curf 2.10GHz |  curscal   ?% |
CPL | avg1    0.40  | avg5    0.17 |               |  avg15   0.11 |               | csw   556801 |               | intr  272694  |               |              |  numcpu     2 |
MEM | tot    13.7G  | free  247.9M |  cache 619.9M |  dirty   0.1M | buff   43.6M  | slab    7.2G |  shmem 116.1M | shrss   0.0M  | vmbal   0.0M  | hptot   0.0M |  hpuse   0.0M |
SWP | tot     1.9G  | free    0.0M |               |               |               |              |               |               |               | vmcom  13.4G |  vmlim   8.7G |
PAG | scan   17448  | steal  15442 |  stall      0 |               |               |              |               |               |               | swin      12 |  swout   3664 |

板顶

root@mail ~ # slabtop --sort c -o
 Active / Total Objects (% used)    : 29313064 / 29993742 (97,7%)
 Active / Total Slabs (% used)      : 973029 / 973029 (100,0%)
 Active / Total Caches (% used)     : 100 / 125 (80,0%)
 Active / Total Size (% used)       : 7104170,14K / 7271337,84K (97,7%)
 Minimum / Average / Maximum Object : 0,01K / 0,24K / 8,00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
3812863 3799719  99%    0,20K 200677       19    802708K vm_area_struct
198814 198707  99%    3,69K  24857        8    795424K task_struct
2990368 2499431  83%    0,25K 186898       16    747592K filp
270498 270443  99%    2,00K  16907       16    541024K kmalloc-2048
124487 124471  99%    4,00K  15574        8    498368K kmalloc-4096
218567 218515  99%    2,06K  14573       15    466336K sighand_cache
555948 554329  99%    0,66K  46329       12    370632K proc_inode_cache
242424 242169  99%    1,00K  15153       16    242448K kmalloc-1024
7592960 7592441  99%    0,03K  59320      128    237280K kmalloc-32
221220 221172  99%    1,06K  14752       15    236032K signal_cache
218679 218646  99%    1,06K  14581       15    233296K mm_struct
334913 334913 100%    0,69K  14563       23    233008K files_cache
317829 317829 100%    0,69K  13821       23    221136K sock_inode_cache
3406080 3403192  99%    0,06K  53220       64    212880K anon_vma_chain
208568 208542  99%    1,00K  13037       16    208592K UNIX
971355 906067  93%    0,19K  46255       21    185020K dentry

大部分情况下，超过 50% 的内存用于 slab。一周后，oom killer 启动并释放更多内存（在此系统上，在其他系统上，20 小时正常运行后）。

我还研究了打开的网络连接/文件/已删除的文件，但这些值对我来说似乎很正常。

提前致谢，亚历克斯

Answer 1

此主机没有足够的内存用于分配。在调整应用程序和进行容量评估时，请增加内存以防止主机崩溃。

根据 atop 输出中的 free + cache，内存利用率约为 96%。Linux 虚拟内存系统绝对会考虑这种内存压力。因此进行分页也就不足为奇了。

---

您需要进一步说明此机器上的应用程序工作负载，并深入了解其内存分配。Linux 运行各种类型的工作负载，而 slab 分配器具有非常通用的存储桶。

如果您使用 cgroups（例如 systemd），请使用它们查看每个服务的消耗情况。例如，如果 chrony 正在运行（用于 NTP），/sys/fs/cgroup/memory/system.slice/chronyd.service/memory.kmem.slabinfo将包含其 slab 分配。使用 systemd-cgtop 命令重复上述操作，按内存查看排名靠前的 cgroups。

按使用量计算，第二大 slab 是 198,000 个 task_struct 对象。任务表示进程。上面的 277 代表您一次运行多少个任务？您的应用程序或脚本分叉的频率是多少？sighand_cache 听起来像信号处理程序，发送给任务的信号量是多少，它们的处理程序做什么？

使用 Linux perf、ftrace 或 bpf 等工具进行详细分析。请参阅这个问题是关于板坯分析的想法。