@codehz 而且做到最后，可能出现这样的情况：所有的 task 都要在同个线程里执行……

@raaaaaar 我觉得没这么严重~试想就算你母语是英语，第一次学 stack，你就知道那是啥吗？还不是得深入研究，看它都定义了哪些操作，有什么特点？至于翻译不统一的问题，那是文档质量问题。

@GeekSky 很好奇干啥月入 3000……

我老弟初中文化，在老家服装厂打工，都能月入小一万，不过一年有两三个月淡季没活干，平均下来也不算太少。虽说比较辛苦，但勤劳致富不是？

所以建议分析一下原因，然后有针对性的提高自己~

用 man 逐个看下系统调用文档就知道怎么用了：man open

6k5 没啥好犹豫的，也不存在镀金一说。除了换还建议有空用心读几本基础书，做 IT 6k5 真的不应该呀……

写个程序调 utime 系统调用去改，可以精确到微秒，但是同样不能改 ctime

https://man7.org/linux/man-pages/man2/utime.2.html

你需要理解装饰器语法糖 @的运行原理，我写过一篇文章，应该可以说清楚： https://python.fasionchan.com/zh_CN/latest/practices/advanced-decorator.html

不用卸载，努努力拿别人的一半还是很容易的

你其实很幸运了，喜欢的恰好是时代需要的

@willww64 早年间的最小化安装主要是节省磁盘空间，那时很多发行版也没包含 ss，现在应该大部分服务器都会有 ss 命令了。

依赖外部命令其实也有一些问题，因为不确定一台服务器是否安装了这个命令，也不知道这个命令的版本是什么，有些命令不同版本输出格式还不一样，这在服务器数量大(当时大概 3 万台)，版本杂的场景是一个噩梦。因此，我们更喜欢直接调 API 或系统调用，虽然也可能有版本差异，胜在拿到的数据是格式化的，规避了解析数据导致的一堆问题。

如果一开始可以预知后面的事情，我们多半就不会按着文中这个路线走，甚至是评估是否有替代监控手段，完全绕开。一开始其实思路很直接，psutil 已经做了大量的基础工作，拿来用就是了。只是开源解决方案有不少带着玩具意味，一遇到规模较大的场景就撑不住。没有办法，选择用它，就只能去解决它带来的问题。

@willww64 直接用 ss 性能其实还行，略低一点点而已，只是当时有不少服务器没有装这个工具

@fengjianxinghun 大佬说的这个是个好东西，有空我也研究下

@KuroNekoFan python 确实有不少弱点，还是要看具体场景，对于性能比较敏感的模块，我现在慢慢转用 Go 来实现，感觉在开发效率与执行效率间找到了一个更好的平衡

@mmrx 哈哈，这或许就是软文硬写？

ss netstat 慢可能是 DNS 反解引起的，lsof 需要遍历 proc 下每个进程的每个 fd，按理应该不如 ss 或 netstat 快

@efaun 是的，所以我们的 agent 自带 py 运行时

@liprais 当时内核模块方案没有在线上用，只是作为一个备用技术思路，技术研究性质的