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 解析

　　　　一次erlang 节点CPU严重波动排查

　　- 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，配合报警。

erlang 健壮性