[程序员] 技术支持里的大宝藏

最近半个月忙一个现场问题，终于在十一前有了明确的答案，可以高兴渡个假期。从中学到了不少的知识，感觉像是发现了个大宝藏！有些放到了公众号，有些放到了CSDN个人专栏。

最终的分析是，在现场使用了perf抓到了问题点。建议大家，如果在本地相同的环境使用perf没有问题的时候，还是需要使用perf来分析比较困难的现场问题，对CPU的消耗不大，最多也就是3~5%的CPU消耗。关键是抓到的信息有非常高的价值，对问题分析很有帮助。当然也得是对口的问题！

大体的问题是，现场使用的TCP socket量比较大，最终导致分配的内存超过了tcp_mem里的hard limit。此时socket，在epoll_wait的情况下，还是会有write事件可用，也就是从内核得到的信息是可以执行发送操作，但是因为内存到极限，分配不到skb内存；最后，应用程序不停的重试发送，出现高CPU使用率；但是不巧这个应用程序的优先级比Kernel进程的优先级还要高，导致了后续一系列的问题。而且会影响平常的debug方式！来来回回的要了好几次日志之后才要的perf，有点晩了。这次应该是长了记性，下次再碰到类似的问题，直接上perf。

写了下面的一些总结/吐槽：
【CSDN】
Linux: network: sysctl: tcp_mem
Linux: proc: net: sockstat6疑惑：系统里没有IPv6的地址
[晕事]今天做了件晕事45 ssh 远程执行命令与＞
Python: RAII:函数执行完毕，socket对象主动发送fin
Linux: debug: perf 可以将record数据文件rotate吗？【ChatGPT】
Linux:debug: systemtap: ubacktrace
Linux: tool: perf使用时遇到的一个问题
【公众号】
[杂谈] 技术支持与反腐
[程序员] 优先级[ChatGPT]
[程序员] 技术支持的基本技能之一：脚本语言！
[程序员] 前人留下的苦难源，我们是否有勇气改正？

后期还会有几篇，希望可以在十一假期写出来一些：
netlink 读取route 里的临时记录；
audit机制的风险；
tcp_mem遭遇hard limit时，是否要上报警告？
出现典型锯齿图的一种情况；
典型网络延迟图，CPU导致；
perf report no-children的使用；
VoWiFi“新业务”模型对老产品的冲击！
出现martian包/tcp syn flood的一个极端情况！
急需施实的一个问题分析工具！
正向分析的挫折！
…