我记得之前看过一篇文章，说 kube-proxy 使用 iptables 模式时会有随机丢包的情况出现。建议用 ipvs 模式再测测

别提了，升了 15 之后 iPhone 根本抢不过 Mac 。有天中午掏出 AirPods 玩手机，iPhone 死活连不上 AirPods，一气之下从 Mac 上移除了 AirPods 。对了，macOS 版本是 11.3.1，而且有 bug，系统设置里每次更新系统都失败，改天在 recovery 模式里升级到最新的系统看看效果

Mac 也一样

问一下楼主看完这些大概花了多少时间？

Chrome 的吧。提示过个一两秒就消失了啊，这都忍不了？

@Nitroethane #11 还有个问题，bsonEncode 里的 buff 不能在当前函数 Put，要在 readFileEvents 里把数据发送到 pipe 之后再 Put 。
https://i.imgur.com/HvDAfQe.png

用了 bson 库封装的 BSONValueWriterPool 对象池之后直接起飞，内存占用直接降到 1.5M 以下，而且内存分配操作次数的平均值为 9 到 10 次。
https://i.imgur.com/t9YuIbs.png

@Nitroethane #8 突然发现有个致命 bug，不应该在 compressFile 函数里就把 buff 给 Put，应该在 handleEvent 的 return 语句前面用 defer 给 Put 掉

@tuxz #39 求问这是什么软件生成的图片？

其实最优解应该是根据文件大小选择最合适的 bytes.Buffer，但是 sync.Pool 不支持这种操作。如果自己手动先 get，判断 buffer 大小再 put 的话，感觉会影响 GC 导致更严重的性能问题

重构了下 handleEvent 函数。这是根据压测结果来看目前性能最好的状态：
https://i.imgur.com/0fnwGB0.png
下面是三次压测结果，测试 5000 个文件，每个文件大小在 1M 以内。第一次结果是 bytes.Buffer 和 flate.Writer 都不使用 sync.Pool ；第二次压测结果是 bytes.Buffer 使用 Pool，flate.Writer 不使用；第三次是两个都使用 Pool 。
https://i.imgur.com/qSKrrSo.png
还有一个优化点是使用 bson.Marshal 方法序列化结构体。因为对这个库不是很熟悉，用了 Encoder 之后性能直接回到解放前。还需要再研究下

@GopherDaily #6 不是，readFileEvents 方法是长期运行的，被调用很多次的是 handleEvent 函数。
其实问题出在 gzBuff 和 zw 两个变量上。这两个变量的生命周期和 readFileEvents 方法是相同的。假如随着程序的运行，要处理的文件越来越大，那么 gzBuff 和 zw 这两个变量的底层 byte slice 也会越来越大，而且不会被 GC 回收，byte slice 也不会自动收缩。所以随着运行时间内存使用量会持续增长。

@darrh00 #4 我这句话是有问题…… 不过不用 sync.Pool 的话问题还存在……

@darrh00 #1 对，entry 没必要用 sync.Pool 。不用 sync.Pool 的话问题依然存在。刚在 handleEvent 函数里加了一行，退出函数前执行 w.Flush()，也没用。
看了下代码，对 gzBuff 底层数组引用的地方只有 entry.FileContent 和 buff，但是函数开始时都执行 Reset 了，不应该还占用呀


@lysS #2 这么明显的内存单位怎么能是 CPU 的图🐶

对这玩意太熟悉了，我是搞安全的，上家公司是外企，用的就是 crowdstrike falcon 。

@xiaoding #2 Mac 上不清楚，反正 windows 上对用户来说无感知，只有后台进程，终端上没有 GUI，而且就算终端有违规操作，例如执行了恶意软件，只会静默地阻止，只有后台 dashboard 才能收到报警。

就像楼上说的，它就是一 hips，监控终端的所有流量（包括访问过哪些 IP 、所有的 DNS 解析记录、访问过哪些网站）、检测扫描文件的安全性、上传终端的所有系统日志、拦截恶意软件的执行等等。不过这玩意是真的强，能检测出国内大部分流氓软件。

还有就是 crowstrike 提供的“增值服务”，他们会定期评估客户的整体安全性，会在每台终端上运行一个一次性的检测工具。这玩意会扫描整个硬盘，看你安装了哪些违规软件，有没有明文存储密码，有没有恶意软件等等。

@Aumujun 第一，你的 defer 放在错误处理前面就是有问题。第二，我跑了一下你的代码，ioctl 调用报错，但是 close 没有问题

还有，现在都用 netlink

close 返回 EBADF 说明你要关闭的文件描述符是一个无效的文件描述符。你的代码有问题，关闭 fd 的 defer 应该放到错误处理的后面，因为如果 unix.Socket() 调用失败的话，fd 的值就是一个无效的文件描述符，你关闭它当然返回 EBADF