具有讽刺意味的是，负责错误日志的进程竟然是最为脆弱的之一。在Erlang的缺省安装中，error_logger39负责记录日志（写入磁盘或者发送到网络上），它的速度要比错误产生的速度慢得多。尤其是在记录用户产生的日志消息（不是错误）或者大量进程崩溃时，更是如此。对于前者，是因为error_logger本来就不适用于记录高度连续的消息。它只适用于真正的异常情况，并不期望过多的消息量。对于后者，是因为崩溃进程的完整状态（包括其消息邮箱）都会拷贝出来进行日志记录。这种消息无需太多，就会耗费大量内存，即使不能立即造成节点内存耗尽（OOM），也足以减慢logger的处理速度，使得后续消息不断累积，导致最终的内存耗尽。

　　到目前为止，最好的解决方案是使用另外一个日志库：lager。   虽然lager不能解决所有的问题，但是它会删节掉巨大的日志消息，会在超过门限时选择性的丢弃掉OTP产生的错误消息，并且会在用户提交消息时自动地在同步、异步模式间切换，以达到自我调控的目的。   对于有些极端情况，lager也无能为力，比如：用户提交的消息非常巨大，并且都来自一次性进程。不过，这种情况非常少见，而且此时程序员往往具有更多的控制权。

注：目前我理解的方法是，在高度密集的日志需求下实现自定义的日志管理模块，采用“去军保帅”的做法，给消息队列设置高低水位线，超过就丢弃一定的消息。

 

转自：http://www.cnblogs.com/rsblog/p/4347453.html