博客

首先，库存在的目的大致可分为：

1、提供便利

2、尽可能解决一些痛点

首先，我们先明确一下Erlang编程语言的一些痛点（伪痛点）：


1，单进程问题


Erlang虚拟机属于抢占式调度，抢占式调度有很多好处，但是同样也存在这弊端。虚拟机在默认情况下分配个每个进程的资源都是相同的，但是若一个进程（gen_server/event/fsm）要为其他许多进程提供服务，这个进程就极有可能成为整个Erlang系统的瓶颈所在。http://www.cnblogs.com/–00/p/4277640.html


2，列表解析效率


在Erlang编程语言中，list/string 是非常常见的一种数据类型，list处理的方式几乎都是遍历或者是尾递归，在list规模小的情况下，这种方式几乎不会给大家造成麻烦，但是一旦list的规模很大之后，情况就会变得非常糟糕。如list的“++”操作存在陷阱，erlang:length(List) 存在陷阱，queue:len(Queue)存在陷阱，诸如这种陷阱看起来很细碎，但是如果不好好处理，指不定就容易出现各种让我们摸不着头脑的坑。

> 前不久，我们刚刚在一个系统中，优化了一个lists:keydelete/3 的操作，大幅度提升了整个接口处理的速度。

当然，这些问题和erts的设计思路有很大的关系，如：private heap，变量不变 … 。


3，refc binary


binary的存在在一定程度上缓解了list处理带来的“低效率”的问题，但是，refc binary（erlang:byte_size(Binary) > 64的binary）的gc又让人比较蛋疼。

Erlang process structure — refc binary



4，OOM


在一定程度上，这也是单进程问题的一个附属品。单进程获得虚拟机资源有限，处理性能不足，导致message mail box 的message不断挤压，继而引发large heap，导致整个Erlang 虚拟机crash。最最典型的就是lager了。


5，Erlang进程CPU消耗度量


一直以来，大家都在社区中试图寻找度量单个Erlang进程CPU的消耗，但是不管是Erlang现在的API函数，还是社区中的方案，都没有提供一种行之有效的方案。为什么？我简单摘抄一段Erlang_IN_Anger中的一段描述吧：

> It is generally difficult to properly analyze the CPU usage of an Erlang node to pin problems to a specific piece of code. With everything concurrent and in a virtual machine, there is no guarantee you will find out if a specific process, driver, your own Erlang code, NIFs you may have installed, or some third-party library is eating up all your processing power.

那么，究竟有哪些库，能帮我们解决（或者是缓解）这些痛点，能给我们带来便利？

1、riak_sysmon

github :

basho/riak_sysmon · GitHub


对erlang:system_monitor/0,1,2 的封装，尽快的发现系统中存在的long_gc，large_heap等性能隐患。针对上述痛点中的“refc binary”和“OOM”。

2、recon

github :

ferd/recon · GitHub


封装了erlang:process_info/1,2 函数，并提供了TOPN的feature，recon_alloc封装了度量虚拟机内部内存的使用量的查询。

不仅如此，recon提供了一种近似度量Erlang进程CPU消耗的方案，

Erlang tool — recon

，memory leak的检查。针对上述痛点中的“Erlang进程CPU消耗度量”、“refc binary”，并且提供了种种便利。好用到爆的感觉。

3、eper/redbug

github :

massemanet/eper · GitHub


刚开始接触Erlang时，社区提供的一种代码调试方案是日志。然，这种方式太不优雅，使用起来非常麻烦。

redbug是对Erlang系统中dbg模块的封装，提供了非常安全有效的代码调试方式。“安全”对生产环境来说，确实太过重要了。

4、pooler/poolboy

github :

seth/pooler · GitHub


github :

devinus/poolboy · GitHub


池。Erlang单进程效率的问题，非常常见的三种方式，第一种是池，第二种是noblock call，第三种是修改某个进程的资源配置。

在社区中，常见的是第一种方案，而第二种和第三种方案常见于Erlang编程语言编源码中（rpc模块，net_kernel模块）。针对上述痛点中的“单进程问题”。

5、jiffy

github :

davisp/jiffy · GitHub


json处理库，而且是nif的，能够尽可能保证效果，并且可以支持return_maps已经encode force_utf8，decode 的return_maps能直接返回map 数据类型，非常之方便。（虽然17的map效率不怎么样，但是18版本做了很大的优化）

6、entop

github :

mazenharake/entop · GitHub


有没有觉得Erlang自带的etop有些难用？entop提供了非常不错的可替代方案。

7、erlang-lz4

github :

szktty/erlang-lz4 · GitHub


不管是Erlang系统，还是其他系统，所倡导的都是“小消息，大计算”，加之Erlang消息传递是值传递的方式，对于大的message，稍微做一下压缩，获取能取得意想不到的效果。不放试一试，lz4 的算法，请Google 之。

8、sync

github :

rustyio/sync · GitHub


on-the-fly recompiling and reloading in Erlang. 大幅度提高工作效率，避免接二连三的重新compile、generate。不过，要注意的是，最好

只用

在开发环境下。

> 关于热更，多叨叨两句：

> 1，在supervisor下增删 gen_server child 热更会失败，目前无解，除非修改supervisor源代码

> 2，gen_server record 增删字段，这个可用 “使用proplists字段值”或者是“map字段值”

> 3，gen_server init 函数逻辑无法热更，解决办法，重写code_change 代码

> 至于常规的逻辑代码，热更基本上没什么问题

9、erlang_term

github :

okeuday/erlang_term · GitHub


存了一个Term到ETS表中，难道不应该知道这个Term到底占用了多大的内存空间吗？要send一个大的message给另一个进程，不度量一点内存占用大小就随心所欲？恐怕不太好。erlang_term可以作为贴心小工具。

Erlang ets — something about cache continue


10、folsom

github :

boundary/folsom · GitHub


提供了多种Metrics 模型，根据自己的应用场景，选择不同的模型就行。内部主要使用ets:update_counter/3,4，性能效果很有保证。

11、ej

github :

seth/ej · GitHub


Helper module for working with Erlang terms representing JSON

试试就知道有没有意思，好不好玩了。

12、task

github :

redink-toys/task · GitHub


遇到过这样一个有意思的场景：主进程是一个普通进程，有10W量级的列表，我想将其过滤之后，将1/2或者是1/4的列表写入到ETS表中，然后进行后续的操作。如果我在主进程中做这一些列操作，这个主进程就会被挂住，因为GC（Erlang的GC不会STW，但很有可能会STP）。考虑到ETS表可以在不同的进程之间共享数据，我就可以在主进程中spawn一个进程，这个这个进程去执行过滤、写入操作，然后这个进程生命周期结束之后，GC是很简单快速的。

task就是一个spawn、receive的简单封装。

13、xref_runner

github :

inaka/xref_runner · GitHub


做xref检查：

善待Erlang 代码 — Xref 实践