erlang 提供了简单易用的并发编程模型，基本不需要再考虑多线程并发问题。但实际应用中并不是那么的完美，很多地方需要注意，标准库也很坑人的；再者多线程编程很多很容易解决的事情，在erlang中是那么的蛋疼和无奈，嗯，erlang只是专注于自己擅长领域，慎入。
1.进程message_queue_len
很多问题归根结底都处在message_queue_len 太长，每个进程都带着一个buffer 无限的queue，嗯，来着不拒。
queue 因为各种各样原因消费不过来，经典的gen_server port 调用receive_match 问题， 越来越长，越长越慢，OOM...
进程数高，数十万百万级别时更容易出问题
列举解决方案：
- 日志组件
errror_logger 很坑，使用lager 关闭crash_log, sync_on none, file_backend 只能用于测试环境，使用自定义scribe_backend 将日志通过网络收集到中心日志服务器。
- dns 解析
- gen_server
改用rabbitmq-server 提供的gen_server2
2. 热点进程
不像多线程模型，一个执行流内路径都由一个线程完成，而是分布到多个进程，而一个进程最多使用一个核心。
一个进程活儿干不过来，那就使用多个进程一组来完成，要做分发（这个很蛋疼啊）。能用ets 就用ets，不行只能分组了。
- 进程优先级调高
process_flag(priority, high)
- discard
process_info(self(), message_queue_len) 控制流量，必要的时候discard 部分
- 合包
消息传递是有成本的，receive {‘gen_cast‘, Msg} 多次合包处理也是提高并发好办法
- supervisor
此进程也容易造成热点，必要proc_lib:spawn 方式，有些场景去掉supervisor 节省内存同时去除热点
3. 公平调度
erlang 是公平调度的，尤其在高进程数节点内，热点进程设置高优先级是必须的，线上使用依赖库很多都有此改动。
否则会出现，CPU 很低，但是业务处理不过来，很多call timeout 问题
- 避免使用rpc:call
erlang 虚机crash 提到，使用自己的gen_call 实现，OTP rpc 使用rex 单进程提供服务，进程优先级无法调整，请求量稍微一高就莫名的timeout。
- swt low
erlang 内部统计reductions 对于bif不准确，可能会存在cpu 很低，但业务依然timeout，提高调度器唤醒敏感度
4. 流控
因为消息队列原因，来着不拒，虚拟crash 大多因为 OOM，所以流控非常有必要
- message_queue_len
过长时，discard 策略，或server busy 应答
- memory
erlang:memory(total)/ SysMem(参考rabbit_memory_monitor) > 70% 后开始拒绝请求
为啥是70%呢？erlang:memory(total) 为实际使用内存，不保留无法使用的碎片，70% 很保守，必要应考试60%以下
5. 系统日志
一旦出现OOM，crash_dump 是无法生成的，shell也基本进入无望，所以必要的系统日志提供事后分析
erlang 没有提供进程队列阀值通知机制，那么只能是定时轮了
根据进程数量： registered() < release_handler_1:get_supervised_procs() < processes() 选取不同频率定时check，配合报警。