系统技术非业余研究

erl启动的时候有个参数 -init_debug 作用是

Makes init write some debug information while interpreting the boot script.

参见erlang system_principles的1.3节：Boot Scripts， 我们可以知道，每个erlang vm启动的时候，init进程都会去读取boot文件，来获取系统要启动那些服务。

如果我们不输入任何参数的话，，默认是其他start_clean.boot文件, 其内容如下：
Read more…

crashdump对于erlang的系统来讲如同core对于c/++程序一样宝贵，对于系统问题的修复提供了最详细的资料。当然erlang很贴心了提供了网页版的crashdump_view帮助用户解读数据，使用方法如下：crashdump_viewer:start().

因为crashdump文本文件里面记录了大量系统相关的信息，这些信息对于分析系统的性能，状态，排除问题提供了不可替代的功能。所以很需要在系统正常运作的时候，得到crashdump文件。

除了坐等系统有问题自动产生crashdump以外，另外还有二种方法来手动产生crashdump。

方法如下：
1. erlang:halt(“abort”).
2. 在erlang shell下输入CTRL C + “大写的A”

演示如下：

$ erl
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:16:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.3.1  (abort with ^G)
1> 
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
A

Crash dump was written to: erl_crash.dump
Crash dump requested by userAborted

$ erl
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:16:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.3.1  (abort with ^G)
1> erlang:halt("abort").

Crash dump was written to: erl_crash.dump
abort

祝玩得开心！

fio是个非常强大的IO性能测试工具，可以毫不夸张的说，如果你把所有的fio参数都搞明白了，基本上就把IO协议栈的问题搞的差不多明白了，原因在于作者Jens Axboe是linux内核IO部分的maintainer. 但是这个工具有个很大的缺点就是没有图形界面，单靠输出的数字很难看出来IO的趋势变化，所以急需一个图形前端.

幸运的是Jens也认识到这个问题，2012年2月15号在google plus上说：

Once complete, this will be a great addition to fio. It can be quite tricky to get a good overview of all the various job controlling options that fio has, presenting them graphically has some advantages over a basic 80-line text cli.

可是Jens是写linux内核代码的，对于图形终端的编程不是很熟悉。 大牛毕竟是大牛，发扬革命不怕苦精神，自己学图形编程，于是在最近的2.1版本给我们带来了这个图形终端。有了这个东西使用起来就方便许多。

我给大家演示下如何编译，运行这个gfio. 在这之前需要给大家说下fio的server/client模式。 fio一旦进入server模式就会在8765 tcp端口上监听，等待客户端来连接。 一旦客户端连接上来，会发上来比如运行job等任务，服务端把运行结果推送到客户端。所以这个图形前端实际上是fio的一个client, 名字叫gfio. 具体参见 README里面的描述。

新版本的支持gfio的fio可以在这里下载 git clone git://git.kernel.dk/fio.git,编译gfio源码的时候, 由于它依赖于gtk库，需要先安装libgtk2.0开发包，演示开始：

$ uname -a
Linux yufeng-Latitude-E6400 3.0.0-30-generic #47-Ubuntu SMP Wed Jan 2 23:16:29 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ sudo apt-get -y install libgtk2.0-dev
$ git clone git://git.kernel.dk/fio.git
$ cd fio
$ ./configure --enable-gfio
...
gtk 2.18 or higher            yes
...

$ make fio
$ make gfio
$ ./fio -S
fio: server listening on 0.0.0.0,8765

这样fio就编译好了，同时进入server模式。 在另外一个终端运行 gfio 就可以看到图形界面，打开examples/aio-read.fio 这个脚本把玩下（注意这个脚本里面文件的路径是/data1, 最好改成/tmp之类的），如下图：

有图有真像！

祝玩得开心！

前段时间有同学在线上问了个问题：

服务器端我是这样设的：gen_tcp:listen(8000, [{active, false}, {recbuf,1}, {buffer,1}]).
客户端是这样设的：gen_tcp:connect(“localhost”, 8000, [{active, false}， {high_watermark,2}, {low_watermark,1}, {sndbuf,1}, {buffer,1}]).
我客户端每次gen_tcp:send()发送一个字节，前6个字节返回ok，第7个字节阻塞
服务端每次gen_tcp:recv(_,0)接收一个字节，接收三个字节后，客户端的第7次发送返回。
按我的理解的话：应该是 服务器端可以接收2个字节+sndbuf里的一个字节，第4个字节客户端就该阻塞的，可事实不时这样，求分析

这个问题确实还是比较复杂，涉及到gen_tcp的发送缓冲区和接收缓冲区，水位线等问题，其中接收缓冲区的问题在这篇 以及这篇 博文里面讲的比较清楚了，今天我们重点来分析下发送缓冲区和水位线的问题。

在开始分析前，我们需要熟悉几个gen_tcp的选项, 更多参见 这里：
Read more…

很久之前我发在javaeye论坛上，预防丢了抄过来：

原文：http://erlang.group.iteye.com/group/wiki/1422-gen_tcp-half-closed

当tcp对端调用shutdown(RD/WR) 时候， 宿主进程默认将收到{tcp_closed, Socket}消息， 如果这个行为不是你想要的，那么请看：

shutdown(Socket, How) -> ok | {error, Reason}
Types:
Socket = socket()
How = read | write | read_write
Reason = posix()

Immediately close a socket in one or two directions.
How == write means closing the socket for writing, reading from it is still possible.
To be able to handle that the peer has done a shutdown on the write side, the {exit_on_close, false} option is useful.

简单的设置inets:setopts(Socket, [{exit_on_close, false}]). 这样就不会被强制退出了。

祝玩得开心！

gen_tcp是erlang做网络应用最核心的一个模块，实践中使用起来会有很多问题，我把团队和我自己过去碰到的问题汇编下，方便大家对症下药.

以下是gen_tcp,tcp,port相关的博文：

1. Erlang版TCP服务器对抗攻击解决方案
2. gen_tcp接受链接时enfile的问题分析及解决
3. gen_tcp 应对对端半关闭
4. gen_tcp容易误用的一点解释
5. 未公开的gen_tcp:unrecv以及接收缓冲区行为分析
6. gen_tcp如何限制封包大小
7. gen_tcp调用进程收到{empty_out_q, Port}消息奇怪行为分析
8. gen_tcp发送缓冲区以及水位线问题分析
9. gen_tcp接收缓冲区易混淆概念纠正
10. gen_tcp发送进程被挂起起因分析及对策
11. gen_tcp:send的深度解刨和使用指南(初稿)
12. Erlang open_port极度影响性能的因素
13. Erlang集群RPC通道拥塞问题及解决方案
14. Erlang新添加选项 +zerts_de_busy_limit 控制节点间通讯的数据量
15. TCP链接主动关闭不发fin包奇怪行为分析
16. gen_tcp的close与delay_send交叉问题
17. R15B01版本controlling_process一个port到self的问题
18. 异步gen_server进行port访问时性能严重下降的原因和应对方法（五）套接字发送的应对
19. 节点间通讯的通道微调

待续，欢迎补充！

祝玩得开心！

我们在做tcp服务器的时候，通常会从安全考虑，限制封包的大小，预防被无端攻击或者避免极端的请求对业务造成损害。
我们的tcp服务器通常是erlang做的，那么就涉及到gen_tcp如何限制封包的大小.

gen_tcp对封包的获取有2种方式：
1. {active, false} 封包透过gen_tcp:recv(Socket, Length) -> {ok, Packet} | {error, Reason} 来接收。
2. {active, true} 封包以消息方式投递。

对于第一种方式:gen_tcp:recv(Socket, Length) 我们开看下代码实现：
Read more…