其实从阿里云监控数据显示，内存占用是逐步上涨的，大概每 5 分钟上涨 0.01%（~0.7m ），所以我最初的调查方向都是以内存泄露为主 [捂脸]

@XiaoxiaoPu #6 嗯哈，昨晚我也看到了 https@@@zhuanlan.zhihu.com/p/25241630 这篇文章里的讲解，结合我的实际情况（绝大多数是每隔 20s 的 ping/pong 心跳，服务端直接响应 pong，不做任何处理）考虑，我觉得 socket 应该不会暂存这么多的数据。昨晚升级了服务器，现场数据已经没了 [捂脸] ，不过今天看了下，大致是能对的上了。以下是 slabtop 的数据，看起来 socket 其实也没有那么大？

```plain
Active / Total Objects (% used) : 381214 / 384110 (99.2%)
Active / Total Slabs (% used) : 14068 / 14068 (100.0%)
Active / Total Caches (% used) : 73 / 101 (72.3%)
Active / Total Size (% used) : 136913.44K / 137986.20K (99.2%)
Minimum / Average / Maximum Object : 0.01K / 0.36K / 8.00K

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
75054 74990 99% 0.19K 3574 21 14296K dentry
46956 46956 100% 0.10K 1204 39 4816K buffer_head
32832 32553 99% 0.06K 513 64 2052K kmalloc-64
23472 23296 99% 0.66K 978 24 15648K proc_inode_cache
21808 21455 98% 0.25K 1363 16 5452K kmalloc-256
21392 21261 99% 0.07K 382 56 1528K avc_node
21024 20410 97% 0.12K 657 32 2628K kmalloc-128
19900 19713 99% 0.62K 796 25 12736K sock_inode_cache
19710 19513 99% 2.06K 1314 15 42048K TCPv6
16286 16286 100% 0.12K 479 34 1916K kernfs_node_cache
14283 14283 100% 0.58K 529 27 8464K inode_cache
11744 11744 100% 1.00K 734 16 11744K ext4_inode_cache
11424 11424 100% 0.04K 112 102 448K selinux_inode_security
5418 5418 100% 0.21K 301 18 1204K vm_area_struct
4864 4864 100% 0.02K 19 256 76K kmalloc-16
4096 4096 100% 0.01K 8 512 32K kmalloc-8
3500 3500 100% 0.57K 125 28 2000K radix_tree_node
3366 2613 77% 0.08K 66 51 264K anon_vma
3315 3315 100% 0.05K 39 85 156K shared_policy_node
3264 3264 100% 0.04K 32 102 128K ext4_extent_status
1792 1792 100% 0.03K 14 128 56K kmalloc-32
1785 1785 100% 0.19K 85 21 340K kmalloc-192
1722 1722 100% 0.09K 41 42 164K kmalloc-96
1584 1584 100% 1.00K 99 16 1584K kmalloc-1024
1184 1079 91% 0.50K 74 16 592K kmalloc-512
1080 1080 100% 0.11K 30 36 120K jbd2_journal_head
912 912 100% 0.66K 38 24 608K shmem_inode_cache
680 680 100% 0.02K 4 170 16K fsnotify_mark_connector
567 567 100% 0.19K 27 21 108K cred_jar
544 544 100% 0.12K 17 32 68K pid
540 540 100% 0.11K 15 36 60K task_delay_info
```

@kele1997 #5 可能是我没表达清楚，我的想法是，这台机器只运行了一个 java 程序，在 top 里显示 RES 为 5g，但是 free 里显示已用 6.8g 。然后根据 1 楼所说我去查了相关资料，现学现卖发现还是会有 1g 的内存出入（ slab 等加上 5g 之后）

在 free 和 top 里显示的差距应该部分缓存导致的，我想表达的是在 top 或者 free 里看到的内存占用与实际进程相加相差过大的问题

@XiaoxiaoPu @nuk 感谢，学到了新知识！根据 http://linuxperf.com/?p=142 这篇文章所说，我计算了下 meminfo 里的统计数据，还是有些会对不上，按文章所说，差的大概 1g 内存可能是因为 alloc_pages/__get_free_page 分配的？

@msg7086 根据 https://zhuanlan.zhihu.com/p/25241630 这篇文章，就算 1 个 tcp 连接占用 8k 内存，2w 个连接也不过 150M 左右 [捂脸]

我有点疑惑的是不知道堆外内存会不会被统计到 RES 中，因为从网上一些内存泄露的排查过程中有提到 zip 压缩的问题（ https://www.cnblogs.com/aipaojiao/p/13680207.html ），而在实际项目中是有用到 websocket 的 permessage-deflate 扩展的（ https://tools.ietf.org/html/rfc7692 ）

```plain
// 去掉了为 0KB 的字段
MemTotal: 7733012 kB // 7551.78M
MemFree: 215988 kB // 210.93M
MemAvailable: 280524 kB // 273.95M
Buffers: 28368 kB // 27.70M
Cached: 225080 kB // 219.80M
Active: 5467844 kB // 5339.60M
Inactive: 111284 kB // 108.68M
Active(anon): 5325980 kB // 5201.15M
Inactive(anon): 236 kB // 0.23M
Active(file): 141864 kB // 138.54M
Inactive(file): 111048 kB // 108.45M
Dirty: 440 kB // 0.43M
AnonPages: 5325680 kB // 5200.86M
Mapped: 46940 kB // 45.84M
Shmem: 536 kB // 0.52M
Slab: 143460 kB // 140.10M
SReclaimable: 64056 kB // 62.55M
SUnreclaim: 79404 kB // 77.54M
KernelStack: 6816 kB // 6.66M
PageTables: 15420 kB // 15.06M
CommitLimit: 3866504 kB // 3775.88M
Committed_AS: 5697572 kB // 5564.04M
VmallocTotal: 34359738367 kB // 32768G
VmallocUsed: 20152 kB // 19.68M
VmallocChunk: 34359712252 kB // 32767.98G
Percpu: 704 kB // 0.69M
AnonHugePages: 4769792 kB // 4658M
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB // 2M
DirectMap4k: 66232 kB // 64.68M
DirectMap2M: 3848192 kB // 3758M
DirectMap1G: 4194304 kB // 4096M
```

不如直接把电池拔了？直接插电使用？

我想知道有多人（ goroutine ）协作嘛

小程序你不维护了，那我们的数据咋办 https://i.v2ex.co/6qkEmGZF.png

@hjc4869 #9 感谢科普 https://i.v2ex.co/W979C9Ry.png

@hjc4869 #7 B 站一个 UP 好像有提到这个问题，Matlab 使用的 Intel MKL 库进行矩阵运算的，而 Intel 肯定不可能去给 m1 做适配，所以这似乎是一个理由？

iPhone12 按照第一种方式，WiFi/蓝牙 /蜂窝网络全开，但是是单卡，12 点半到 7 点 40，还是 100%

好像没碰到，一直用的九键，没出现楼上卡死的情况= =

自己编译的东西习惯全放到 /usr/local/xxx 里，比如 nginx 的主目录就是 /usr/local/nginx，然后配置文件在 /usr/local/nginx/conf，然后直接 ln 二进制到 /usr/local/bin 里，优点是想删除直接删整个目录就好，没什么残留

iphone6 还没坏，感觉还可以再服役一年，咋就这么难坏（笑哭

60 不是正常温度么？

实际项目中在 websocket 上使用过 swoole，坑点还是有不少，选择的原因是着急上线+需要对接业务是 php 的。

碰到的坑点有 Table 需要传入 capacity，超出就删已有数据，可能还有实际容量达不到 capacity 指定的数量的问题。隐约记得还有内存可见性问题，通过 Timer 创建的任务不能访问到链接信息问题。最严重的还是一次莫名的线上事故，整个进程完全阻塞，呆呆的停在那里= =，coredump 之后紧急重启了，事后分析堵塞在 epoll_wait 上，具体就没细看了，加了个班直接迁移到 golang 上了= =

@leishi1313 #2

了解了下 mongorepo，涨姿势了。

感觉比较适合都是技术栈的项目，我这边部分服务是采用 go 写的，部分是 java，在一个 repo 里维护的话，感觉不是非常合适，感谢~

@zhanchong316p #1

每个服务单独维护一个 proto 的 repo，生成的 java 文件也会放在和 proto 文件一个 repo 嘛？我这边因为有部分服务是 go 部分是 java，所以怎么维护 proto 文件是个头疼问题

报警靠谱，表达方式可以注意下，就说是非法入室，不认识他们