clangd + youcompleteme +vim

win7 x64 就有 patch guard 了，绕过 PG 的方案有很多，但是出一个死一个
一定要做内核防护的话，内核提供了很多 callback，可以驱动注入去做 callback 检测，但是点比较少，比如 object callback

另外，还有一条万能的路，走虚拟化，在 host 上 hook vm，参考 360 他们的做法

当然，你可以把 PG 关掉，这个方案搜一把就一大堆了

意思就是说，内核很多报错，不是所有场合都和你理解的那个 errno 的字面意思一样

NO space left on device 未必是真的 no space left，可能只是某个抽象资源用完了

no mem 也是一个意思

因为内核资源耗尽，统一返回 NOMEM，这个 errno 的语义不限于 MEM，一般是指某种资源

举个例子，你设置 cgroup，如果没设置 memory 允许的 numa node，直接去设置 cpu 的列表，也会返回这个 errno

@baoyexi 补充一点，lock-free 对于 99.99%的代码来说是屠龙之术
一把锁只有没有办法降低冲突了，才会考虑 lock-free，否则优先考虑怎么避免冲突

@baoyexi
mutex 这个东西不要想着去优化锁本身的性能
1. 锁内部的代码，是否足够轻便和必要
2. 锁冲突的路径是不是可以考虑转移，把锁转移到一个数据流更加冷的路径下去

@Lime mutex 自己做的成本很高，这是我不推荐用协程的关键原因，因为没有人知道谁会怎么跑你在你的任务框架上，协程的锁理论需要做锁膨胀才是最优解

调度饥渴就是调度公平问题，考虑一个很经典的场景，N 个人去 xxx 部门开证明，有 M 个步骤，每个步骤都需要串行，最后的结果就是第一个人处处优先，最后一个特别慢，明显这种情况下，最后一个人可能是很不满意的
内核的 cfs 调度其实某些角度就是为了解决这个问题，epoll_wait 的 event，也可能导致类似的问题，我只开个头，你自己思考

1. mutex 的实现太暴力了，有些场景会很糟糕，怎么退化 mutex 是需要考虑的，退化 mutex 以后这个问题就复杂化了
2. 调度优先级也过于暴力，考虑性能比较多，考虑公平性不够，可能出现调度饥渴，另外 task 的亲和性问题貌似没看到太多的处理，计算敏感的场景下，task 的亲和性还是很重要的
3. 准备下配套的 gdb 调试脚本，否则切换协程以后压根没法调试，不是每个人都会去解析那一堆的上下文的
4. 一个 epoll 大概率是不够的，epoll 在某些场景下性能退化很严重的，有些东西比较糟心

抛开这些，代码质量还是不错的
不过我还是不推荐玩这种东西，受限太严重了，需要性能的时候，一切都需要自己控制，不需要的时候，golang 的那套足够覆盖了

监控本质是解决问题的，如果说监控解决不了问题，只是为了做一套完整的方案而做监控
那么监控的意义是不存在的
普罗米修斯那套东西之所以只是基础设施，就是因为他没有办法去解决业务上的问题

这就是典型的把手段当做了目的，我做了监控，我的任务完成了，但是其实任务的核心是——解决线上已经存在的，或者可能存在的问题，聚焦没聚焦好

所以吐槽和被吐槽的同时，不妨思考下，自己做的东西到底解决了啥问题，而不是，我出于好心，所以需要有好报

监控的核心在
1. 什么数据值得采集
1) 业务、内核 软抽象资源，比如文件打开个数上线，tcp 的 backlog
2) 通用硬件资源的抽象，比如 cpu 内存 io 带宽
3) 服务质量抽象，比如各种请求的延迟，队列长度
4) 各种错误的感知，各种事件的感知，比如 java 触发了一次 gc，操作系统触发了一次 recliam，业务触发了一次 xxx
2. 数据的采集成本是什么
xxx 数据读的成本是多少，比如 win 下的 createsnapshot 成本有多高，适合多少秒采集一次，linux 下遍历 /proc 的成本是啥（ proc 可不是真的内存文件）
3. 怎么呈现数据让人可以快速找到问题所在，这里的核心是怎么整理排查问题的思路，让有关联性的数据在一起，但是不能乱做时序上的关联

RPS RFS 这一堆得东西，内核都是 hash...未必有收益
内核默认不开是有道理的

至于 si 打满，rps 和 rfs 基本对 si 没啥影响，更多是影响 sys
如果你的问题是 si 打满的话，irq balance 干掉，直接多网卡队列分散绑核就是了...
如果遇上多网卡队列还是不均衡，去调网卡的 hash 算法，看看 ethtool 显示你的网卡支持多少不同的 hash 算法

@baicheng10 这个事做过类似的，发现 GP 异常了，发现是 AVX 指令集没对齐，然后看代码没啥问题，发现是 gcc bug，当然最后解决方式就多了

llvm sanitizer

@tempdban 简历发下 [email protected] ？

@tempdban 阿里云 rds 有兴趣么？

@realpg 去微博上 @宫一鸣

@Zhuozhuo 最近有朋友想回成都，留个联系方式？

mmap 更慢，多想想就知道，page fault 明显更多了，而且是 major page fault

trim 了解下，ssd 需要 trim，erase 和 gc 很耗时

@duanhui8 你没明白我啥意思, 通过 socket 去做队列, 不写队列那么复杂的东西了, 当然, 几万的 tps, 你就是 stl 加锁, 性能也毫无问题, 不要小看现在的 cpu...

直接 libevent, consumer 监听一个本地的 unix domain sock, 所有的 producer 连接 unix domain sock, 然后往里面写, consumer 负责从里面读, 读出来以后, 写到后端 db, 怎么会增加数据库的性能压力...

当然,你就是 stl + lock 也毫无问题, 不要过早优化, 不要过早优化, 不要过早优化, 重要的事说三次, 在你没有压测之前, 把各种乱七八糟的东西都丢掉! 简单的 lock 可以解决 99%的问题, 特别是啥 spinlock 和 lockless lockfree, 把他们当彻底忘记掉, 他们没有意义, 除非你要 ns 级别的延迟.

我特别特别讨厌各种东西, 上来就是复杂设计, 简单的设计, 测过了才知道, 起码拿着 perf 之类的看过了, 热点到底在哪里, 而不是想当然的各种轮子往上套, 套出一堆复杂得没办法维护的东西出来