The Mirages

上周公司做了一个培训，是讲团结协作的，但是更高一个层次其实是整体观。

今天大猫说IDC迁移的事情，也是一个整体观。很多搞技术的同学很容易专注于技术上，而忽略了你只是集体中的一部分，而你所做的只是让公司这个组织里的一部分。     在技术中，我们很容易发现某个模块跟其他模块之间的关系，也知道一个模块出现了问题，会导致与它相连的其他模块也会出现问题。 往更上一层来想，其实运维是技术部的一环，而整个技术部又是公司组织里的一部分，所以当你跟技术部其他同事谈的时候，你是代表了运维组，而当你跟其他比如HR这样的部门谈的时候，你又是代表着技术部的形象。而你跟供应商谈的时候又代表着你的公司，当你出国的时候又是代表着中国。   所以人还是那个人，但是在不同的情形又是不同的一个角色，而并不是说你的角色是一成不变的。就跟电脑CPU一样，总是在上下文切换干不同的事情，而且还要调度好，不然一件事情占用过多的时间，当然也有可以绑定CPU只干一件事情的。这个世界也必定有人只专注于某一件事情的，可这些毕竟都是小部分。   在工作中就得考虑每件事情你所处的位置。 当然我做的还是太烂了，以至于老是被骂啊！ 其实很多非技术的同事基本很能搞清楚，难道我们搞技术的都太木纳了？   团队协作说起来容易，但是出现利益冲突的时候就比较难协作好了，毕竟人的本性是自私的，安-兰德还写过一本书叫《自私的德性》。比较好说通的是当最终集体得到的利益远远大于个人的时候，大家一般都会暂时放弃一些个人的。   不说下去了，下面就没底了。 具体可以看胡适的一篇散文《容忍和自由》。

  原文链接： http://steveltn.me/blog/2014/03/15/deploy-rails-applications-using-docker 原作者：Weiyan Shao  

什么是docker？

  Docker是一个用来打包，装载和运行应用程序的一个轻量级容器的开源项目。它的工作方式非常像虚拟机，包裹所有的东西（文件系统，进程管理，环境变量等）在一个容器内。跟虚拟机有所不同，它是使用LXC（Linux kernel container）来替代虚拟层。 LXC没有自己的内核，但是与主机和其他容器一起共享Linux内核的。 基于LXC，因此Docker是非常轻量级的，因此在运行应用程序的时候几乎没有性能损失。 Docker同样提供了聪明的方法去管理你的images镜像。通过Dockerfile和自己的缓存机制，任何人都可以容易重新发布一个更新过的镜像而不用重新传输大量的数据。  

为什么是Docker?

  因为你从来都不知道你的应用程序能否在服务器上正常运行，就算你在本地已经测试和正常运行过了。那是因为服务器上的环境跟你的本地并非完全一致。RVM的设置，ruby和gem的版本差异。如果我们在发布前进行本地测试的时候，我们就已经确认如果在本地正常运行那它也能在服务器上正常运行，那我们会节省一些在服务器上debug错误的时间。 对于巨量的发布，使用虚拟机镜像是相对比较容易的。你可以在几分钟内创建一个虚拟机实例和应用你的镜像让它进行工作。除了便利性，它也有如下一些问题：

1. 如果你只做了一个很小的更新可不得不提交一个完整的新镜像
2. 有很多的性能损失。
3. 你的应用程序可能运行在一个虚拟环境的VPS上，所以你不能运行一个虚拟机在已有的虚拟环境之上。

网络的秘密 现代网络的秘密基本就是tcp/ip的秘密。解开这个秘密最重要的钥匙是steven写的《tcp/ip 详解的卷一，卷二》，下面这个就是看这个书的一些总结吧。 要了解tcp/ip那首先要了解一些基本概念。 MTU： 最大传输单元，这个就是指明了一次最多传输多少bytes的数据。这个一般都是1500. MSS： 最大报文段大小，这个指明了每次传输segment的大小，这个一般是1460. 之前一直没弄明白MTU和MSS之前的区别，后来看书才突然想明白了，MTU是2层的，而MSS是4层的。 所以为什么MSS定下的大小是1460， 就是1500-20（IP包头）- 20（TCP包头）的结果。 win： 也就是窗口大小，这个就是指明了本地可以接收多少数据大小再返回一个ACK确认。 RTT： 往返传输时间， 就是网络中src和dst之间的往返的延时，这个时间的长短跟win的大小是有关系的。 RTO： 重传超时， 也就是计时器计算多久没有收到返回后再次进行发送。 以上是一些基础概念，下面是一些基本网络流程。 先抄一个tcp状态迁移图吧，然后再稍微解释一下：   TCP的三次握手，准确的说应该是TCP建立连接的3次握手。 这个就是一个互相确认的过程。 TCP的4次握手， 准确的说应该是TCP关闭连接的4次握手。 很多人会比较困惑，为什么建立连接是3次，而关闭要4次呢。 这个是因为大部分TCP实现都是全双工的， 也就是数据包是相互传递的。 所以当要释放的时候要2边都要确认没有数据传送了。所以我们看到系统中一些TIME_OUT就不用太大惊小怪，对于有些公网服务，有这种TIME_OUT是非常正常的。 所以在建立连接的时候我们有client和server之分，而关闭连接的时候是没有server和client之分的。 认识一些TCP的标志位： SYN, ACK 这2个我们经常碰到的，这2个后面带的值一般都是从0开始累加上去的。 PSH： 就是说将收到的报文段尽快转给应用层进行处理。 RST： 这个在天朝访问辽国的时候会经常出现的一个状态，重建连接。

aryaka是一家做互联网加速的互联网公司。我们大猫同学想要用他们的加速服务来进行互联网服务。 到底要多快呢，大猫同学设想的是中国到美国在100ms以内。这个有可能吗？ 通过公开的资料，中国到到美国有2条海底光缆： 分别为TPE和CUCN，其中TPE全长17700KM， CUCN是36800KM。 参考资料： http://en.wikipedia.org/wiki/TPE_(cable_system) http://en.wikipedia.org/wiki/CUCN_(cable_system)   同时我们知道，tcp通讯基本都是全双工进行的，所以RTT都是是2倍的物理距离。 同时物理原理告诉我们，光速每秒是30万公里/小时。由此我们就可以计算中国到美国最快可以到多久之内完成呢。 17700(TPE)/300000(光速) * 2 = 118ms 由此可知要实现中美之间80ms以内传输是完全不行的，除非你认为塞班和关岛也算美国本土。   因此我在测试之前我就知道这个要求是根本无法实现的。 但是为了想看看aryaka的一个服务，于是还是稍微测试了一下，并用tcpdump做了记录。   要使用aryaka的服务必须先跟对方的pop点进行连接，连接了这个pop点后就可以直接通过aryaka内部的路由到达我们洛杉矶的AWS服务器上。   但是连接了之后发现，ping的延迟还是在200ms左右，于是问了aryaka的工作人员，他们说他们对tcp的连接做了加速，于是就用tcp进行测试，发现连接真的很快啊，几ms就已经建立完成了，可实际要传输数据的时候还是在200ms左右。     而从tcpdump里的数据可以看到，实际的IP并不是我发起方的一个IP，而是他们在美国的一个POP点的IP。 于是我基本可以推测出来，所谓的tcp层连接快其实是一个假象。   推测出来的结果来就是： 1. aryaka内部网络是始终保持连接的。 2. 你一旦连接了aryaka的一个pop点后，这个pop点会立刻进行返回，并告诉你连接已完成，对对端也是pop点跟对端之间连接完成就认为是连接完成。 3. 实际数据传输的时候还是走的aryaka的内部网络，这个说实话还是很快的，从北京去往洛杉矶下载可以在450KB/s， 而不走他们的网络是70KB/s。 4.  断开连接同样也是跟pop点断开就认为是全部断开了   不过测试下来感觉aryaka比较适合对于传送数据要求稳定的要求比较好，毕竟比直接介入MPLS会节省很多费用啊。不过我也没有问过aryaka的价格结算方式。

  现在欧洲国家不景气，所以都希望吸引中国人过去，但是他们又害怕你留在那里打黑工。 说如何办理吧，有了上次签西班牙的过程，这次就方便多了。法国旅游签证貌似中智都代理了，中智这中介费挣的，所以还能在芳草地这样的地方租了一层，这都是广大百姓的钱啊。 而且现在法国签证48小时就出结果了，基本3天就可以到你手上了。 首先登录 https://cn.tlscontact.com/cnBJS2fr/login.php?l=zh_CN 进行注册和预约。 需要准备的材料都大同小异，可老婆大人就怕不过，所以弄了一堆。 2寸照片2张，但是最后又给回了一张，实际就用了一张，为了这个某些人还花了35元照了个像。 公司准假证明，网上有现成的模板，就是注意要公司盖章和人事签字。 护照和复印件 户口本和复印件 资产证明：银行流水，定期存款，房本等等，反正让他们相信你不稀罕在那打工就成。 往返机票订单 住宿酒店订单 行程单 其他参照网站说明吧。 然后就填写《短期申根签证申请表》和《短期申根签证申请补充问题》 接着就提前90天预约就行了。 到了芳草地，这地真不错，以前还真不知道东大桥附近还有这么高大上的地方呢。排队，提交材料，付钱，打印发票，走人，要不了一个小时的。 签证费500多，中介费200多，真你妈够黑的。 3天后就拿到签证了，真快，比以前那个啥啥啥国家快多了。 拿到签证才是自助游的第一步呢，后面定酒店，火车，住宿，租车，拼团，参观哪些景点，这些都让球球去弄吧，我负责付款就成。 飞机票： 看来看去还是kuxun上比较便宜，老东家qunar自从收编那些小破网站后明显涨价了。 住宿: 闲booking上太贵的话就上airbnb上订吧，booking是各种旅馆和宾馆，airbnb是民宿（基本就1-2个房间的）。booking上所谓的旅馆也就是大一点的民宿而已。 买火车票： 你总不能就在巴黎待着啊。直接上欧铁中文网站买的那是有钱人。自由行的就上下面2个上买吧。 https://www.idtgv.com/en/reserver http://www.sncf.com/en/passengers 哦，说一句很多人都说付不了款，记得把自己信用卡开通3D验证。上次用了兴业的没有问题，就是货币转换费收的我肉疼，所以这次直接中行全币种卡，没有货币转换费，付款都没有问题的。 在巴黎基本坐地铁就行了，下面这个就是英文版巴黎地铁查询，貌似比天朝的要高大上很多啊。只是这个没有跟google map整合起来，导致没法在google进行搜索。 http://www.ratp.fr/plan-interactif/carteidf.php?lang=uk 法国南部就基本是靠火车是自驾了，看了很多qyer的分享公交车还是不靠谱啊。 看来今年车本必须出啊，不然以后怎么去德国和美国以及澳洲啊。

wordpress网站优化

由于图便宜，买了一个就128M内存的vps。所以非常关注性能的问题。

性能主要是2点，php和mysql的部分。

mysql的部分网上很多都有所有说到了，不启动innodb，限制binlog cache, 限制sort buffer等等。具体可以参见如下

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
34
35
36
37
38
39
40
41
42
43
44
45
46

[mysql]
no-auto-rehash

[mysqld]
user = mysql
port = 3306
open_files_limit = 600
back_log = 20
max_connections = 100
max_connect_errors = 200
table_cache = 60
external-locking = FALSE
max_allowed_packet = 16M
sort_buffer_size = 128K
join_buffer_size = 128K
thread_cache_size = 10
thread_concurrency = 8
query_cache_size = 0M
query_cache_limit = 2M
query_cache_min_res_unit = 2k
default_table_type = MyISAM
thread_stack = 192K
transaction_isolation = READ-UNCOMMITTED
tmp_table_size = 512K
max_heap_table_size = 32M
long_query_time = 1
log_long_format
server-id = 1
binlog_cache_size = 2M
max_binlog_cache_size = 4M
max_binlog_size = 512M
expire_logs_days = 7
key_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 2M
bulk_insert_buffer_size = 2M
myisam_sort_buffer_size = 4M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
skip-innodb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

php的部分。
使用fastcgi， 前端使用nginx来进行fastcgi代理。 fastcgi使用的php-fpm。

首先我们要了解track服务的特征。

一般互联网广告公司的代码都是嵌入在客户网站中的部分页面，而这些代码的体积也不会很大，因此针对这个特征我们就需要进行对应的http server的优化。

keepalive: 在很多教程中都是推荐开启keepalive，这样可以复用连接，但是在track的http server中还是建议关闭吧，毕竟很多用户连接你的服务器很长时间内只会一次的，你开启了keepalive就会造成很多的无效连接。

TCP_NODELAY： 由于track代码一般都比较小，经常只有几百个字节，而默认tcp会开启nagle算法，这个算法是鼓励发送全尺寸的的数据段，而我们的track代码可能无法填充满一个分组，于是导致等待的延时。有时候会有100ms到200ms的延时。 如果你的track代码大于1500个字节的话，那也可以开启这个算法。

Connection header: 在http的头部中有个connection的部分， 由于一般track代码只运行一次，运行完成我们就需要尽快关闭连接，所以在connection头部返回的时候我们直接变成 Connection: close以此来尽快关闭连接。

增加缓存时间： 由于很多track code不会经常经常进行更改，所以为了避免每次都下载，可以增加相应的过期时间。

track服务优化之一 ： DNS和域名 在互联网广告公司里，有一些服务是用作跟踪用户的，而这些代码嵌入的不多，qps也不高，然后文件大小也比较小，对于这样的应用我们如何进行优化呢。 我们http请求第一步开始说起。 大部分的http请求都是通过dns来进行的，这样dns解析的速度也关系到整个访问的速度。 下图中我们可以很明显的看到，这个请求最大的2个部分就是dns和内容下载。 我们知道DNS的缓存时间都由DNS设置TTL时间来决定的（除了部分local dns做强制缓存），而当一个域名在local dns中没有缓存时，local dns就会以迭代的方式去查询这个域名的解析。比如我们通过trace来模拟一个本地没有缓存的迭代过程。 下面是我们解析www.sohu.com的一个例子。 我们可以看到这里，首先是找到根域名的服务器，然后找到所有.com域名的根服务器，然后找到sohu.com域名的根服务器，然后解析了www.sohu.com， 而由于www.sohu.com做了一次cname，所以要进行解析，最终得到对应的IP地址。 而这个过程中，我们发现实际去dns.sohu.com的时间才52ms，而他去到根域名服务器和.com根域的解析时间加起来要452ms，而这个时间都是算在整个请求的时间内的。 从上可以看到加快DNS解析速度的重要性，而在local dns中缓存是重重之重。而这个第一步就是统一域名，发现国内某些广告商居然用好多域名来进行跟踪。而google却只用了一个单独域名来进行。 下图是我直接访问这家广告公司的跟踪域名，可以看到光dns解析的时间就903ms，这个还是他们使用了dnspod的服务器的情况下。 而他们的很多广告都使用了不同的域名，不过经过查询是应该用了泛域名解析。但是实际dns请求的时候还是会有延迟啊，local dns可不管是不是泛域名呢。 而这家广告商的这些域名指向最终都是同一个IP，那为什么不用单个域名呢？ 而我们看google ga，所有的ga使用的域名都是同一个。这样从dns层面减少了响应的时间。 从上面我们得到，使用单一域名在dns层面的好处是比较大的。 加快DNS解析速度的另外一个因素就是TTL时间。这个从解析速度来看自然是越大越好，比如很多根域名服务器都是缓存1周的，但是我们看到大量的还是缓存1个小时的。毕竟时间放太长，一旦网络出了问题都没办法切换。所以有些请求量很大的域名的ttl时间都是120秒左右的，就是怕万一有问题来不及切换。 这个就没有绝对的要求，全看各自的dns服务器的分布和性能了。

一年之计在于春，就列一下今年的个人计划吧。 学习开车，没办法了，必须学了，在海淀驾校还是东方时尚之间选择呢。 锻炼身体： 身体太重要了，没有这个啥都干不成啊，先继续100个俯卧撑计划。至于去游泳，现在工作实在是太忙，而且稍微有点远，所以没法保证每周3次啊，等调整好了再报名参加。每周三次，平均每次成本在15元左右，这个还是可以接受的。 法国旅行： 也土炮一次上一个热门国家，这个计划就让我们家球球做了，但是之前的学习工作还是要做的。 看完林达的《带一本书去巴黎》，简略过一下LP的内容。旅行的意义不就是了解这个国家的文化和历史来的吗？ 学习完成, 并写完整和之后的运维管理系统，主要是资产管理，监控报警，服务台内容，初始化系统和密码管理这5项内容吧。 这个东西外面看了很多，可惜没有适合自己实际情况的。虽然很不想重复造轮子，可实在是被逼的。

有台服务器，4G内存的。 可以显示可用的内存数字有1070MB， 可机器上没有什么进程占用大量的内存啊，于是就慢慢开始找原因了。 然后用了之前yufeng提供的一段内存检查的代码来进行检查，看是否有slapinfo和pagetable占用的多。http://blog.yufeng.info/archives/2456

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

#/bin/bash
for PROC in `ls /proc/|grep "^[0-9]"`
do
if [ -f /proc/$PROC/statm ]; then
  TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`

  RSS=`expr $RSS + $TEP`
fi
done
RSS=`expr $RSS * 4`
PageTable=`grep PageTables /proc/meminfo | awk '{print $2}'`
SlabInfo=`cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'`

echo $RSS"KB", $PageTable"KB", $SlabInfo"MB"
printf "rss+pagetable+slabinfo=%sMBn" `echo $RSS/1024 + $PageTable/1024 + $SlabInfo|bc`
free -m

可执行下来的结果，显示已用的vmrss+pagetable+slapinfo总共才1.4GB左右 于是想是不是一些inode占用了比较多的内存，于是在sysctl.conf中加入了如下参数将内存的caches，denties和inodes等信息sync到磁盘上

1

vm.drop_caches = 3 

可执行了sysctl后也就清理了50MB内存，那剩下的内存呢。 然后就查看/proc/meminfo，看看是否free命令有bug啊 看来这里也没有啊，这个结果跟free出来的结果是一致的。 于是就开始 /proc/PID/status 里面的vm部分进行累加计算，发现vmsize的累加的值跟这个内存使用的大小还是很接近的。

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

for PROC in `ls /proc/|grep "^[0-9]"`
do
  if [ -f /proc/$PROC/status ]; then
      TEP=`grep  'VmSize' /proc/$PROC/status |awk '{print ($2)}'`
      if [ ! -n $TEP ];
	  then
	  	TEP=0
	  fi
	  VMSIZE=`expr $VMSIZE + $TEP`
  fi
done
echo $VMSIZE