Joe Armstrong 在愚人节介绍了
too_big_to_fail flag,这个东西真是好多疑问啊,希望只是愚人节的一个玩笑.
介绍
Too_big_to_fail_process进程平时和正常进程一样,一旦需要更多内存的时候面目就开始狰狞起来:如果它需要内存的时候出现了分配内存错误,就会随机挑选比较占用资源比较少的进程杀掉,然后重新尝试为too_big_fail进程分配内存.
如果是杀了本节点内其它所有进程还是不够用怎么办?会从其它节点
"窃取"内存!!!! Too_big_to_fail_process 进程会在其它节点创建自己的副本,在该节点继续分配自己需要的内存.具体细节:
- too_big_to_fail_process 在节点A耗尽内存
- "helper"进程在节点B分配内存
- "helper"在其所在节点尽可能的分配内存
- too_big_to_fail_process减少在节点A的内存使用量,转而使用在节点B占用的内存
- 反复执行 如果这两个节点都内存耗尽就尝试从别的节点继续上面的"窃取"过程
如果所有的too_big_to_fail_nodes内存都被耗尽了,还有垂死一搏:
"Memory Allacator of Last Resort".这个内存分配器还有能力分配新的内存,如果幸运点分配的速度比消耗的速度快,那就小车不倒继续推一直跑下去,如果内存消耗速度快于分配的速度,系统就会崩溃,需要重启.
too_big_to_fail_process 将跟随OTP-R18B发布,目前memory allocator of last resort的相关研究工作还在进行中.
疑问
我的疑问:
- 什么样的业务场景需要设计这样霸气的进程?（怎么看都像一个玩笑）
- 占用多个节点内存的情况,这个进程怎么协调内部逻辑的?
- Memory Allacator of Last Resort 是做数据压缩来争取内存空间么?(GC还有机会么?)
- 一个Vm里面有两个这样的进程,策略是怎样的?
请教了一下@淘宝褚霸 得到答复 ：
应该是个玩笑没有这样的使用场景的。
[0] http://site.douban.com/204209/
[1] http://joearms.github.com/2013/04/01/too-big-to-fail.html
[2] http://www.reddit.com/r/programming/comments/1bfqcz/joe_armstrong_too_big_too_fail_flag_for_erlang/
[3] http://developers.slashdot.org/story/13/04/01/2230220/erlang-getting-too-big-to-fail-process-flag
最后小图一张:
