系统技术非业余研究

Erlang的集群是由各个节点组成的，一个节点有一个名字来标识，而不管这个节点在网络的物理位置，所以在部署Erlang集群的时候就很方便。只要在集群里新启动一个节点，给个相对固定的引导的节点，让新节点和这个引导节点取得联系，由引导节点把新节点介绍入集群就OK了。
在实践中，新采购的机器上通常配置好IP,以及ssh访问权限。 我们需要在新机器上手工安装Erlang系统，部署新应用，然后启动应用节点，加入集群服务，这个步骤很繁琐。我们希望能够自动化去做这个事情。common_test的ct_系列模块来救助了。
common_test是A framework for automated testing of arbitrary target nodes，它随带的ct_ssh可以透过ssh在远程机器上执行各种各样的shell命令，通过scp传输数据;而ct_slave非常方便的可以连接到远程机器启动一个erlang节点。
pool（www.erlang.org/doc/man/pool.htm）模块也可以远程启动节点，但是它要依赖于操纵系统的ssh工具，需要在机器之间做ssh互信，也就是说ssh targetip这样的不能出现任何的交互,比如说键入密码,很不方便。

我们首先来演示下如何在远程机器上执行ssh命令：
Read more…

前段时间我们在MYSQL调优上发现有瓶颈，怀疑是过多拷贝内存，导致内存带宽用完。在Linux下CPU的使用情况有top工具, IO设备的使用情况有iostat工具，就是没有内存使用情况的测量工具。 我们可以看到大量的memcpy和字符串拷贝（可以用systemtap来测量），但是像简单的数据移动操作就无法统计，我们希望在硬件层面有办法可以查到CPU在过去的一段时间内总共对主存系统发起了多少读写字节数。

所以我们内存测量的的目标就归结为二点：1. 目前我们这样的服务器真正的内存带宽是多少。 2. 我们的应用到底占用了多少带宽。

首先来看下我们的服务器配置情况：

$ sudo ~/aspersa/summary 
# Aspersa System Summary Report ##############################
        Date | 2011-09-12 11:23:11 UTC (local TZ: CST +0800)
    Hostname | my031121.sqa.cm4
      Uptime | 13 days,  3:52,  2 users,  load average: 0.02, 0.01, 0.00
      System | Dell Inc.; PowerEdge R710; vNot Specified (<OUT OF SPEC>)
 Service Tag | DHY6S2X
     Release | Red Hat Enterprise Linux Server release 5.4 (Tikanga)
      Kernel | 2.6.18-164.el5
Architecture | CPU = 64-bit, OS = 64-bit
   Threading | NPTL 2.5
    Compiler | GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
     SELinux | Disabled
# Processor ##################################################
  Processors | physical = 2, cores = 12, virtual = 24, hyperthreading = yes
      Speeds | 24x2926.089
      Models | 24xIntel(R) Xeon(R) CPU X5670 @ 2.93GHz
      Caches | 24x12288 KB
# Memory #####################################################
       Total | 94.40G
        Free | 4.39G
        Used | physical = 90.01G, swap = 928.00k, virtual = 90.01G
     Buffers | 1.75G
      Caches | 7.85G
        Used | 78.74G
  Swappiness | vm.swappiness = 0
 DirtyPolicy | vm.dirty_ratio = 40, vm.dirty_background_ratio = 10
  Locator   Size     Speed             Form Factor   Type          Type Detail
  ========= ======== ================= ============= ============= ===========
  DIMM_A1   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A2   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A3   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A4   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A5   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A6   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B1   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B2   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B3   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B4   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B5   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_B6   8192 MB  1333 MHz (0.8 ns) DIMM          {OUT OF SPEC} Synchronous
  DIMM_A7   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
  DIMM_A8   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
  DIMM_A9   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
  DIMM_B7   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
  DIMM_B8   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
  DIMM_B9   {EMPTY}  Unknown           DIMM          {OUT OF SPEC} Synchronous
...

DELL R710的机器上有2个X5670CPU,每个上面有6个core，超线程，所以共有24个逻辑CPU。上面插了12根 8192MB(1333 MHz)内存条。

我们的机器架构从之前的FSB总线结构变成现在的numa架构，谢谢@fcicq提供的信息,请参考下图（来源）：

我们可以清楚的看到每个CPU都有自己的内存控制器直接连接到内存去，而且有3个通道， CPU直接通过QPI连接。 内存控制器和QPI上面都会流动数据。
Read more…

fio是个非常好用的io压力模拟工具，功能非常齐全， 有兴趣的同学参看 这里。
这里我用fio模拟我们线上mysql服务器的压力来为厂家送来的pci-ssd卡做压力测试，底下是脚本(已经测试正确)，也许有的同学有用。
Read more…

今天有同学在gmail里面问了一个Erlang的问题，问题描述的非常好, 如下：

问题的背景是：

1、我开发了一个服务端程序，接收客户端的连接。同一时刻会有多个客户端来连接，连接后，接收客户端请求后，再发送响应消息，然后客户端主动断连。

2、服务端监听的socket属性设置如下：

[binary, {packet, raw},
{ip, IPAddr}, {backlog, 10000},
{active, false}, {reuseaddr, true},
{nodelay, false}, {delay_send, true},
{recbuf, 128 * 1024}, {sndbuf, 64 * 1024}]

3、服务器accept监听socket，接收客户端请求，发送响应消息分别是在3个不同的进程中进行。接收请求和发送响应的进程都是重复使用的，每次重新使用的时候传入一个新accept的socket。

问题的现象是：

1、单个用户发起呼叫的时候，流程是成功的，服务器能正常响应。但是多个用户一起呼，批量跑的时候，跑一段时间后，部分客户端会发现不能接收到服务器返回的响应。从抓包来看，客户端的请求是发送到服务器端了。

2、服务器这边发送响应的进程会收到一条{empty_out_q, #Port<0.25876>}这样的消息，而这条消息并不是我开发的代码产生的。

问题是：

1、为什么发消息的进程会收到{empty_out_q, #Port<0.25876>}这样的消息？

2、收到empty_out_q消息，是不是就说明调用gen_tcp:send发送失败？

3、是不是说设置了delay_send的属性，所以即使send失败，也是异步的，在调用send的时候会马上返回ok，但是后面真的发送失败后，则系统会给调用send方法的进程发送一条{empty_out_q, #Port<0.25876>}这样的消息。

这个问题非常有意思。 Read more…