补录,笔记太过久远,原文已然忘记。《维摩诘经》有云,无尽灯者,譬如一灯燃百千灯,冥者皆明,明终不尽。所谓燃灯者,大抵如此
文革十年甚于崖山者百倍
视其平居无以异于俗人,临大节而不可夺,此不俗人也
人民,人民,有多少罪恶借你的名义施行
殷鉴不远,多行不义必自毙
人类一思考,上帝就发笑。
Python是一门动态强类型语言, 动态性是它鲜明的特点.
但是动态性在给程序员充分的自由的同时, 也带来了一些不好的负面效应. 特别是在团队协作的时候, 不好的队友会引发许多难以定位的问题.
同时动态性也大大削弱了ide的作用, 代码提示, 重构等一些功能远不如静态语言来得可靠.
1 | class Person: |
比如这个代码片段, ide很难准确识别introduce_someone
的参数应该是Person
类的实例, 它只能单纯地从文本上分析, 并把所有可能的单词都提示出来.
而且当调用introduce_someone
, 传入了不合适的对象, 也很难通过静态检查发现.
类型标记的出现就解决了这些问题.
最近在在一台服务器上发现, 一个服务的工作进程会异常退出, 但部署有相同代码的其他服务却没有类似的情况.
查看日志发现以下错误
1 | Traceback (most recent call last): |
在上面的错误输出里有一个关键词 RLIMIT_NPROC
, 涉及到了linux的Resouce limit.
在Linux系统中,Resouce limit指在一个进程的执行过程中,它所能得到的资源的限制,比如进程的core file的最大值,虚拟内存的最大值等。
最近在开发的lightgbm树模型,发现服务在处理了一定量请求后会卡死,请求无响应。
pstack
之后发现, 进程卡在libgomp.so这个动态库的函数中. 证实确实是卡死
1 | Thread 8 (Thread 0x7f8eb7900700 (LWP 1859)): |
首先尝试google lightgbm hang
, 看了前几条记录.
发现,github上的一个issue, 顺着发现官网文档上早就记录里这个问题, 并且提供了解决办法.
gevent是一个使用完全同步编程模型的可扩展的异步I/O框架。
通用monkey.patch_all() 所有io操作函数, gevent可以以同步的方式编写异步代码. 在不更改代码的同时就可以使系统并发性能得到指数级提升。
这里有一个局限, c扩展中的io操作无法被patch, 会导致整个server阻塞