我的笔记本电脑内存很大（32GB），但仍然有可用内存不足的问题。我使用的是 Linux（Fedora 27），重启后一段时间就会出现这种情况。
如果你检查空闲输出，会发现内存看起来正常，并且有 19Gb 的缓存内存，理论上应该可以根据需求释放：
# free -h
total used free shared buff/cache available
Mem: 30G 10G 419M 768M 19G 624M
Swap: 999M 999M 280K
但是我尝试启动应该获得 2Gb 内存的虚拟机却出现“无法分配内存”的情况。
查看 cat /proc/meminfo 发现大部分缓存内存都到了 Slab - SUnreclaim 点：
# cat /proc/meminfo
MemTotal: 32310876 kB
MemFree: 387332 kB
MemAvailable: 624464 kB
Buffers: 15120 kB
Cached: 1379140 kB
SwapCached: 7316 kB
Active: 10350772 kB
Inactive: 1330164 kB
Active(anon): 10028184 kB
Inactive(anon): 1085388 kB
Active(file): 322588 kB
Inactive(file): 244776 kB
Unevictable: 900 kB
Mlocked: 900 kB
SwapTotal: 1023996 kB
SwapFree: 0 kB
Dirty: 3940 kB
Writeback: 0 kB
AnonPages: 10280264 kB
Mapped: 761148 kB
Shmem: 827040 kB
Slab: 19615756 kB
SReclaimable: 80356 kB
SUnreclaim: 19535400 kB
KernelStack: 30272 kB
PageTables: 161940 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 17048360 kB
Committed_AS: 28120088 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 128
HugePages_Free: 128
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 262144 kB
DirectMap4k: 15651468 kB
DirectMap2M: 17266688 kB
DirectMap1G: 1048576 kB
检查slabtop，发现大部分消耗到了kmalloc-2048：
# slabtop -o
Active / Total Objects (% used) : 10959485 / 11158942 (98,2%)
Active / Total Slabs (% used) : 653007 / 653007 (100,0%)
Active / Total Caches (% used) : 112 / 134 (83,6%)
Active / Total Size (% used) : 19572995,47K / 19615517,82K (99,8%)
Minimum / Average / Maximum Object : 0,01K / 1,76K / 23,12K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
9692082 9692082 100% 2,00K 623116 16 19939712K kmalloc-2048
218790 218790 100% 0,02K 1287 170 5148K avtab_node
120140 116705 97% 0,20K 6007 20 24028K vm_area_struct
106794 47394 44% 0,04K 1047 102 4188K Acpi-Namespace
103936 103832 99% 0,01K 203 512 812K kmalloc-8
99200 92297 93% 0,03K 775 128 3100K kmalloc-32
89024 85587 96% 0,06K 1391 64 5564K pid
88320 87190 98% 0,02K 345 256 1380K kmalloc-16
70476 40684 57% 0,19K 3356 21 13424K dentry
64576 40757 63% 0,06K 1009 64 4036K kmalloc-64
52210 50218 96% 0,09K 1135 46 4540K anon_vma
43200 36795 85% 0,25K 1350 32 10800K filp
40960 35936 87% 0,02K 160 256 640K selinux_file_security
37950 37731 99% 0,13K 1265 30 5060K kernfs_node_cache
32200 21252 66% 0,57K 1150 28 18400K radix_tree_node
23556 21252 90% 0,59K 906 26 14496K inode_cache
23409 13952 59% 1,06K 855 30 27360K ext4_inode_cache
20224 20014 98% 0,06K 316 64 1264K ebitmap_node
19530 15676 80% 0,09K 465 42 1860K kmalloc-96
19210 10443 54% 0,05K 226 85 904K ftrace_event_field
13398 7867 58% 0,75K 638 21 10208K xfrm_state
13216 13117 99% 0,07K 236 56 944K Acpi-Operand
11949 11689 97% 0,19K 569 21 2276K kmalloc-192
10569 8405 79% 0,10K 271 39 1084K buffer_head
10404 10404 100% 0,04K 102 102 408K ext4_extent_status
9775 6827 69% 0,70K 425 23 6800K shmem_inode_cache
9472 7628 80% 0,12K 296 32 1184K kmalloc-128
8823 8823 100% 0,08K 173 51 692K Acpi-State
6528 5762 88% 0,03K 51 128 204K avc_xperms_data
5616 4745 84% 0,50K 177 32 2832K kmalloc-512
5250 4268 81% 0,19K 250 21 1000K cred_jar
5110 5110 100% 0,05K 70 73 280K mbcache
4488 3876 86% 0,66K 187 24 2992K proc_inode_cache
3904 3017 77% 0,06K 61 64 244K kmem_cache_node
3808 3808 100% 0,14K 136 28 544K ext4_groupinfo_4k
3542 3369 95% 0,69K 154 23 2464K sock_inode_cache
3532 2875 81% 1,00K 113 32 3616K kmalloc-1024
3296 3021 91% 0,25K 103 32 824K kmalloc-256
3232 3232 100% 0,12K 101 32 404K seq_file
3162 3162 100% 0,04K 31 102 124K pde_opener
3040 2540 83% 0,25K 97 32 776K skbuff_head_cache
2968 2968 100% 0,07K 53 56 212K eventpoll_pwq
2784 2746 98% 1,00K 87 32 2784K UNIX
2618 2518 96% 0,12K 77 34 308K jbd2_journal_head
2496 2392 95% 0,25K 78 32 624K proc_dir_entry
2432 2432 100% 0,12K 76 32 304K secpath_cache
2192 2103 95% 7,88K 551 4 17632K task_struct
2024 1852 91% 0,09K 44 46 176K trace_event_file
1950 1783 91% 1,06K 65 30 2080K signal_cache
1768 1768 100% 0,12K 52 34 208K cfq_io_cq
1638 1638 100% 0,10K 42 39 168K blkdev_ioc
1530 1530 100% 0,23K 46 34 368K posix_timers_cache
1512 864 57% 0,38K 72 21 576K kmem_cache
1368 1368 100% 0,16K 57 24 228K kvm_mmu_page_header
1300 616 47% 0,31K 52 25 416K nf_conntrack
1040 1040 100% 1,19K 40 26 1280K mm_struct
1036 955 92% 2,06K 70 15 2240K sighand_cache
为什么它这么大，有没有办法在不重启的情况下清除它？
答案1
这对于 Unix/Linux/BSD 来说是正常的。当您出于任何原因从磁盘读取页面时，它们会被塞入缓存并留在那里。如果您需要内存，则可以使用，但释放内存需要开销，如果您再次需要同一个磁盘，则不必再次将其读入内存。注意到您的 Buff/Cache 是 19G 吗？实际上只有 10G 正在使用。如果内存耗尽，您的系统将开始使用 SWAP，并且一切都会变慢，具体取决于您的 SWAP 设备的速度。那么你就有问题了。
答案2
您的可用内存或“Ram”较低（0.6 GB） 一、问题可能由于系统 BIOS 过时而发生（不太可能） 在 BIOS 菜单中应用默认设置 在 BIOS 菜单中转到高级选项卡，然后是性能，如果启用了超频，请禁用 xmp（极端内存配置文件），或禁用超频。然后查看可用内存是否增加。二、我建议使用命令限制内存使用set-property。在终端类型中systemd-cgls，输出显示控制组层次结构。确定哪个“session-*.scope”（例如：session-3.scope）然后输入
systemctl set-property session-3.scope MemoryLimit=15G
重启
再次查看可用内存是否增加，如果有效，请访问在此处输入链接描述