Weakyon Blog

首先这个问题相当小白，如果已经了解的同学看到这个标题应该就明白了，就能略过不看了。

我遇到这个问题是对改造的twemproxy做异常测试时出现的。

首先简介一下改造的多进程版本的twemproxy原理。

改造的twemproxy会连接zk去获取一些信息，建立监视使得后端redis掉线(使用一个watchdog来将redis注册到zookeeper上)能够通过zookeeper被通知到。

而后才会fork出子进程，主进程当获取到zookeeper的watch消息后，会通过管道来通知子进程去连接此时正常的redis。

经常能看到线上的服务器报出超时，除了自己代码的问题，因为网络环境导致超时的原因是各种各样的：

硬件上：各层交换机微突发；芯片转发；链路，网卡阻塞等等

软件上：在负载较高的情况下，KVM之类的虚拟化性能更不上（同一宿主机的两台KVM虚拟机压测时会报出大量超时）；

网络导致的超时，简单的可以用ping -f来观察，但是有些细微的超时，需要借助更加细微的工具来发现

我遇到的网络问题，大部分情况下都能使用下面的代码测试验证

内存方面的知识真是博大精深，把一些看到的零碎的知识点做个笔记总结下。

这些知识只是自己的理解，并不能保证正确，ULK和《深入理解Linux虚拟内存管理》这两本书看完以后还会来更新这篇的内容。

段式管理与页式管理

在操作系统理论中

gitcafe创建项目

配置域名

继如何创建这样一个blog这一篇已经过去快一年了。

然而最近遇到一个新的问题，各大搜索引擎毫无流量。因此写了文章后，除了几个朋友以外也没人看。

内存管理有两篇文章讲的还是满清晰的：

操作系统学习笔记-储存管理

The Linux Kernel-Chapter 3 Memory Management

下面这本书是有不少中文翻译的，可以自行查找

本文主要是讨论伙伴算法的，讲伙伴算法的文章虽然多，但是没几篇讲的很清楚的。我也是结合了几篇文章看了好久才弄明白，特地记下来。

业务线上出错，返回给用户的结果不正确。

使用了ZINTERSTORE这个接口对多个集合做交并集返回预期外的空集。如下图：

这是因为twemproxy只是把指令转发给redis而已，而多个集合被哈希算法分片在不同的redis节点上，所以转发这个redis并没有这几个集合，会直接返回空集。

这并不是BUG，redis3.0也存在这个特性，当多个集合做交并集操作时，需要使用hash_tag特性。

由于twemproxy的多进程改造计划，所以对教科书一般的nginx的管理方式做了分析

nginx的-s指令可以对进程执行多个命令。

这些命令由主进程接受信号然后在循环中对状态进行判断，然后通过unix socket或者信号的方式传达给子进程。

从代码里面可以看到如下状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

for()
{
    if (delay) {}
    sigsuspend();
    ngx_time_update();
    if (ngx_reap) {} //需要重启工作进程
    if (!live && (ngx_terminate || ngx_quit)) {} //工作进程都结束，自己也设定了结束，那么退出
    if (ngx_terminate) {} //强制退出状态
    if (ngx_quit) {} //优雅退出状态
    if (ngx_reconfigure) {} //配置热加载
    if (ngx_restart) {} //重启(配置不变)
    if (ngx_reopen) {} //重新打开日志
    if (ngx_change_binary) {} //二进制文件改变
    if (ngx_noaccept) {} //不再接受新连接
}

twemproxy的多进程改造计划中参考了nginx的设计，然而nginx有一段让我看不太明白。

这篇文章总结的很好

sigsuspend sigprocmask函数的使用方法

sigsuspend将新的信号集阻塞操作和pause操作组合在一起成为原子操作

做了以下的操作

nginx的文件缓存分为两种，内存缓存和硬盘缓存。

内存缓存指文件句柄等信息进行缓存，减少使用open等的系统调用。

硬盘缓存指文件被缓存到硬盘上，一般是因为当作反向代理用才会有这种需求。

内存缓存是全模块都可以调用的，因为封装在core/ngx_open_file_cache.c中。

而硬盘缓存只有http模块可以调用，因为封装在http/ngx_http_file_cache.c中，最常见的就是upstream模块的cache了。

C的内存管理难已经成为了共识。记得我那时候写ydfs，第一次接触全异步编程这种模式，没有考虑到内存的统一管理，导致溢出泄漏问题层出不穷。最终搞定没BUG了，那代码的阅读质量也是让人不敢恭维。那么来看看nginx是怎么做的吧。

nginx的内存池分为池(pool)和块(block)两个概念

这是nginx使用到的内存结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

typedef struct ngx_pool_large_s  ngx_pool_large_t;

struct ngx_pool_large_s {
    ngx_pool_large_t     *next;
    void                 *alloc;
};

//块
typedef struct {
    u_char               *last;//块目前已分配内存的末尾
    u_char               *end;//块总共可分配内存的末尾
    ngx_pool_t           *next;//下个块的指针（注意这里虽然是池类型，\
    //但是实际上的使用中池的一些数据结构并没有全部用到，基本上是当块来用的）
    ngx_uint_t            failed;//在该块上尝试分配内存的错误次数
} ngx_pool_data_t;

//池
struct ngx_pool_s {
    ngx_pool_data_t       d;//内存池的第一个块
    size_t                max;//池中块支持的最大大小，大于该大小将分配在large结构中
    ngx_pool_t           *current;//指向当前的块
    ngx_chain_t          *chain;//
    ngx_pool_large_t     *large;//大内存链表
    ngx_pool_cleanup_t   *cleanup;//清理数据的回调
    ngx_log_t            *log;//日志指针
};


typedef struct {
    ngx_fd_t              fd; 
    u_char               *name;
    ngx_log_t            *log;
} ngx_pool_cleanup_file_t;

池中以链表的形式保存许多块以及large链表。这是从数据结构中能大致看出的东西。