系统技术非业余研究

我们在做服务器程序的时候，经常要知道一个请求的响应时间，借以优化或者定位问题。 通常的做法是在代码里面加入日志计算时间，这个方法有问题，时间不准确。因为数据从网卡到应用程序，从应用到网卡的时间没有被计算在内。 而且这个时间随着系统的负载有很大的变化。
那同学说，我wireshark, tcpdump抓包人肉统计不行吗。 可以的，只不过我会很同情你，此举需要耐心且不具可持续性。 所以我们希望有个工具能够最少费力的做这个事情。

这时候来自percona的tcprstat来救助了！ 这个工具原本开发用来调查mysqld的性能问题，所以不要奇怪它的默认端口是3306, 但是我们可以用这个工具来调查典型的request->response类型的服务器。

什么是tcprstat:
Read more…

NIF是什么? A NIF library contains native implementation of some functions of an Erlang module.
不清楚的同学请参考http://www.erlang.org/doc/man/erl_nif.html.
这个功能对于扩展Erlang,利用现有的遗留c的财产,提高性能非常有帮助.
但是通常同学们会无视手册里面的一句话:

Avoid doing lengthy work in NIF calls as that may degrade the responsiveness of the VM. NIFs are called directly by the same scheduler thread that executed the calling Erlang code. The calling scheduler will thus be blocked from doing any other work until the NIF returns

导致了非常严重的设计问题. 比如在NIF里面调用mysql client api, 作费时的IO操作等等, 我已经看到好几个同学这么干了,为了揭示这个问题的严重性, davisp同学为我们写了个例子来演示这个问题: 代码在这里
https://github.com/davisp/sleepy.

Sleepy – A misbehaving NIF
This demonstrates what happens if a NIF takes a long time and is called from as many schedulers as exist in the VM. Namely, that the VM is halted until the NIF functions return.

我们来演示下把:
Read more…