Linux on Tech Explorer

用 process_vm_readv() 实现多进程内存队列

Thu, 04 Jun 2020 06:58:27 +0800

一，问题背景
#

多进程之间需要传输大量数据的时候，比如多进程 RPC 框架的进程之间通信，常用共享内存队列。

但是共享内存队列难免会有入队+出队 2次 memcpy 。

而且要变长共享内存队列，如果支持多生产者进程+多消费者进程，就要处理线程安全方面的问题，比较麻烦。

process_vm_readv() , process_vm_writev() 是 Linux 3.2 新增的 syscall，用于在多个进程的地址空间之间，高效传输大块数据。

https://www.man7.org/linux/man-pages/man2/process_vm_readv.2.html

https://github.com/open-mpi/ompi/blob/master/opal/mca/btl/sm/btl_sm_get.c#L96

在此，我提个设想，可以用 process_vm_readv 实现一个多进程内存队列，相比之下，优势是：

在处理多线程/多进程并发时，更简单
省掉一次 memcpy。

下面 demo 代码演示了这个思路。为了方便，直接用 posix mq 来传输 iovec 数组，也没有考虑多路复用。真实项目可能需要 eventfd 之内的机制来做 notify。

实测了下，3个进程加起来有 5.5 GB/秒的速度。

二，代码
#

#include <assert.h>
#include <fcntl.h>
#include <mqueue.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <sys/wait.h>
#include <unistd.h>

#include <iostream>
#include <sstream>
#include <vector>
using namespace std;

struct MemMessage {
 pid_t pid = 0;
 vector<iovec> mem_vec;

public:
 MemMessage() {}

 string DebugString() const {
 ostringstream oss;
 oss << "pid=" << pid;
 for (const auto& mem : mem_vec) {
 oss << " iov={" << mem.iov_base << "," << mem.iov_len << "}";
 }
 return oss.str();
 }

 string ToString() const {
 pid_t from_pid = getpid();
 string buff;
 buff.append((const char*)&from_pid, sizeof(from_pid));
 for (const auto& mem : mem_vec) {
 buff.append((const char*)&mem, sizeof(mem));
 }
 return buff;
 }

 bool FromString(const char* buff, size_t buff_len) {
 size_t pos = 0;
 if (buff_len < sizeof(pid)) {
 return false;
 }
 pid = *((pid_t*)buff);
 pos += sizeof(pid);
 for (; pos + sizeof(iovec) <= buff_len; pos += sizeof(iovec)) {
 mem_vec.resize(mem_vec.size() + 1);
 auto& iov = mem_vec.back();
 memcpy(reinterpret_cast<char*>(&iov), buff + pos, sizeof(iov));
 }
 return true;
 }

 void CopyToMem(string& buff) {
 size_t sum = 0;
 for (const auto& iov : mem_vec) {
 sum += iov.iov_len;
 }

 buff.resize(sum, '\0');
 iovec local;
 local.iov_base = &buff[0];
 local.iov_len = buff.size();

 auto nread = process_vm_readv(pid, &local, 1, &mem_vec[0], mem_vec.size(), 0);
 // assert(nread >= 0);
 if (nread <= 0) {
 cout << getpid() << " process_vm_readv from=" << DebugString() << " sum=" << sum << " len=" << nread
 << endl;
 cout << "pid=" << pid << " " << strerror(errno) << endl;
 }
 }
};

class MemQueue {
 mqd_t m_mq;
 struct mq_attr m_attr;

public:
 int Init(const string& queue_name, bool read_write = false) {
 memset(&m_attr, 0, sizeof(m_attr));
 m_attr.mq_flags = 0;
 m_attr.mq_maxmsg = 10;
 m_attr.mq_msgsize = 4096;
 const int oflag = read_write ? O_WRONLY | O_CREAT : O_RDONLY;
 m_mq = mq_open(queue_name.c_str(), oflag, S_IRWXU, &m_attr);
 // m_mq = mq_open(queue_name.c_str(), oflag);
 cout << getpid() << " mq_open=" << queue_name << " oflag=" << oflag << " ret=" << m_mq << endl;
 }

 int PushMemMsg(const MemMessage& msg) {
 string buff = msg.ToString();
 return mq_send(m_mq, buff.c_str(), buff.size(), 0);
 }

 bool PopMemMsg(MemMessage& msg) {
 string buff(m_attr.mq_msgsize, '\0');
 unsigned prio = 0;
 const auto ret = mq_receive(m_mq, &buff[0], buff.size(), &prio);
 if (ret < 0) {
 return false;
 }
 buff.resize(ret);
 msg.FromString(buff.data(), buff.size());
 return true;
 }
};

const static string queue_name = "/test_queue";

enum STATUS { STATUS_WAITING = 0, STATUS_RUNNING = 1, STATUS_EXIT = 2 };

struct ControlCenter {
 int proc_status;
};

ControlCenter* control = nullptr;

void child_proc() {
 const auto ret = fork();
 assert(ret >= 0);
 if (ret != 0) {
 return;
 }

 while (STATUS_WAITING == control->proc_status) {
 usleep(1000);
 }

 MemQueue q;
 q.Init(queue_name);
 size_t bytes = 0;
 while (STATUS_RUNNING == control->proc_status) {
 MemMessage msg;
 if (q.PopMemMsg(msg)) {
 string buff;
 msg.CopyToMem(buff);
 bytes += buff.size();
 } else {
 usleep(1000);
 }
 }
 cout << getpid() << " bytes=" << bytes << " exit" << endl;

 exit(0);
}

int main(int argc, char* argv[]) {
 control = (ControlCenter*)mmap(NULL, sizeof(*control), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
 control->proc_status = STATUS_WAITING;

 const static int proc_num = 3;
 for (int i = 0; i < proc_num; ++i) {
 child_proc();
 }

 MemQueue q;
 q.Init(queue_name, true);

 control->proc_status = STATUS_RUNNING;
 string str(1024 * 1024 * 10, 'a');
 for (int i = 0; i < 10000; ++i) {
 MemMessage msg;
 for (int t = 0; t < 3; ++t) {
 size_t base = rand() % str.size();
 size_t size = rand() % (str.size() - base);
 msg.mem_vec.emplace_back(iovec{&str[base], size});
 }
 const auto ret = q.PushMemMsg(msg);
 // cout << getpid() << " PushMemMsg=" << msg.DebugString() << " ret=" << ret << endl;

 // sleep(1);
 }

 control->proc_status = STATUS_EXIT;

 for (int i = 0; i < proc_num; ++i) {
 int status = 0;
 wait(&status);
 }

 return 0;
}

构造最短程序打印自身的 MD5

Mon, 20 Apr 2020 00:00:00 +0000

一，介绍
#

比赛题目很简单：构造一个程序，在 stdout 上打印出自身的 MD5，程序越短越好。按最终程序文件大小字节数排名，文件越小，排名越靠前。只能使用 ld-linux-x86-64.so, libc.so, libdl.so, libgcc_s.so, libm.so, libstdc++.so 。禁止了 socket, shmget, fork, execvc 等 syscall 。

汇编高手如云，本人只做到 752 字节，只拿到 27 名。但忙活好几天，学到不少东西，也有苦劳，还是值得记录一下。

基本是纯 C 实现，没有动用汇编。

二，用过的一些思路和资源
#

基于这个 MD5 实现改造 https://gist.github.com/creationix/4710780

https://www.nayuki.io/page/fast-md5-hash-implementation-in-x86-assembly

参照 musl 和 rt0 ，去除对 glibc 依赖

musl libc https://www.musl-libc.org/
rt0 : https://github.com/lpsantil/rt0

三，没有成功的一些思路
#

思路，利用内核的 MD5 计算代码： grep -i md5 linux-5.6.2 只找到 2处，
1. TCP_MD5SIG ， CONFIG_TCP_MD5SIG : “TCP: MD5 Signature Option support (RFC2385)” 一个冷门特性，看起来通过 socket 才能执行。
2. AF_ALG Linux 的 crypto api，通过 socket 形式暴露 api，但是 socket 被禁用了。 https://www.chronox.de/libkcapi.html
构造碰撞，hardcode 直接 print 出来

https://github.com/corkami/collisions

https://www.rogdham.net/2017/03/12/gif-md5-hashquine.en

https://github.com/Rogdham/gif-md5-hashquine

http://www.win.tue.nl/hashclash/ 尝试了 fastcoll_v1 ，但是 fastcoll 构造1个字节的冲突要 2 block = 128 字节，则 16 字节就要 2048 字节，还不如 C 语言直接算。
通过某些 ipc 机制，绕过评判。试了简单的 shmget, 不成功。

三. 代码
#

后续借鉴思路，有优化

#define SYS_write 1
#define SYS_exit 60

inline long syscall3(long n, long a0, long a1, long a2) {
 long ret;
 __asm__ volatile("syscall" : "=a"(ret) : "a"(n), "D"(a0), "S"(a1), "d"(a2) : "rcx", "r11", "memory");
 return (ret);
}
inline long syscall1(long n, long a0) {
 long ret;
 __asm__ volatile("syscall" : "=a"(ret) : "a"(n), "D"(a0) : "rcx", "r11", "memory");
 return (ret);
}

static int write(int f, const char* d, int l) {
 int ret = syscall3(SYS_write, f, (long)(d), l);
 return (ret);
}

void _exit(int r) { syscall1(SYS_exit, r); }

typedef unsigned uint32_t;
typedef unsigned char uint8_t;
typedef unsigned long size_t;
#define NULL 0 // In words

#define memcpy(dest, src, n) \
 for (size_t i = 0; i < n; ++i) { \
 ((char*)dest)[i] = ((const char*)src)[i]; \
 }

// leftrotate function definition
#define LEFTROTATE(x, c) (((x) << (c)) | ((x) >> (32 - (c))))

static void md5_hash(uint8_t* initial_msg, const size_t initial_len, uint32_t hash[4]) {
 // Note: All variables are unsigned 32 bit and wrap modulo 2^32 when calculating

 // r specifies the per-round shift amounts
 const static uint8_t r[] = {
 7, 12, 17, 22, 5, 9, 14, 20, 4, 11, 16, 23, 6, 10, 15, 21,
 };

 // Use binary integer part of the sines of integers (in radians) as constants// Initialize variables:
 uint32_t k[64];
 for (int i = 0; i < 64; ++i) {
 double f = 1.0 + i;
 asm("fsin;\n\t"
 "fabs;\n\t"
 : "=t"(f)
 : "0"(f));
 f *= 4294967296.0;
 k[i] = (uint32_t)f;
 }

 // Pre-processing: adding a single 1 bit
 // append "1" bit to message
 /* Notice: the input bytes are considered as bits strings,
 where the first bit is the most significant bit of the byte.[37] */

 // Pre-processing: padding with zeros
 // append "0" bit until message length in bit ≡ 448 (mod 512)
 // append length mod (2 pow 64) to message

 const int new_len = ((((initial_len + 8) / 64) + 1) * 64) - 8;

 // Message (to prepare)
 uint8_t* msg = initial_msg msg[initial_len] = 128; // write the "1" bit

 uint32_t bits_len = 8 * initial_len; // note, we append the len
 memcpy(msg + new_len, &bits_len, 4); // in bits at the end of the buffer

 // Process the message in successive 512-bit chunks:
 // for each 512-bit chunk of message:
 for (int offset = 0; offset < new_len; offset += 64) {
 // break chunk into sixteen 32-bit words w[j], 0 ≤ j ≤ 15
 uint32_t* w = (uint32_t*)(msg + offset);

 // Initialize hash value for this chunk:
 uint32_t a = hash[0];
 uint32_t b = hash[1];
 uint32_t c = hash[2];
 uint32_t d = hash[3];

 // Main loop:
 uint32_t i;
 for (i = 0; i < 64; i++) {
 uint32_t f, g;

 if (i < 16) {
 f = (b & c) | ((~b) & d);
 g = i;
 } else if (i < 32) {
 f = (d & b) | ((~d) & c);
 g = (5 * i + 1) % 16;
 } else if (i < 48) {
 f = b ^ c ^ d;
 g = (3 * i + 5) % 16;
 } else {
 f = c ^ (b | (~d));
 g = (7 * i) % 16;
 }

 uint32_t temp = d;
 d = c;
 c = b;
 b = b + LEFTROTATE((a + f + k[i] + w[g]), r[i / 4 / 4 * 4 + i % 4]);
 a = temp;
 }

 // Add this chunk's hash to result so far:

 hash[0] += a;
 hash[1] += b;
 hash[2] += c;
 hash[3] += d;
 }
}

static char xdigits(char c) {
 if ((c >= 0) && (c <= 9)) {
 return '0' + c;
 }
 return 'a' + (c - 10);
}

void _start(void) __attribute__((noreturn));

void _start(void) {
 uint32_t hash[4] = {0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476};

 char* addr = (char*)0x400000;
 const size_t len = 688;
 md5_hash(addr, len, hash);

 unsigned char* md = (unsigned char*)&hash[0];
 char buff[32];
 for (int i = 0; i < 32; ++i) {
 unsigned x = md[(i >> 1)];
 x >>= (i & 1 ? 0 : 4);
 buff[i] = xdigits(x & 15);
 }
 write(1, &buff[0], sizeof(buff));
 _exit(0);
}

CFLAGS="-static -Os -Wl,--omagic -D__RT0_WITH_FASTER_SYSCALL__ -ffunction-sections -Wl,--gc-sections -nostartfiles -nodefaultlibs -nostdlib -nostdinc -Wl,--build-id=none -fomit-frame-pointer -fno-stack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-unroll-loops -fmerge-all-constants -fno-ident -mfpmath=sse -mfancy-math-387 -finline-functions-called-once -I ./ "

gcc $CFLAGS print_my_md5.c -S -fverbose-asm
gcc $CFLAGS print_my_md5.s -o print_my_md5 

strip -R .comment print_my_md5
strip -R .bss print_my_md5
ls -l ./print_my_md5
./ELFkickers/sstrip/sstrip print_my_md5
./print_my_md5
echo
md5sum ./print_my_md5
ls -l ./print_my_md5

基于 ElasticSearch 开发垂直搜索系统

Sun, 29 Mar 2020 00:00:00 +0000

一，背景介绍
#

ElasticSearch 是由 Lucene 包装上分布式复制一致性算法等附加功能，构成的开源搜索引擎系统。

近两年在业界热度大增，主要有 3 种应用场景：

全文搜索引擎
NOSQL 数据库
日志分析数据库 ELK

很多垂直领域搜索需求，都可以基于 ElasticSearch 来设计架构。

ElasticSearch 能大幅度提升相关业务的迭代开发速度，实现类似 sql 数据库增删改查一样的快速开发。并在相对高 qps 的在线业务中，保证毫秒级的延迟，提供极高的可用性和稳定性。

经过持续的研读官方文档，调研业界经验，并在实践中应用反思后，总结出一套架构方案。供参考，欢迎意见建议。

二，架构方案
#

一个 ElasticSearch 集群 cluster ，配套：

转发代理 proxy
队列

1. 转发代理 proxy
#

proxy 的功能是：

协议转换，做 rpc 协议如 protobuf 和 ElasticSearch REST json 之间的协议转换，对文档更新等请求，定义了 rpc 协议，便于队列做各种处理。
引入 RPC 框架成熟的负载均衡，容灾，故障屏蔽等功能，到对 ES 的 RPC 中，比如如果单机 ES 进程挂了，通过返回码让调用方自动换机器重试。
统一监控告警系统，监控各种请求失败，延迟分布等，并监控 ElasticSearch java 进程状态，集群状态
转发文档更新请求给本机的队列。用队列做削峰填谷，自动合并批量，做限流。
提供双写能力，便于索引升级切换
proxy 到本机 ES 做了 http 连接池，避免频繁的 HTTP tcp 建连接。

2. 队列
#

队列实现了出队限流，请求合并，削峰填谷 3个功能。

在实际业务中，常常会定期做文档全量更新，会出现短时间内写请求高峰，

如果直接写 ES，请求高峰时，经常出现 ES write 线程池占满，导致部分写请求失败。

另外部分业务每次请求只更新1个文档，导致 ES cpu 高，影响 ES 的写性能，不符合官方推荐做法。

为此，引入队列:

配置限制了出队的 QPS ，确保集中高峰被抹平，以匀速稳定地写入 ES，彻底消除了更新失败。
并用配置自动把多个请求合并成批量（比如 5000个文档一个批量），优化了 ES 的写入性能。
请求高峰中超出配置 QPS 的请求，队列自动暂存在文件中，随后处理，保证了 ES 服务平稳。

3. 其他工具
#

另外，繁荣的 ES 开源生态中，周边工具非常丰富便捷，我们常用的两种周边工具：kinana 和 bin/elasticsearch-sql-cli，极其方便快捷，大幅度提升了开发效率。

三，搜索应用开发优化指南
#

垂直搜索系统的在线检索部分，一般流程如下

ES 用来实现召回和粗排环节，和部分自动补全环节。

基于 ES 开发的优点：

ES/Lucene 的 Query DSL 极其强大全面灵活，业务逻辑代码大幅度简化，开发简单便捷，业务迭代开发速度大大提高。
有商业公司维护的高质量官方文档，网上也有海量资料，新人几天就可以上手，快速形成生产力，提升团队效率。
成熟稳定，就目前经验看没有遇到过 bug
业务如果扩展，后续伸缩性，扩展性，分 shard ，多副本等，都有比较成熟方案。

1. query DSL 语法
#

基于 ES 的开发，首先需要学习常见的几种 query，

ES 的 query 简单分成 4 类:

term query，对单个词的 query，包括 term/terms/range/exists/missing/ids/regexp 等
full text query ，全文检索query，对多个词（即句子）的query，包括 match/multi_match/common 等
compound query 复合 query，包括 bool/dis_max/function_score 等
match_all ，简单匹配所有文档

建议先学习 term/match/range/bool ，就可以实现大部分业务逻辑。

网上资料较多，就不转述了。

可以先看看这些中文资料，在 test 环境的 kibana 做做实验，快速上手：

https://www.elastic.co/guide/cn/elasticsearch/guide/current/search-in-depth.html

https://my.oschina.net/yumg/blog/637409

https://www.cnblogs.com/yjf512/p/4897294.html

当然最好的还是官方英文文档：

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html

2. 分词
#

中文搜索的一个核心议题，就是分词。

ElasticSearch 常用的中文分词是 ik analyzer。ik 是开箱即用，便于小型业务快速开发的。

但是作为对分词可定制性要求较高的业务，我们实际测试，发现 ik analyzer :

不支持本地自定义词典文件的热加载；
无法针对不同 index 配置不同自定义词典；
另外对一些分词的 bad case ，比如没有正确切分的词，没法简单 fix。

因此推荐不用 ik ，而是在更新文档和搜索的时候，在外部做分词，然后用空格拼起来，传给 ES 做索引/搜索。这种方案中，在 ES mapping 中配置成 whitespace 分词器。

外部分词可以用 cppjieba 等，索引分词还可以合并多种分词算法结果提高召回率。

对 cppjieba ，我之前做过内存优化，将内存优化到了 1/100。

另外，索引之前，也有必要做 UTF8 的 normalize，全角转半角，英文大小写统一，和英文的词干提取， mapping 中常用

"cjk_width", "lowercase", "porter_stem"

这些filter

具体可以参考已有业务代码。

3.关系型搜索
#

实际开发遇到典型的 one-many 关系型数据上的 query，

比如在某业务中，就遇到这种逻辑，经过调研发现常见有 4 种方案：

分开2 个 index : one + many ，分开2次串行 search，问题: 需要2次延迟大
反范式，完全展开，one 的数据追加到每一个 many 文档中，问题：数据量变大，更新 one 需要用 _update_by_query 如果 one 数据更新频繁，可能导致大量写操作
nested ，比如 one 嵌套 many 子文档问题是：nested 嵌套文档更新需要更新整个 root 文档，即要把整个 one 文档和含有的 many 文档 select 出来，修改，再写回。对热门 one 文档，更新会操作大量数据，并发写还可能 data race。
join, has_parent, has_child 把 one 和 many 的所有字段合并到一个 index 中， one 和 many 分别独立更新。

经过实际数据测试 join field 方案，发现当 one:many = 1:1000万时，延迟在 5ms 可以接受，因此目前采用了这种方案。

当然，官方文档指出 join 性能是会慢的，后续也有待实践检验。

4. 粗排相关性打分
#

Lucene 从 2016年的 6.0 版本开始，默认的相关性算法切换成了 bm25 ， bm25 是一种调整过的 tf idf 算法。

这里可以做一简单举例介绍，更深入的介绍可以参见下面文章，以及官方文档：

https://farer.org/2018/09/10/practical-bm25-part-1-how-shards-affect-relevance-scoring-in-elasticsearch/

https://www.cnblogs.com/richaaaard/p/5254988.html

ES 的 explain 对 bm25 算分的过程有详尽的解释，推荐自行实验。

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-explain.html

4.1. BM25 例解
#

比如某业务的真实数据中，我们在所有文档的 title 这个 field 搜索 “牛奶 ” 这个词，

explain 可以看到，这个 bm25 分数的是这样得来的：

sum( weight(title:牛奶 in 77341) [PerFieldSimilarity] ) ，
weight(title:牛奶 in 77341) [PerFieldSimilarity] = idf * tfNorm

首先，如果某 field 被多个 term 命中，分别算每个 term 的分数 (PerFieldSimilarity)，然后求和，本例子只有1个 term “牛奶”。

每个 term 的分数 PerFieldSimilarity

PerFieldSimilarity = idf * tfNorm

而 idf 表征词的重要程度，与具体文档无关。

idf = log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))

其中 docFreq 就是本shard 中，有多少个文档含有 “牛奶”， docCount 就是本shard 一共有多少个文档。

tfNorm = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength))
termFreq=1.0
k1=1.2
b=0.75
avgFieldLength=14.456173
fieldLength=2 //比如如果 title 是 "牛奶 醪糟" ，那就是 2个 term

freq 即该 field 中，“牛奶”这个词出现了几次 k1 和 b 都是固定常数。 fieldLength 是当前文档的当前field ，一共有多少个 term。 avgFieldLength 即本 shard 中的所有文档的本 field 的 fieldLength 的平均值

4.2. BM25 shard 调整
#

实际业务发现，当 index 内文档太少(比如 10w 量级就算少) 时，有的词在多个 shard 内，词频分布会出现严重不均匀，可能会导致 bm25 分数产生较大偏差，

实践中的解决办法：

Search 的 url_parameters 参数填 “&search_type=dfs_query_then_fetch”
减少 shard 数

4.3. BM25 similarity 参数调整
#

如上计算过程可见，bm25 中的 b 参数，是用来给短文档做加权的，即 b 越大，越倾向于给短文档更高的 score，实际中，和算法同学一起分析后，发现针对我们的某业务，不应该对短文本有太高偏向，所以我们把 b 调整成了 0.3 ，实测发现解决了一批 bad case，用户体验有明显改善。

四，性能优化
#

计算机程序的性能取决于数据结构和算法， ES/Lucene 中主要有几种数据结构:

FST
Posting List ，著名的倒排索引，PForDelta 压缩，支持 SkipList 方式跳跃
BKD Tree，用来实现 int 和 geo 查询
DocValues , 以 DocID 为 Key 的列存储

https://zhuanlan.zhihu.com/p/47951652

https://www.elastic.co/blog/elasticsearch-query-execution-order

更深入的理解，我目前也在探索中。

在垂直搜索引擎业务中，用户对延迟非常敏感，一般业界经验认为，良好的用户体验应该是在 ** 200毫秒 ** 内返回搜索结果，这就意味着 ES 延迟最好控制在 100毫秒之内。

经过我们实际业务发现，决定 ES 延迟的因素主要有：

内存是否足够， page cache 是否 cache 了检索过程用到的文件数据
具体 query 的优化，类比 mysql query 优化

1. page cache 内存优化
#

page cache 是决定 ES 延迟的首要因素，用作在线检索服务的 ES ，实际中在线检索的代码路径不能有硬盘 io 访问 (实践证明， SSD也不行)

当 ES 用作在线垂直搜索引擎时，

《查询亿级数据毫秒级返回！牛逼哄哄的ElasticSearch是如何做到的？》 https://zhuanlan.zhihu.com/p/68706615

《ElasticSearch在数十亿级别数据下，如何提高查询效率？》 https://zhuanlan.zhihu.com/p/60458049

实践中，某 index 发现延迟非常高，达到了 1-2秒，用户体验很差。调查发现，iostat 看下 io util 很高，经常到 80% 90%，单机索引数据文件是 page cache 可用内存的 4倍，于是降低了副本数，单机数据量减少到 page cache 可用内存2倍后，硬盘 io 降到了 0 ，延迟一下降低到了 150ms 。

2. int 字段查询优化
#

业务中常会有一些 int 型的字段，存一些枚举性质的值。在 10亿以上文档的情况下，实际发现有的会出性能问题。

比如比如前述业务有1个 int 类型的 filter 字段，实际只有 {0,1} 2种取值，

借助 ES 的 profile ，我们发现搜索 query 93% 的耗时在 filter 字段的 PointInSetQuery 中，

随后发现，针对该业务，只需要返回 filter 为 0 的文档，于是我们在更新文档时，发现 filter 非0 的文档，直接把所有字段都清空，并随后在 query 中去掉了 filter 字段的过滤。

之后发现耗时从 150ms 降到了 20ms。

3. 副本数 replicas num
#

确定副本数的思路：

副本数越小越好。越小，单机数据越少，文件被 cache 的比例越高，性能越好。
副本太少会影响可用性。因此必须大于最大能容忍故障单机个数 max_failures 。

综合起来就是：

max(max_failures, ceil(num_nodes / num_primaries) - 1).

num_primaries 是 primary shards 的数量，就是一个 index 有多少个 shards，一般都 > num_nodes

replicas_might_help_with_throughput_but_not_always

对数据量特别少的 index，可以每台机都存一个副本 “auto_expand_replicas”: “0-all”,

4. 多 SSD
#

在 elasticsearc.yml 的 path.data 配置多个路径，ES 会自动把 shard 均分到多个路径上，如果有多个硬盘，可以充分利用多设备的 io 带宽，当然对在线业务意义不大。

5. 内存配置
#

最开始我们使用 16G 内存机型，后来发现出现大量 Elasticsearch Data too large Error 错误，随后发现，解决办法就是换到 64G 内存机型，

改 jvm.options 加大 jvm 的 heap 解决，从 10G 加大到 30G 解决 -Xms30g -Xmx30g

需要注意的是，不建议大于 32G，避免 jvm 的指针压缩优化失效。可以看 ES 的启动 log 确定

[2019-05-22T12:29:16,961][INFO ][o.e.e.NodeEnvironment ] [node_xxx] heap size [29.7gb], compressed ordinary object pointers [true]

https://www.elastic.co/cn/blog/a-heap-of-trouble

6. refresh_interval
#

如网上众多文章所说， refresh_interval 一般都设成了 30秒。

一些参考资料：

滴滴 Elasticsearch 多集群架构实践 https://cloud.tencent.com/developer/article/1405404
京东到家订单中心 Elasticsearch 演进历程 https://cloud.tencent.com/developer/article/1377194
从平台到中台：Elaticsearch在蚂蚁金服的实践经验 https://new.qq.com/omn/20190117/20190117A09ADY.html
美团点评旅游搜索召回策略的演进 https://tech.meituan.com/2017/06/16/travel-search-strategy.html
eBay 的 Elasticsearch 性能调优实践 https://www.infoq.cn/article/elasticsearch-performance-tuning-practice-at-ebay
有赞搜索系统的架构演进 https://tech.youzan.com/search-tech-1/
有赞搜索引擎实践(工程篇) https://tech.youzan.com/search-engine1/
全面理解搜索Query：当你在搜索引擎中敲下回车后，发生了什么？ https://zhuanlan.zhihu.com/p/112719984
elasticsearch初学终极教程: 从零到一 https://kalasearch.cn/blog/elasticsearch-tutorial/

怎样让 C++ 中 throw exception 产生的 coredump 带上栈

Sun, 29 Mar 2020 00:00:00 +0000

1. 问题
#

一个 C++ 程序，如果 throw 了 exception ，但是又没有 catch，那么一般会产生 coredump，问题是，在 gcc 4.x 版本产生的 coredump 文件中，没有 throw 时候的堆栈信息，导致不知道是哪里 throw 的，没法查问题。

原因是 gcc 4.x 的 /libstdc++-v3/src/c++11/thread.cc:92 里面有个 catch(…)，所以 stack unwind 了，就没了 throw 时候的 stack 。

void * execute_native_thread_routine(){
 try {
 ... 
 }catch(...){
 std::terminate();
 }
}

https://abcdabcd987.com/libstdc++-bug/

一个解决办法是可以升级 GCC 7 ，或者可以用更简单的办法：

2.代码 hook `__cxa_throw` ，让 coredump 带上堆栈
#

一个解决办法是通过改代码，hook __cxa_throw() 让每次生成的 coredump 都带上堆栈：

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/cxxabi.h#L616

// Throw the exception.
void __cxa_throw(void*, std::type_info*, void (_GLIBCXX_CDTOR_CALLABI *) (void *)) __attribute__((__noreturn__));

__cxa_throw() 是 libstdc++/libc++ 用于实现 throw 的函数。

https://libcxxabi.llvm.org/spec.html

#include <iostream>
#include <stdexcept>
#include <thread>

extern "C" { //加这3行代码，通过 hook __cxa_throw，直接 abort，可以避免 stack unwind。
 void __cxa_throw(void* ex, void* info, void (*dest)(void*)) { ::abort(); }
}

void func(){
 throw std::runtime_error("die");
}

int main() {
 std::thread t(func);
 t.join();
 return 0;
}

效果如下

(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff7264801 in __GI_abort () at abort.c:79
#2 0x0000555555554f53 in __cxa_throw (ex=0x7ffff0000ba0, info=0x555555756ce0 <typeinfo for std::runtime_error@@GLIBCXX_3.4>, 
 dest=0x7ffff7af4140 <std::runtime_error::~runtime_error()>) at test.cpp:6
#3 0x0000555555554f8f in func () at test.cpp:10
#4 0x0000555555555371 in std::__invoke_impl<void, void (*)()> (__f=@0x555555769e78: 0x555555554f53 <func()>)
 at /usr/include/c++/7/bits/invoke.h:60
#5 0x000055555555517e in std::__invoke<void (*)()> (__fn=@0x555555769e78: 0x555555554f53 <func()>) at /usr/include/c++/7/bits/invoke.h:95
#6 0x000055555555584c in std:: thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x555555769e78) at /usr/include/c++/7/thread:234
#7 0x0000555555555808 in std:: thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x555555769e78) at /usr/include/c++/7/thread:243
#8 0x00005555555557d8 in std:: thread::_State_impl<std:: thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x555555769e70)
 at /usr/include/c++/7/thread:186
#9 0x00007ffff7b096ef in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ffff761c6db in start_thread (arg=0x7ffff6e85700) at pthread_create.c:463
#11 0x00007ffff734588f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

3. gdb `catch throw`
#

如果是对已有的二进制，或者已经在运行的进程：

gdb 里面输入 catch throw 然后运行，gdb 就会在任何 throw 的时候暂停，即可看到 throw 时候的栈。

pdqsort-qsort

Tue, 03 Mar 2020 00:00:00 +0000

可以对抗输入数据模式的排序算法。

quick sort 在输入数据接近有序的情况下，效率不高。

Pattern-defeating quicksort (pdqsort) is a novel sorting algorithm that combines the fast average case of randomized quicksort with the fast worst case of heapsort, while achieving linear time on inputs with certain patterns. pdqsort is an extension and improvement of David Mussers introsort. All code is available for free under the zlib license.

pdqsort 结合了随机化的 quicksort 的快速的平均性能，和 heapsort 在最坏情况下的性能，并且在某些特定的输入模式下，可以实现线性的性能。 pdqsort 是 David Mussers 的 introsort 的一个扩展。

https://github.com/orlp/pdqsort

Single Thread Algorithms This table provides a brief description of the single thread algorithms of the library.

ClickHouse/contrib/pdqsort/

https://www.boost.org/doc/libs/1_67_0/libs/sort/doc/html/sort/single_thread.html

Algorithm	Stable	Additional memory	Best, average, and worst case	method
spreadsort	no	key_length	N, Nsqrt(LogN), min(NlogN, Nkey_length)	Hybrid radix sort
pdqsort	no	Log N	N, NLogN, NLogN	Comparison operator
spinsort	yes	N / 2	N, NLogN, NLogN	Comparison operator
flat_stable_sort	yes	size of the data / 256 + 8K	N, NLogN, NLogN	Comparison operator

spreadsort is an extremely fast hybrid radix sort algorithm, designed and developed by Steven Ross.
pdqsort is a improvement of the quick sort algorithm, designed and developed by Orson Peters.
spinsort is a stable sort that is fast with random or nearly sorted data, designed and developed by Francisco Tapia.
flat_stable_sort is a stable sort that uses very little additional memory (around 1% of the size of the data), providing 80% - 90% of the speed of spinsort, designed and developed by Francisco Tapia.

用 abstract unix socket 实现进程单实例运行

Tue, 03 Mar 2020 00:00:00 +0000

一，问题背景
#

很多时候，我们需要确保进程只有一个实例运行。

有几种方法：

http://stackoverflow.com/questions/2964391/preventing-multiple-process-instances-on-linux

http://stackoverflow.com/questions/5339200/how-to-create-a-single-instance-application-in-c-or-c

https://github.com/qtproject/qt-solutions/tree/master/qtsingleapplication/src

比较常规的做法，是对一个文件加文件锁 flock，比如对 pid 文件 flock( LOCK_EX|LOCK_NB )

但是这种方法有些弊端：

如果文件被 mv 或者 rm，是会被绕过的。
如果磁盘故障比如磁盘满，目录没有写权限，会失败。

二，abstract namespace unix socket
#

http://linux.die.net/man/7/unix

unix socket 有3种：

基于文件的
socketpair 创建的，匿名的
abstract namespace 的，Linux特有

Linux 下， AF_UNIX socket 支持一种特殊的 abstract namespace unix socket 。

相比普通的基于文件系统的 unix socket，abstract namespace unix socket ：

没有磁盘文件
进程挂了以后自动删除，无残留文件
无需担心与文件系统上的文件冲突，不需要关心文件系统上的绝对路径是否存在的问题

在 lsof 的结果里面看起来，就是有一些类似 @test_abstract_ns 这样的文件项

代码中使用也很简单， abstract namespace unix socket 在 bind 之前，sockaddr_un.sun_path[0] 设成 0x0 即可。

三，代码
#

于是我用 abstract unix socket 实现了一个 SysSem 工具类（一个 system 范围的 semaphore ），用来：

让一个程序只启动一个实例。
让 x 进程等待 y 进程执行完 yyy 操作后，才能执行 xxx 操作。

特点：

多进程/线程并发安全。
当持有的进程被 kill ，OS自动释放，无残留。
没有磁盘文件，没有文件意外被删的各种情况。
不占用 tcp/udp 端口。
简单，不到 60行代码。

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

#include <algorithm>
#include <string>

//
// a semaphore with system scope.
//
// 1. no race conditions between Post() / GetValue() , better than flock().
// 2. when a running process be killed, automatically release all.
// 3. no file on disk, no accidently delete .
// 4. no tcp/udp socket, no confliction, no port consumption.
//
class SysSem {
public:
 SysSem() : _fd(-1) { memset(&_addr, 0, sizeof(_addr)); }
 ~SysSem();

 void Init(std::string id);

 bool Post();
 bool GetValue();

 const char* GetID() const;

private:
 struct sockaddr_un _addr;
 int _fd;
};

void SysSem::Init(std::string id) {
 _addr.sun_family = AF_UNIX;
 const size_t len = std::min(id.size(), sizeof(_addr.sun_path) - 2); // 2 = start null and end null byte
 // abstract namespace socket address , _addr.sun_path[0] is a null byte ('\0')
 memcpy(_addr.sun_path + 1, id.c_str(), len);
 // memcpy(_addr.sun_path + 0, id.c_str(), len);
}

const char* SysSem::GetID() const { return &_addr.sun_path[1]; }

SysSem::~SysSem() {
 if (_fd >= 0) {
 ::close(_fd);
 _fd = -1;
 }
}

bool SysSem::Post() {
 _fd = ::socket(AF_UNIX, SOCK_STREAM, 0);
 if (_fd < 0) {
 return false;
 }

 if ((0 != ::bind(_fd, (struct sockaddr*)&_addr, sizeof(_addr))) || (0 != listen(_fd, 65536))) {
 return false;
 }
 return true;
}

bool SysSem::GetValue() {
 const int clientFD = ::socket(AF_UNIX, SOCK_STREAM, 0);
 if (clientFD < 0) {
 return false;
 }
 const bool ret = (0 == ::connect(clientFD, (struct sockaddr*)&_addr, sizeof(_addr)));
 ::close(clientFD);
 return ret;
}

#include <assert.h>
#include <stdio.h>

int main(int argc, char** argv) {
 if (argc != 3) {
 fprintf(stderr, "usage: %s abstract-path post/get\n", argv[0]);
 exit(1);
 }

 SysSem inst;
 inst.Init(argv[1]);

 if (0 == strcasecmp(argv[2], "post")) {
 assert(inst.Post());
 SysSem check;
 check.Init(argv[1]);
 assert(check.GetValue());
 printf("ok, i am the only one under %s. running ...\n", inst.GetID());
 pause();

 } else if (0 == strcasecmp(argv[2], "get")) {
 assert(inst.GetValue());
 printf("a process is running under %s. \n", inst.GetID());
 } else {
 printf("unknown cmd \n");
 }

 return 0;
}

借助 ext4 文件系统的打洞功能实现消息队列

Sat, 10 Aug 2019 00:00:00 +0000

借助 ext4 文件系统的打洞功能，可以实现一个消息队列 https://gist.github.com/CAFxX/571a1558db9a7b393579

fallocate(fd, FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE, offset, length);

Punching holes in files

https://lwn.net/Articles/415889/

怎样对大文件的中间部分进行增删？

首先，如果复制/写文件的后半段的话，肯定是可以实现的，但是这样不“高效”。所以这里的需求是 “怎样在大文件中间 insert 或者 delete 一段数据而不用读写文件的后半部分”。

由于 unix 的历史，并没有直接提供这种 syscall 。

如果用 3.15 之后的 linux kernel ，在 ext4 (only for extent-based files) 和 XFS 文件系统上， http://man7.org/linux/man-pages/man1/fallocate.1.html http://man7.org/linux/man-pages/man2/fallocate.2.html

fallocate 这个 syscall 新增了 FALLOC_FL_COLLAPSE_RANGE (delete 一段) 和 FALLOC_FL_INSERT_RANGE （insert 一段）这两个选项，可以实现在文件系统 block size 边界对齐的 insert/delete 。

Proxygen http2 代码分析

Wed, 08 Mar 2017 00:00:00 +0000

Proxygen 的整体架构

一个 HTTPSession 对应一个 tcp 连接。

HTTPSession 中包含HTTPCodec ，HTTPCodec用来在 HTTPMessage(Request/Response) 和字节流之间做转换（就是解析/序列化）。

一个 HTTPTransaction 对应一个 HTTP2 的Stream ，也就是一次 Req/Resp Handler 是业务逻辑处理的基类。

其中 HTTP2 部分由几个类构成：

codec/HTTPCodec.h
codec/HTTP2Framer.cpp
codec/HTTP2Codec.cpp , HTTPParallelCodec.cpp
codec/Compress/HeaderCodec.cpp,HPACKCodec.cpp
session/HTTPSession.cpp
session/HTTPTransacion.cpp
session/HTTP2PriorityQueue.cpp

1. HTTPCodec.h
#

定义了 HTTPCodec 这个基类，定义了用来在内部的 HTTP Request/Response 和字节流之间做转换的公共接口，是HTTP1.1/SPDY/HTTP2 的公共基类。具体的HTTP2/HTTP1.1等各种协议的编解码，实现在 HTTP1.1/SPDY/HTTP2 等子类中。

1) HTTPCodec
#

HTTPCodec 是 HTTP1.1/ HTTP2 接口的超集，即HTTP1.1也被当成 HTTP2 实现

i. 首先所有的子类都要支持 StreamID，HTTP1.1 由于有KeepAlive，看成有多个Stream。 ii. onIngress()，传入输入数据，驱动解析。 iii. generateHeader()/ generateBody() /generateChunkHeader() /generateGoaway()/ generatePingRequest()/ generatePriority() 等，是 http1.1/http2 的超集。HTTP1xCodec.cpp 是没有实现HTTP2 的这些Frame 的generateXXX函数。HTTP1.1

2) PriorityQueue，优先级队列。
#

Session/HTTP2PriorityQueue.cpp 实现了这个接口类

3) HTTPCodec::Callback 类
#

解析的过程中，需要通知 HTTPCodec 的使用者做一些操作，因此有个接口类 HTTPCodec::Callback，HTTPCodec 的使用者实现 Callback 的子类，传给 HTTPCodec 的子类，HTTPCodec 的子类在解析过程中解析出来的各种消息都回调这个callback。 Callback 的主要方法有:

onMessageBegin()
onHeadersComplete() // HeaderList 接收完
onBody() // Body 开始
onMessageComplete() //Message 整个接收完
onWindowUpdate() // 收到 WindowUpdate Frame
onPriority()， //收到 Priority Frame等

顾名思义，处理HTTPMessage 开始事件，收到各种 HTTP2 Frame 等等。

2. HTTP2Framer.cpp
#

10种Frame 的解析/序列化工具函数，parseXXXFrame, writeXXXFrame，最底层。供HTTP2Codec 使用。

3. HTTP2Codec
#

Framing Layer，即处理 HTTPMesage , HTTP2 Frame 和输入/输出字节流之间的解析/序列化。实现了HTTPParallelCodec(HTTP2和SPDY的公共基类，HTTPCodec 的子类)，HeaderCodec两个接口类

1) 输入字节流的解析的时候，做:
#

i. HEADERS Frame，
#

做各种 Header 的变换处理。

ii. PRIORITY
#

4. compress/HeaderCodec.cpp
#

HeaderCodec 是 Header List 的编解码器。HeaderCodec解码的结果通过 HeaderCodec::StreamingCallback接口类通知给使用者（即HTTP2Codec）。HeaderCodec::StreamingCallback主要有个 onHeader(name, value) 接口(HTTP2Codec实现了)。

5. compress/HPACKCodec.cpp
#

HPACK保存 int –> string 的映射，通过发送 int，代替 string 来压缩。

HPACK编码，主要需要实现动态表，静态表，Huffman encoding，Header序列化/解析。

HPACKCodec 主要有 encode(vector

)/decode(Buffer) 两个接口。重要成员变量：

 HPACKEncoder encoder_;
 HPACKDecoder decoder_;

实际的动态表/静态表逻辑，是一个HeaderTable，主要数据结构就是vector + ，

HPACKDecoder 里面的动态表对应的是 HPACKContext，先 peek 一个字节，判断是否用了HPACKDecodeBuffer来解码

Integer比特编解码，literal编解码，都实现在 HPACKDecodeBuffer / HPACKEncodeBuffer里面。

Huffman encoding 实际使用的是 256位的trie，不是2位的，为了优化性能。

在 HeaderTable.cpp 中，可以看到，实际的 vector 是当成一个环形队列来用的，实际是把 RFC 中规定的 [ 1 — n ] 的区间，逆向映射到这个环形队列中，即 index 1 是，对应到环形队列的尾，index n 是对应到环形队列的头。这样，按照 RFC，增加 Header 进来的时候，应该是加在 1 前面，并把所有的已有 Header 往后挪1个位置，实现上就可以不用做 “挪动”，而且已有的 name–>index 的映射也不用改。这是一种实现上的小技巧。

并用一个

unordered_map<Header.name , list<index> > 

的形式存储 Header.name 到一组 vector 中的 index 的映射，这是由于有相同 name ，对应多个 value 的情况，而且要支持 “查找 name+value 匹配” 和 ”查找 name 匹配“ 两种查找。

6. session/HTTP2PriorityQueue.cpp
#

每一个 Stream都依赖一个 Stream 或者 Stream 0。一个 Stream A 依赖 Stream B ，那么 A 就是 B 的子节点。形成依赖树。 Stream 0 是树的根节点。

HTTP2PriorityQueue实现了PriorityQueue接口类，实现了 addPriorityNode(StreamID id, StreamID parent) 接口

主要的逻辑实现在 Node这个内部类里面。

PriorityQueue 的数据成员，主要是一个 unorder_map<streamID, Node>

Node内部的数据成员：

Node {
 HTTP2PriorityQueue& queue_; //属于哪个 PriorityQueue
 Node *parent_{nullptr}; 		//树中的父节点
 HTTPCodec::StreamID id_{0}; //
 uint16_t weight_{16}; //权重
 HTTPTransaction *txn_{nullptr}; 

 bool isPermanent_{false};
 bool enqueued_{false}; //enqueued 表示在 有输出数据的队列中

 uint64_t totalEnqueuedWeight_{0}; 
 uint64_t totalChildWeight_{0};

 std::list<std::unique_ptr<Node>> children_; // 子节点
 std::list<std::unique_ptr<Node>>::iterator self_; 

 folly::IntrusiveListHook enqueuedHook_; //一个侵入式链表
 folly::IntrusiveList<Node, &Node::enqueuedHook_> enqueuedChildren_; //

}

有输出数据等待发送 (pending Egress) 的 HTTPTransaction ，会加入

signalPendingEgress() ，通知 HTTP2PriorityQueue 某一个 Stream 产生了输出数据。内部实现是把这 Stream加入

clearPendingEgress()，通知一个 Stream 发完了输出数据。

addOrUpdatePriorityNode()，

nextEgress() ，获取有输出数据等待发送的 HTTPTransaction 的列表，列表的每个元素是 pair< HTTPTransaction * ，double weight > ，按照 weight 从大到小排列，列表中的所有weight 加起来等于1。

7. session/HTTPTransaction.cpp
#

HTTPTransaction 表示一次 Req／Resp，HTTPTransaction 需要和 HTTPSession 交互写入 HTTPMessage 所以提出了Transport 这个概念，这样依赖关系就是单向的，没有 HTTPTransaction – HTTPSession 之间不会产生双向依赖。实际处理业务的代码，定义成一个个 Handler，需要与Handler 交互，

1) HTTPTransaction::Transport
#

是 HTTPTransaction 的下层为 HTTPTransaction 提供的输出HTTPMessage 服务。(下层具体指的是 HTTPSession)。

Transport 的方法有：sendHeaders()/sendBody()/pauseIngress()/resumeIngress()/ sendPriority() / 等

2) HTTPTransactionHandler
#

是一个个业务Handler 的基类，Handler的方法有:onHeadersComplete()/onBody()/onChunk/onTrailers/onEgressPaused()/ onEgressResumed等，就是解析出 HTTP Message的各个部分，或者流控发现无法再写了时候的通知。

i. HTTPTransaction::Handler 有好几种,业务Handler 比如直接生成 ErrorPage 的 HTTPDirectResponseHandler就是生成 404 页面的 Handler，在其内部，实现 onHeadersComplete 方法，在这个方法内生成回包数据，然后调用 HTTPTransaction 的 sendHeaders/sendBody 等方法发回给客户端。

3) HTTPTransactionIngressSM
#

由于 HTTPTransaction 要调用 Handler 的好几种方法，内部要记录当前已经处理到哪一步了，不能允许在任意时机，任意来的数据都触发回调，所以搞了两个状态机，HTTPTransactionIngressSM/ HTTPTransactionEgressSM 来明确地规定回调可以触发的顺序。

4) HTTPTransaction 的重要成员变量：
#

streamId, handler_ , transport_ ,egressState_ , ingressState_, recvWindow_ , sendWindow_, HTTP2PrioprityQueue::Handle queueHande_,

8. session/HTTPSession.cpp
#

HTTPSession 针对 HTTP2/HTTP1.1/SPDY的超集的，HTTPSession是一个 HTTPCodec::Callback（接受解析出来的各种 Frame），是 HTTPTransaction::Callback（供HTTPTransaction发送输出 HTTP Message）,是 FlowControlFilter::Callback（接受输出状态打开/关闭的通知）。

1) 重要成员变量：
#

{
 folly::IOBufQueue readBuf_,
 folly::IOBufQueue writeBuf_,
 map<StreamID, HTTPTransaction>transactions_,
 HTTP2PriorityQueue queue,
 FlowControlFilter connFlowControl_,
}			
			

2) getNextToSend()
#

是做发送的，可以看到，proxygen 是按相对权重来分派带宽的。txnEgressQueue_.nextEgress() 取出当前可发送的 HTTPTransaction + 相对权重的列表，然后把可发送字节数按照相对权重分给各个HTTPTransaction。

9. 细节
#

1) IOBufQueue
#

多处用到的基础类：IOBufQueue，Zero-Copy，引用计数。一个 Bufffer Chain，设计类似 linux kernel 的sk_buff, BSD 的 mbuf 。

https://github.com/facebook/folly/blob/master/folly/io/IOBuf.h

 * An IOBuf is a pointer to a buffer of data. *
 * IOBuf objects are intended to be used primarily for networking code, and are
 * modelled somewhat after FreeBSD's mbuf data structure, and Linux's sk_buff structure.
 * IOBuf objects facilitate zero-copy network programming, by allowing multiple
 * IOBuf objects to point to the same underlying buffer of data, using a
 * reference count to track when the buffer is no longer needed and can be freed.

2) HTTPHeaders
#

HTTPHeaders 有个性能优化，用了静态完美hash函数，把常用的 83个 Header 各自唯一地hash 成1 字节，HeaderList 的查找使用汇编实现的memchr。

https://github.com/facebook/proxygen/blob/master/proxygen/lib/http/HTTPHeaders.h

* Headers are stored as Name/Value pairs, in the order they are received on
 * the wire. We hash the names of all common HTTP headers (using a static
 * perfect hash function generated using gperf from HTTPCommonHeaders.gperf)
 * into 1-byte hashes (we call them "codes") and only store these. We search
 * them using memchr, which has an x86_64 assembly implementation with
 * complexity O(n/16) ;)
 

TrafficServer http2 代码分析

Wed, 08 Mar 2017 00:00:00 +0000

TrafficServer 是Apache基金会的 HTTP/HTTP2 代理服务器。

TrafficServer 的 HTTP2 部分主要的代码在 :

trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc
trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
trafficserver/proxy/http2/ Http2DependencyTree.h, Http2DependencyTree.cc
trafficserver/proxy/http2/HPACK.h, HPACK.cc
trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc

1. trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
#

10种Frame 的struct定义，解析/序列化函数，HeaderList转换函数，一些常量定义

2. trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
#

Http2ClientSession 处理 io event 事件，解析 FrameHeader，

调用顺序：

Http2ClientSession::main_event_handler()

--> state_read_connection_preface()

--> state_start_frame_read()

--> state_process_frame_read() 解析出一个完整的Frame

--> do_complete_frame_read()

--> Http2ConnectionState::main_event_handler(HTTP2_SESSION_EVENT_RECV )

3. trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
#

Http2ConnectionState，对应一个 HTTP2 连接，代码基本等价于 proxygen 的 HTTPSession，主要的成员变量：

{ 
 双链表<Http2Stream> //略挫，有个find_stream 用的遍历，改map好点。

 Http2ClientSession，

 HpackHandle 2个，

 DependencyTree，

 Http2ConnectionSettingsclient_settings server_settings，连接的几个 Settings 配置项，一个int数组
}

主要的方法：各个 rcv_xxx_frame() 和 send_xxx_frame(0 Http2ConnectionState::main_event_handler(HTTP2_SESSION_EVENT_RECV )里面，解析输入的各种 Frame

rcv_data_frame, // HTTP2_FRAME_TYPE_DATA
rcv_headers_frame, // HTTP2_FRAME_TYPE_HEADERS
rcv_priority_frame, // HTTP2_FRAME_TYPE_PRIORITY
rcv_rst_stream_frame, // HTTP2_FRAME_TYPE_RST_STREAM
rcv_settings_frame, // HTTP2_FRAME_TYPE_SETTINGS
rcv_push_promise_frame, // HTTP2_FRAME_TYPE_PUSH_PROMISE
rcv_ping_frame, // HTTP2_FRAME_TYPE_PING
rcv_goaway_frame, // HTTP2_FRAME_TYPE_GOAWAY
rcv_window_update_frame, // HTTP2_FRAME_TYPE_WINDOW_UPDATE
rcv_continuation_frame, // HTTP2_FRAME_TYPE_CONTINUATION

还有发送各类 frame 的接口，send_data_frames()/send_headers_frame() / send_push_promise_frame() / send_rst_stream_frame() 等。

具体地：

rcv_data_frame :
#

find_stream,然后检查stream的state是不是OPEN/HALF_CLOSE_LOCAL，去除 padding，处理END_STREAM flag，检查本端流量控制 window_size ，保存buffer，更新本地的window，发回 Connection 和 Stream Level 的WindowUpdate Frame。

rcv_headers_frame：
#

find_stream/create_stream，处理padding，处理PRIORITY flag添加到 PriorityTree 里面，如果 Header Block 结束了（即有END_HEADERS FLAG），那就http2_decode_header_blocks() 做HPACK 解压缩，调用 Http2Stream 处理解析出的HeaderList

rcv_priority_frame:
#

find_stream，reprioritize，重新调整树。

rcv_rst_stream_frame
#

rcv_settings_frame:
#

parse检查收到的各个配置项，更新到client_settings中，并发送SETTINGS_ACK

rcv_push_promise_frame 等
#

包括 rcv_ping_frame

rcv_goaway_frame:

rcv_window_update_frame

比较简单，略。

rcv_continuation_frame
#

类似 rcv_headers_frame

send_data_frames_depends_on_priority
#

取了 DependencyTree的top()，

send_data_frames 等
#

send_a_data_frame

send_headers_frame

send_push_promise_frame

send_rst_stream_frame

send_settings_frame

send_ping_frame

send_goaway_frame

send_window_update_frame

比较简单，就是检查字段合法性，序列化，然后发送。

4. trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc
#

对应实现HTTP2 的Stream，重要的成员变量有：

Http2StreamState _state;//实现IDLE，OPEN，RESERVED，HALF_CLOSE等的切换。

DependencyTree::Node *priority_node;// Priority Tree中的节点指针。

5. trafficserver/proxy/http2/Http2DependencyTree.h, Http2DependencyTree.cc
#

Http2DependencyTree::Node 表示一个Stream，成员变量有：

{
 bool actived; //是否有输出数据
 bool queued; //是否在 actived 队列中
 uint32_t id;
 uint32_t weight;
 uint32_t point; //queue中的节点按照这个 point 做优先级排序
 Node *parent; //父节点
 DLL<Node> children; //子节点的双列表
 
 PriorityQueueEntry<Node *> *entry; // 
 PriorityQueue<Node *> *queue; //有输出数据的所有子节点的队列，按point 优先级降序排列

 Http2Stream *t;
}

Http2DependencyTree 中有个 Node * root 指向树的根节点。

Http2DependencyTree的主要方法有：

Node *find(uint32_t id);
DFS 递归遍历树，查找一个Stream。
Node *add(uint32_t parent_id, uint32_t id, uint32_t weight, bool exclusive, T t); 就是插入 parent 的 children 链表中，兼做 exclusive 处理。
void remove(Node *node); 从parent 的 queue 中移除自己，把自己的 queue 全转给 parent，把自己的 children 全转给 parent
void reprioritize(uint32_t new_parent_id, uint32_t id, bool exclusive); 重排优先级，就是移动节点
Node *top(); 返回整个树中，point 最高的叶子节点。递归实现。
void activate(Node *node); 往上遍历，如果当前节点没有在 parent 的 queue中，加入
void deactivate(Node *node, uint32_t sent); 从parent 的queue中去除自己。
void update(Node *node, uint32_t sent);

这里使用 Weighted Fair Queue (WFQ) Scheduling 来调度 Stream 之间的优先级。

Http2ConnectionState::send_data_frames_depends_on_priority() 中，是直接取了树的 top() 节点，

6. trafficserver/proxy/http2/HPACK.h, HPACK.cc
#

实现 HPACK 压缩/解压缩

7. trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc
#

实现静态的 Huffman 表，接口简单，只有4个函数，，

是实现成二叉树，相比proxygen估计效率会低一些。

Linux LoadAvg 编程比赛

Thu, 13 Aug 2015 00:00:00 +0000

问题背景
#

https://timyang.net/programming/load-average/

2015.08.13 高可用架构群 Load 编程比赛，Tim 在群征集一段代码使 load average 最高

多线程写几个 while 循环的方法太 trivial 了，就不提了。

下面是 byronhe 的两个解：

1. 究极版之 stap 大法
#

vagrant@vagrant-ubuntu-trusty-64:~$ cat loadavg.stap

probe kernel.function("get_avenrun") {
 $avenrun[0]= ($1<<11);
 $avenrun[1]=$avenrun[0];
 $avenrun[2]=$avenrun[1];
}

vagrant@vagrant-ubuntu-trusty-64:~$ sudo stap -g loadavg.stap $(((1<<(64-11))-1))

效果如下:

https://github.com/torvalds/linux/blob/master/fs/proc/loadavg.c

https://github.com/torvalds/linux/blob/master/kernel/sched/loadavg.c

已经到达内核变量可以表示的最大值了，所以是究极版。嘿嘿嘿。

《用systemtap来修改下linux内核变量的值》 http://blog.yufeng.info/archives/102

《Install SystemTap in Ubuntu 14.04 》 http://blog.jeffli.me/blog/2014/10/10/install-systemtap-in-ubuntu-14-dot-04/

2. 用 O_SYNC 制造 uninterruptible 进程
#

利用 O_SYNC 制造同步请求，使得进程进入 D 状态，增大 loadavg

#!/usr/bin/env python
 import os
 import sys

 def load_add_1():
 fd=os.open("test.txt",os.O_CREAT|os.O_RDWR|os.O_SYNC, 0644)
 for i in xrange(10000*100):
 os.write(fd," "*100)
 sys.exit(0)

 for i in xrange(10):
 if os.fork() == 0:
 load_add_1()

《Linux Load Averages: Solving the Mystery》深度解析 loadavg 的历史根源演变和意义

http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

When load averages first appeared in Linux, they reflected CPU demand, as with other operating systems. But later on Linux changed them to include not only runnable tasks, but also tasks in the uninterruptible state (TASK_UNINTERRUPTIBLE or nr_uninterruptible). This state is used by code paths that want to avoid interruptions by signals, which includes tasks blocked on disk I/O and some locks. You may have seen this state before: it shows up as the “D” state in the output ps and top. The ps(1) man page calls it “uninterruptible sleep (usually IO)”.

On Linux, load averages are (or try to be) “system load averages”, for the system as a whole, measuring the number of threads that are working and waiting to work (CPU, disk, uninterruptible locks). Put differently, it measures the number of threads that aren’t completely idle. Advantage: includes demand for different resources.

解释： linux 下的 loadavg ，表示 runnable 进程数，加上 uninterruptible 状态的进程数。 uninterruptible 状态出现在进程不希望被信号打断时，比如阻塞在磁盘 IO 上，或者某些锁上。就是有时候会在 ps 或者 top 中看到的 “D” 状态。

因此 linux 下的 load average，不是整个系统对各种资源的需求，不仅包含对 cpu 的需求，也包含了对磁盘 iops 等资源的需求，是一种广义的负载。

一个使用KuaiPan备份linux服务器的脚本

Sat, 08 Feb 2014 00:00:00 +0000

近日需要给服务器做备份，在网上找到了一个现成的金山快盘的api：https://github.com/deren/python-kuaipan （感谢！）
试了一下，遂决定备份到金山快盘上。

备份脚本考虑了以下几个方面的要求：
1.上传之前一定要加密，对比之后，使用了openssl的aes-256-cbc加密算法
2.增量备份，最开始尝试用duplicity,写了一个duplicity的backend，然后发现，好复杂！猛然发现，linux上的tar就有增量备份功能，于是直接用了tar
3.分卷，KuaiPan有文件大小限制，此处用了split把tar文件分卷

代码放在 https://github.com/byronhe/kuaipan_backup

a http proxy script

Mon, 18 Nov 2013 00:00:00 +0000

简单几行 python 代码实现一个 http 代理

#!/usr/local/bin/python
# -*- coding: utf-8 -*-

import base64
import select
import socket
import httplib
import os
import sys
#base64.encodestring("das\120xsdada\s")

def usage ():
 print "connect_to_http_proxy %s"
 print "usage: connect_to_http_proxy &lt;desthost&gt; &lt;destport&gt;"

if len(sys.argv) != 3:
 usage()
 print sys.argv
 sys.exit()

proxy_host="web-proxy-domain.com"
proxy_port="8080"
dest_host=""
dest_port=""
dest_host, dest_port=sys.argv[1:]

sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
sock.connect((proxy_host,int(proxy_port)))
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
req="CONNECT "+dest_host+":"+dest_port + " HTTP/1.0\r\n\r\n"
sock.send(req)
resp=sock.recv(100000)
if resp.find("200") &lt; 0:
 print req,resp
 exit(-1)

ep=select.epoll()
ep.register(sock.fileno(),select.EPOLLIN)
ep.register(sys.stdin.fileno(),select.EPOLLIN)
while True:
 events=ep.poll(1,2)
 for fd,event in events:
 if event & select.EPOLLERR:
 sys.exit(0)
 if event & select.EPOLLIN and fd==sock.fileno():
 os.write(sys.stdout.fileno(),sock.recv(1024*100)) 
 if event & select.EPOLLIN and fd==sys.stdin.fileno():
 os.write(sock.fileno(),sys.stdin.read()) 

#conn=httplib.HTTPConnection(proxy_host+":"+proxy_port)
#conn.request("CONNECT",dest_host+":"+dest_port)
#res=conn.getresponse()
#print res.read()
#if res.status != 200:
# print res.status,res.reason
# sys.exit()

libpcap试玩

Sun, 04 Aug 2013 00:00:00 +0000

libpcap驱动了tcpdump,和wireshark这类抓包工具.提供了高度灵活的包过滤语言. 据wikipedia,高性能的包过滤最早是在bsd上作为一个问题被解决,被称为bpf,在内核实现了一个解释器,进行包匹配,用户态提供一个字符设备, linux作为后来者,支持与bsd基本相同的packet filter,称为lpf,不同的是,linux是通过在一个raw socket来支持包过滤的,通过setsockopt来SO_ATTACH_FILTER,挂载过滤器. strace 可知,libpcap实际上进行了如下syscall:

socket(PF_PACKET, SOCK_RAW, 768) = 59 
setsockopt(59, SOL_SOCKET, SO_ATTACH_FILTER, "\1\0\0\0\0\0\0\0\250\327Vc\375\177\0\0", 16) = 0

参考资料
#

libpcap的api文档和demo代码可以参见

实现
#

参考文档了demo,我写了一个小的sniffer,

如下:

class Sniffer{
public:
 Sniffer():handle(NULL),cap_exp(""),net_if("any"),exp_compiled(false){}
 ~Sniffer(){
 if(handle){
 pcap_freecode(&filter_code);
 }
 if(exp_compiled){
 pcap_close(handle);
 }
 }

 string help(){
 string h("avaliable net_interface:");
 pcap_if_t* alldev=NULL;
 if(0==pcap_findalldevs(&alldev, errbuf)){
 for(pcap_if_t * dev =alldev;NULL!=dev;dev=dev->next){
 h+=dev->name;
 h+=" ";
 }
 pcap_freealldevs(alldev);
 }
 char * default_if=pcap_lookupdev(errbuf);
 if(default_if){
 h+=" default interface:";
 h+=default_if;
 }
 return h;
 }

 string err(){
 return pcap_geterr(handle);
 }

 bool configure(const string & net_interface,const string & exp){
 if(net_interface!="")
 net_if=net_interface;
 cap_exp=exp;

 if(0!=pcap_lookupnet(net_if.data(),&netp,&maskp,errbuf)){
 return false;
 }

 handle=pcap_create(net_if.data(),errbuf);
 if(NULL==handle){
 return false;
 }
 if(0!=pcap_activate(handle)){
 return false;
 }
 //ignore:?
 //pcap_set_snaplen
 //pcap_set_promisc
 //pcap_set_rfmon
 //pcap_set_timeout
 //pcap_set_buffer_size
 //pcap_set_tstamp_type

 //only cap ethernet packet
 if(DLT_EN10MB!=pcap_datalink(handle)){
 return false;
 }

 if (0!=pcap_compile(handle, &filter_code, cap_exp.data(), 0, maskp)) {
 return false;
 }
 exp_compiled=true;

 if (0!=pcap_setfilter(handle, &filter_code)) {
 return false;
 }
 }

 bool loop(int pkg_num=-1){
 typedef void (*pcap_handler)(u_char *user, const struct pcap_pkthdr *h,
 const u_char *bytes);
 pcap_loop(handle,pkg_num,&(Sniffer::pcap_callback),(u_char*)this);
 }

 static void pcap_callback(u_char *user, const struct pcap_pkthdr *h,
 const u_char *bytes){
 Sniffer * p_this=(Sniffer*) user;
 p_this->dispatch(h,bytes);
 }

private:

 void dispatch(const struct pcap_pkthdr *h, const u_char *bytes){
 got_packet(NULL,h,bytes);
 }


 private:
 pcap_t *handle; // packet capture handle 
 string net_if; //e.g. "eth0"
 string cap_exp; //e.g "tcp and dst port 80"
 bool exp_compiled;
 struct bpf_program filter_code; // compiled filter program (expression) 
 bpf_u_int32 netp;
 bpf_u_int32 maskp;
 char errbuf[PCAP_ERRBUF_SIZE];
};

【旧代码】mysql备份的shell脚本

Tue, 15 Nov 2011 00:00:00 +0000

思路类似 http://bazaar.launchpad.net/~lenzgr/mylvmbackup/trunk/view/head:/mylvmbackup.pl.in

#!/bin/sh
bk_to="/var/mysql-backup-`date +%Y-%m-%d-%k-%M-%S |tr -d ' '`"
user_name="root"
user_pw="dev"

sql="
flush tables with read lock;
system cp -pR /var/lib/mysql $bk_to; 
unlock tables;
"
mysql -u $user_name -p$user_pw -e "$sql"
echo $sql 
tar cjf $bk_to.bz2 $bk_to
rm -rf $bk_to

一个用inotify监控apache的脚本

Sun, 29 Aug 2010 00:00:00 +0000

用于监控apache，如果退出就自动重启apache，原理是在如果apache退出，则apache的pid文件会被close，或触发attrib事件，只要用inotify监控这个事件，然后重启apache，再重新监控pid文件即可。

#!/bin/bash
#Author:windydays
#Date : 2010/8/29
#用于监控apache，如果退出就自动重启apache，原理是在如果apache退出，则apache的pid文件会被close，或触发attrib事件，
#只要用inotify监控这个事件，然后重启apache，再重新监控pid文件即可。
#使用方法：用root权限运行即可。
#停止方法：sudo pkill inotifywait.
pid_file=/var/run/apache2.pid 
mon_log=/var/log/apache2/mon-apache.sh.log
if ! [ -f $pid_file ] ; then
 echo 'pid file does NOT exist! maybe it is somewhere else or
 service is
 down now.' >>$mon_log;
 exit 1 ;
fi
#如果apache没有出问题，会阻塞在下面这里.
inotifywait -q -e close $pid_file >>$mon_log;
exit_code=$?;
echo "At $(date)" >>$mon_log;
#如果#?不等于0说明inotifywait不正常退出。
if [ $exit_code = 0 ];then 
 /etc/init.d/apache2 restart
 sleep 8;
 exec $0;
fi

领会意思即可，这个东西没有实用价值，有一些超时问题无法解决。

实际上还是那种每隔两分钟，就发个HTTP请求，检测apache是否还活着的方式比较稳定可靠，例如monit。

apache的安全增强配置(使用mod_chroot,mod_security)

Tue, 17 Aug 2010 00:00:00 +0000

LAMP环境的一般入侵，大致经过sql注入，上传webshell，本地提权至root，安装rootkit等步骤。

采用如下的配置，mod_chroot和单独分区挂载可以让本地提权变得极为困难，而mod-security可以封堵一般的sql注入等应用层攻击。

以下内容是在ubuntu10.04上实践以后总结出来的,直接上命令，就不做过多解释了，水平有限，错误在所难免，欢迎指正。

首先确保apache,php,mysql已经正常工作,出现问题的话，查看 /var/log/apache2, /var/log/syslog, /var/log/mysql/error.log 尤其是apparmor导致的权限错误，不易发现。

一，mod_chroot 的安装与配置
#

1.mod_chroot的安装，配置

目标是chroot到/var/www。

(1) 安装:

sudo service apache2 stop
sudo apt-get libapache2-mod-chroot
sudo vi /etc/apache2/mod-available/mod_chroot.conf

内容为

<IfModulemod_chroot.c>
  LoadFile /lib/libgcc_s.so.1
  ChrootDir /var/www
</IfModule>

sudo a2enmodmod_chroot

/etc/apache2/site-enabled/000-default 中 DocumentRoot 改为 /

sudo ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid

并把

ln -s /var/www/var/run/apache2.pid /var/run/apache2.pid

加到/etc/rc.local中

sudo mkdir /var/www/tmp #放session
sudo chmod 1777tmp
sudo mkdir -p /var/www/var/run/mysqld
sudo ln -s / /var/www/var/www

安装好apache,静态页面和php正常后，弄mysql

sudo service mysql stop.
改/etc/apparmor.d/usr.sbin.mysqld，把"/var/run/mysqld.sock w,“那一行复制并改为 “/var/www/var/run/mysqld.sock w,”
改/etc/mysql/my.cnf 在[client],[mysqld_safe],[mysqld]每一节里socket路径改为 “socket = /var/www/var/run/mysqld/mysqld.sock”
sudo servicemysql start.

一些其他问题

date()不正常，解决办法：

sudo mkdir -p /var/www/usr/share /var/www/etc
sudo cp -rp /usr/share/zoneinfo /var/www/usr/share/
sudo cp /etc/localtime/var/www/etc/

DNS可能出问题(没试过)

sudo cp /etc/resolv.conf/var/www/etc/resolv.conf

找不到错误页面

sudo cp -rp /usr/share/apache2//var/www/usr/share/

二，mod_security 的安装与配置
#

2.mod_security的安装，配置

安装

sudo aptitude install libapache2-mod-security2
sudo cp/usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_config.conf  /etc/apache2/mods-enabled/mod-security.conf
sudo a2enmod mod-security
sudo apache2ctl stop

修改 /etc/apache2/mods-available/mod-security.conf 中的 debug_log 和 audit_log 路径到合适的位置，并添加如下两行

Include/usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_global_config.conf
Include/usr/share/doc/mod-security-common/examples/rules/base_rules/*.conf

sudo apache2ctl start

#/usr/share/doc/mod-security-common/examples/rules/目录下还有一些规则可用

参照gentoo的ebuild中的如下内容（http://gentoo-portage.com/www-apache/mod_security/ChangeLog）

if ! use vanilla; then 
 mv "${D}"${APACHE_MODULES_CONFDIR}/mod_security/modsecurity_*{41_phpids,50_outbound}*/
 "${D}"${APACHE_MODULES_CONFDIR}/mod_security/optional_rules || die
fi

modsecurity_*{41_phpids,50_outbound}*的这几个规则还是不要用比较好。

另外，http://www.gotroot.com/tiki-index.php?page=mod_security+rules 提供一些规则

三，其他加固措施
#

3.另外，可以把/var/www/放在一个单独的分区上，用noexec,nosuid,nodev参数挂载,打开mysql的apparmor,可以极大增强安全性。

参考资料
#

参考资料： /usr/share/doc/mod-chroot-common/

http://core.segfault.pl/~hobbit/mod_chroot/index.html

http://server.it168.com/a2010/0714/1077/000001077357.shtml

http://www.howtoforge.com/chrooting-apache2-mod-chroot-debian-etch

/usr/share/doc/mod-security-common

补充说明
#

后期补充一些：

chroot的关键是确保/var/www/ ,/var/www/var/www都存在，并且/var/www/var/www 是指向/的符号连接

对apache chroot的过程，我的理解（如有不对，欢迎指正）是

先初始化其他模块
chroot到/var/www
改变当前目录到/var/www(此时实际上是改变到/var/www/var/www目录下)
当http请求到来时，比如http://127.0.0.1/index.php,根据vhost的配置（如果documentroot是/，网页实际放在/var/www/下的话），apache寻找/index.php(实际上是/var/www/index.php)

另外，还有个诊断方法是查看/proc//root和/proc//cwd，一个是apache的root路径，一个是apache的当前目录（是apache的pid ），再看看apache的访问日志

Linux on Tech Explorer

用 process_vm_readv() 实现多进程内存队列

一，问题背景 #

二，代码 #

构造最短程序打印自身的 MD5

一，介绍 #

二，用过的一些思路和资源 #

三，没有成功的一些思路 #

三. 代码 #

基于 ElasticSearch 开发垂直搜索系统

一，背景介绍 #

二，架构方案 #

1. 转发代理 proxy #

2. 队列 #

3. 其他工具 #

三，搜索应用开发优化指南 #

1. query DSL 语法 #

2. 分词 #

3.关系型搜索 #

4. 粗排相关性打分 #

4.1. BM25 例解 #

4.2. BM25 shard 调整 #

4.3. BM25 similarity 参数调整 #

四，性能优化 #

1. page cache 内存优化 #

2. int 字段查询优化 #

3. 副本数 replicas num #

4. 多 SSD #

5. 内存配置 #

6. refresh_interval #

怎样让 C++ 中 throw exception 产生的 coredump 带上栈

1. 问题 #

2.代码 hook __cxa_throw ，让 coredump 带上堆栈 #

3. gdb catch throw #

pdqsort-qsort

用 abstract unix socket 实现进程单实例运行

一，问题背景 #

二，abstract namespace unix socket #

三，代码 #

借助 ext4 文件系统的 打洞 功能实现消息队列

Proxygen http2 代码分析

1. HTTPCodec.h #

1) HTTPCodec #

2) PriorityQueue，优先级队列。 #

3) HTTPCodec::Callback 类 #

2. HTTP2Framer.cpp #

3. HTTP2Codec #

1) 输入字节流的解析的时候，做: #

i. HEADERS Frame， #

ii. PRIORITY #

4. compress/HeaderCodec.cpp #

5. compress/HPACKCodec.cpp #

TrafficServer http2 代码分析

1. trafficserver/proxy/http2/HTTP2.h, HTTP2.cc #

2. trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc #

3. trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc #

rcv_data_frame : #

rcv_headers_frame： #

rcv_priority_frame: #

rcv_rst_stream_frame #

rcv_settings_frame: #

rcv_push_promise_frame 等 #

rcv_continuation_frame #

send_data_frames_depends_on_priority #

send_data_frames 等 #

4. trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc #

5. trafficserver/proxy/http2/Http2DependencyTree.h, Http2DependencyTree.cc #

6. trafficserver/proxy/http2/HPACK.h, HPACK.cc #

7. trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc #

Linux LoadAvg 编程比赛

问题背景 #

1. 究极版之 stap 大法 #

2. 用 O_SYNC 制造 uninterruptible 进程 #

一个使用KuaiPan备份linux服务器的脚本

a http proxy script

libpcap试玩

参考资料 #

实现 #

【旧代码】mysql备份的shell脚本

一个用inotify监控apache的脚本

一，问题背景
#

二，代码
#

一，介绍
#

二，用过的一些思路和资源
#

三，没有成功的一些思路
#

三. 代码
#

一，背景介绍
#

二，架构方案
#

1. 转发代理 proxy
#

2. 队列
#

3. 其他工具
#

三，搜索应用开发优化指南
#

1. query DSL 语法
#

2. 分词
#

3.关系型搜索
#

4. 粗排相关性打分
#

4.1. BM25 例解
#

4.2. BM25 shard 调整
#

4.3. BM25 similarity 参数调整
#

四，性能优化
#

1. page cache 内存优化
#

2. int 字段查询优化
#

3. 副本数 replicas num
#

4. 多 SSD
#

5. 内存配置
#

6. refresh_interval
#

1. 问题
#

2.代码 hook `__cxa_throw` ，让 coredump 带上堆栈
#

3. gdb `catch throw`
#

一，问题背景
#

二，abstract namespace unix socket
#

三，代码
#

借助 ext4 文件系统的打洞功能实现消息队列

1. HTTPCodec.h
#

1) HTTPCodec
#

2) PriorityQueue，优先级队列。
#

3) HTTPCodec::Callback 类
#

2. HTTP2Framer.cpp
#

3. HTTP2Codec
#

1) 输入字节流的解析的时候，做:
#

i. HEADERS Frame，
#

ii. PRIORITY
#

4. compress/HeaderCodec.cpp
#

5. compress/HPACKCodec.cpp
#

1. trafficserver/proxy/http2/HTTP2.h, HTTP2.cc
#

2. trafficserver/proxy/http2/Http2ClientSession.h, Http2ClientSession.cc
#

3. trafficserver/proxy/http2/Http2ConnectionState.h, Http2ConnectionState.cc
#

rcv_data_frame :
#

rcv_headers_frame：
#

rcv_priority_frame:
#

rcv_rst_stream_frame
#

rcv_settings_frame:
#

rcv_push_promise_frame 等
#

rcv_continuation_frame
#

send_data_frames_depends_on_priority
#

send_data_frames 等
#

4. trafficserver/proxy/http2/Http2Stream.h, Http2Stream.cc
#

5. trafficserver/proxy/http2/Http2DependencyTree.h, Http2DependencyTree.cc
#

6. trafficserver/proxy/http2/HPACK.h, HPACK.cc
#

7. trafficserver/proxy/http2/HuffmanCodec.h, HuffmanCodec.cc
#

问题背景
#

1. 究极版之 stap 大法
#

2. 用 O_SYNC 制造 uninterruptible 进程
#

参考资料
#

实现
#

一，mod_chroot 的安装与配置
#

二，mod_security 的安装与配置
#

三，其他加固措施
#

参考资料
#

补充说明
#