top - 20:14:48 up 3:50, 14 users, load average: 0.11, 0.07, 0.01
Tasks: 271 total, 1 running, 270 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 29219.0 total, 11881.2 free, 15466.7 used, 1871.1 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 13315.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22408 fancy 20 0 1939288 1.3g 27236 S 0.0 4.7 0:54.23 node
24540 fancy 20 0 1796316 1.2g 26852 S 0.0 4.2 0:35.77 node
26340 fancy 20 0 1701084 1.1g 26816 S 0.0 3.9 0:23.76 node
23238 fancy 20 0 1799560 977.2m 28864 S 0.0 3.3 3:33.66 node
31380 fancy 20 0 1398740 859612 26588 S 0.0 2.9 0:22.56 node
24790 fancy 20 0 1462860 300348 34624 S 1.0 1.0 1:39.24 node
9485 systemd+ 20 0 1312000 207576 19056 S 0.0 0.7 0:11.86 mysqld
963 Debian-+ 20 0 3837356 196252 93012 S 0.0 0.7 0:32.77 gnome-shell
23193 fancy 20 0 1002800 180660 27656 S 0.0 0.6 0:05.43 gulp serve
9028 root 20 0 2638748 126656 47920 S 0.3 0.4 1:33.09 dockerd
9613 root 20 0 836084 117188 27760 S 0.0 0.4 0:02.63 node
24551 fancy 20 0 662480 103232 26836 S 0.0 0.3 0:11.79 node
31391 fancy 20 0 665040 96780 26580 S 0.0 0.3 0:06.74 node
26351 fancy 20 0 658384 90828 26800 S 0.3 0.3 0:08.92 node
22419 fancy 20 0 657872 89828 26852 S 0.3 0.3 0:11.09 node
22389 fancy 20 0 695392 79676 28204 S 0.0 0.3 0:09.40 node
10265 root 20 0 563444 76636 64800 S 0.0 0.3 0:00.89 chrome
24378 fancy 20 0 624668 71208 27944 S 0.0 0.2 0:09.08 node
30433 fancy 20 0 623132 68656 28088 S 0.3 0.2 0:06.28 node
26321 fancy 20 0 624668 68288 28136 S 0.3 0.2 0:07.36 node
10328 root 20 0 4724840 63104 50104 S 0.0 0.2 0:00.07 chrome
10310 root 20 0 479184 57416 47052 S 0.0 0.2 0:00.06 chrome
871 root 20 0 1999352 55604 22584 S 0.3 0.2 0:31.49 containerd
1175 Debian-+ 20 0 1886872 54284 40392 S 0.0 0.2 0:00.14 gsd-media-keys
1179 Debian-+ 20 0 1326184 52356 38780 S 0.0 0.2 0:00.17 gsd-power
1209 Debian-+ 20 0 1251796 51872 38440 S 0.0 0.2 0:00.13 gsd-wacom
> free -m
total used free shared buff/cache available
Mem: 29218 15468 11879 17 1871 13313
Swap: 0 0 0
以上是 top 和 free 命令的输出,可以看到 used 内存有 15G,top 命令中可以看到所有进程的 res 加起来也不到 6G,那么其他内存去哪了呢? buff/cache 也只有 1G 多。
PS: 这个机器是一个 KVM 虚拟机
1
fengpan567 2020-12-10 20:27:28 +08:00
total = used + free + cache
|
2
fancy2020 OP @fengpan567 这个没问题,问题是 Used 的 15G 哪里来的
|
3
fengpan567 2020-12-10 20:30:24 +08:00
@fengpan567 看错了,忽略回复吧
|
4
secondwtq 2020-12-10 20:35:30 +08:00 via iPhone
slabtop
|
5
Goldilocks 2020-12-10 20:45:27 +08:00
你是不是调 tcp 的参数了?
|
6
fancy2020 OP ```
Active / Total Objects (% used) : 1860787 / 2297584 (81.0%) Active / Total Slabs (% used) : 61586 / 61586 (100.0%) Active / Total Caches (% used) : 104 / 136 (76.5%) Active / Total Size (% used) : 353336.72K / 458958.50K (77.0%) Minimum / Average / Maximum Object : 0.01K / 0.20K / 23.25K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 1277757 985385 77% 0.10K 32763 39 131052K buffer_head 252392 150714 59% 0.57K 9014 28 144224K radix_tree_node 91904 91440 99% 0.06K 1436 64 5744K anon_vma_chain 65871 65740 99% 0.20K 1689 39 13512K vm_area_struct 64134 46069 71% 0.19K 3054 21 12216K dentry 46322 46322 100% 0.09K 1007 46 4028K anon_vma 45000 44873 99% 0.13K 1500 30 6000K kernfs_node_cache 35968 35968 100% 0.03K 281 128 1124K kmalloc-32 34272 27703 80% 0.04K 336 102 1344K ext4_extent_status 31808 30933 97% 0.25K 994 32 7952K filp 31744 31744 100% 0.01K 62 512 248K kmalloc-8 30044 30044 100% 0.14K 1073 28 4292K ext4_groupinfo_4k 25600 24707 96% 0.06K 400 64 1600K kmalloc-64 23679 22105 93% 0.59K 877 27 14032K inode_cache 23040 23040 100% 0.02K 90 256 360K kmalloc-16 22320 11742 52% 1.05K 744 30 23808K ext4_inode_cache 13552 13552 100% 0.07K 242 56 968K Acpi-Operand 12864 12259 95% 0.50K 402 32 6432K kmalloc-512 9996 9996 100% 0.04K 98 102 392K pde_opener 9664 9664 100% 0.25K 302 32 2416K skbuff_head_cache 8880 8449 95% 0.66K 370 24 5920K proc_inode_cache 8602 8562 99% 0.18K 391 22 1564K kvm_mmu_page_header 8568 7377 86% 0.09K 204 42 816K kmalloc-96 8466 8466 100% 0.04K 83 102 332K Acpi-Namespace 8128 8004 98% 0.12K 254 32 1016K pid 7456 7456 100% 1.00K 233 32 7456K kmalloc-1024 5312 5312 100% 1.00K 166 32 5312K UNIX 5271 5271 100% 0.19K 251 21 1004K kmalloc-192 4935 4935 100% 0.19K 235 21 940K cred_jar 4800 4800 100% 0.06K 75 64 300K kmem_cache_node 4590 4590 100% 0.05K 54 85 216K ftrace_event_field 4485 4485 100% 0.69K 195 23 3120K sock_inode_cache 4480 4480 100% 0.07K 80 56 320K eventpoll_pwq 4256 4101 96% 0.12K 133 32 532K kmalloc-128 3969 3969 100% 0.38K 189 21 1512K kmem_cache 3808 3542 93% 0.25K 119 32 952K pool_workqueue 3720 3720 100% 1.06K 124 30 3968K signal_cache 3366 3366 100% 0.12K 99 34 396K jbd2_journal_head 3240 3240 100% 1.06K 108 30 3456K mm_struct 3151 2971 94% 0.69K 137 23 2192K shmem_inode_cache 3072 3072 100% 0.03K 24 128 96K dnotify_struct 2928 2774 94% 2.00K 183 16 5856K kmalloc-2048 2323 2323 100% 0.69K 101 23 1616K files_cache 2040 2040 100% 0.02K 12 170 48K numa_policy 2016 1982 98% 4.00K 252 8 8064K kmalloc-4096 1952 1785 91% 0.25K 61 32 488K kmalloc-256 1816 1784 98% 3.81K 227 8 7264K task_struct 1770 1770 100% 2.06K 118 15 3776K sighand_cache 1748 1748 100% 0.09K 38 46 152K trace_event_file 1536 1536 100% 0.03K 12 128 48K fscrypt_info 1530 1530 100% 0.08K 30 51 120K inotify_inode_mark 1323 1323 100% 0.38K 63 21 504K mnt_cache 1152 1152 100% 0.06K 18 64 72K i915_dependency 1024 1024 100% 0.02K 4 256 16K jbd2_revoke_table_s 1020 1020 100% 0.05K 12 85 48K fscrypt_ctx 949 949 100% 0.05K 13 73 52K Acpi-Parse 876 876 100% 0.05K 12 73 48K mbcache ``` @secondwtq here you go |
7
fancy2020 OP 这个问题其实是想问:Used 是不是应该等于所有 RES 之和?
|
8
tomychen 2020-12-10 21:28:06 +08:00
Private | Shared
1 | 2 Anonymous . stack | . malloc() | . brk()/sbrk() | . POSIX shm* . mmap(PRIVATE, ANON) | . mmap(SHARED, ANON) -----------------------+---------------------- . mmap(PRIVATE, fd) | . mmap(SHARED, fd) File-backed . pgms/shared libs | 3 | 4 The following may help in interpreting process level memory values displayed as scalable columns and dis‐ cussed under topic `3a. DESCRIPTIONS of Fields'. %MEM - simply RES divided by total physical memory CODE - the `pgms' portion of quadrant 3 DATA - the entire quadrant 1 portion of VIRT plus all explicit mmap file-backed pages of quadrant 3 RES - anything occupying physical memory which, beginning with Linux-4.5, is the sum of the following three fields: RSan - quadrant 1 pages, which include any former quadrant 3 pages if modified RSfd - quadrant 3 and quadrant 4 pages RSsh - quadrant 2 pages RSlk - subset of RES which cannot be swapped out (any quadrant) SHR - subset of RES (excludes 1, includes all 2 & 4, some 3) SWAP - potentially any quadrant except 4 USED - simply the sum of RES and SWAP VIRT - everything in-use and/or reserved (all quadrants) top 的计算方法还挺复杂 比较笼统的算,应该是 RES + SHR |
9
aysfk 2020-12-10 21:36:31 +08:00 via Android
@fancy2020
个人理解,应该不是,RES 通常占了 Used 大部分,cat /proc/meminfo 有更多数据 |
10
hatebugs 2020-12-10 23:01:55 +08:00 via Android
shared mem 占用的
|
11
laminux29 2020-12-11 00:26:32 +08:00
由于开源系统的复杂性,每款工具软件的统计算法都不同,统计出来的结果,会有一些小差异。
比如 top/htop/slabtop/cat /proc/meminfo 都不一样。 如果你是来规划或监控内存使用量的,我觉得小差异不需要去过度关注。 |
12
fancy2020 OP @laminux29 主要是感觉不是小差异,差了感觉好几个 G 呢。我这个机器现在一开机就占用 8/9 个 G,所以今天才想找出到底是啥在占用
|
13
laminux29 2020-12-11 01:27:24 +08:00 1
@fancy2020 尴尬了,这是个 X-Y 问题。
你想问的是 X,但你写的问题却是 Y 。 这不是个好习惯,建议你下次问问题,直接问 X 。 针对你的真正问题(想找出到底是啥在占用),给你几个建议: 1.htop 以 tree 方式展开,观察一下。不一定有用,但快捷。 2. https://stackoverflow.com/questions/131303/how-can-i-measure-the-actual-memory-usage-of-an-application-or-process 3.我自己的方法比较复杂,我会在虚拟化系统上,新建一台相同配置的虚拟机,然后手动一步一步从头开始安装,直到安装到当前配置。每安装一步,就做个快照。 比如,装完 OS 做个快照,配置完 OS 做个快照,装下一个软件后做个快照,配置完刚才安装好的软件后又做个快照。 这样子,你总会发现,在某一步骤后,重新开机,物理内存使用率突然暴涨。 这时,你就可以基于快照,重新调整整个安装操作步骤,要不改个配置参数,要不换个软件,等等。有快照,就是方便。 4.如果还不行,那就只有使出 bat 项目级的 debug 手段了,更复杂。 那就是从系统开始,每个软件都已源码 debug + 性能监控模式运行。在 load/reload 、new/delete 、malloc/free 等位置插入性能检测点,检测内存,这样能彻底找到问题,不过这种方法太麻烦了,工作量是团队级别的,一个人要做完基本不可能。 |
14
vk42 2020-12-11 03:50:54 +08:00
lz 提供的信息不够啊,至少说明下跑了什么服务吧,某些情况下光算 userland 内存占用不全。另外看起来这 VM 目的是跑后端服务的?那要 gnome-shell 做什么?
|
15
dazhangpan 2020-12-11 13:00:37 +08:00
meminfo 看一下是不是大页内存占用了
|