Docker 小知识

我们知道,Docker不过是通过资源隔离实现的,通过一定的手段总是可以不进入容器就可以看到(已启动)容器中的所有东西;一般来讲,我们可以通过docker命令提供的exec来进入容器,但是该方法是通过docker daemon完成的,如果docker daemon出现问题无法响应,就不好玩了; 然后,我们就会考虑通过nsenter来进入容器所在的名字空间中;

其实,就算没有nsenter,我们同样也能做一些看似很NB的事情的,如下图,195106是某容器的进程,我们就可以在宿主机上通过如下图的方式进入容器的文件系统,然后可以随意修改文件

shell 小知识点

实例:

脚本功能说明:

不断连接(然后立即断开)本地80端口;如果连接时间超过0.9s则输出连接时长并退出脚本

  1. 通过TIMEFORMAT来设置time命令的输出,time命令的选项不走参数,走环境变量;具体格式man time
  2. nc -z选项的行为是,连接后立即断开,相当于扫描; -v选项输出扫描结果提示,这里面直接扔掉了,所以该选项是多余的;nc似乎没有连接超时的设置
  3. bash不支持浮点数的运算与比较,借助bc实现;对于比较运算,为真输出1,为假输出0; 和bc的返回值无关
  4. bash中支持模运算,上面也用到了
  5. time的输出是输出到标准错误的,一般情况下我们没法直接接收到标准错误的输出,这里就把time放到了一个子shell中执行,然后将子shell的标准错误重定向到标准输出,然后赋值给变量t;所以,需要注意一点的是,time前面的两个圆括号之间是有空格的,少了空格就成了算数运算了(结果必错)

上面脚本执行比较慢,如果是多核的话,可以稍微修改一下:(该脚本未测试,可能不好使)

 

相关参考: http://blog.csdn.net/gengshenghong/article/details/7583580

上面脚本每秒中才能跑300次,怀疑time、nc命令消耗了较多的时间,“改良”脚本如下:

这里省去了time、nc,但是出现了两次date命令;测试结果和上面脚本几乎一样

参考资料: http://www.cnblogs.com/chengmo/archive/2010/10/22/1858302.html

 

如何检测是哪个进程发起了tcp主动请求

一个不能正确工作的脚本 monitor.php:

不能正确工作的原因:

  1. 可能tcpdump没有立即输出抓到的数据包,当输出时连接已经断开许久了
  2. 就算tcpdump能足够快地输出抓到的数据包,执行ss的时候也可能已断开连接(这个至少不至于一个抓不到)
  3. 就算本地主动关闭连接的情况下,连接会一段时间内处于timewait状态,但是timewait状态是不关联pid的哦

验证猜想缓存问题导致的方法:

  1. 启动检测脚本: php monitor.php
  2. nc打开百度80端口连接,然后 ctrl+z
  3. while :; do curl  http://baidu.com ;done
  4. 检测脚本输出结果部分如下:

 

解决办法:

正确的解决办法是使用systemtap: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/useful-systemtap-scripts.html#nettop

docker资源限制之cpu篇

  1. 通过 –cpu-quota 限制容器使用的cpu的配额,如:
    –cpu-quota 50000 : 最多允许使用1个核心的50%
    –cpu-quota 300000: 最多允许用满3个核心,如果只给该容器分配了2个核心,则用满2个核心为止
  2. –cpu-period (默认 50000),和–cpu-quota 一起使用
  3. 通过 –cpuset-cpus 限制容器只运行在指定的几个核心上,如:(留几个核心,避免跑死宿主机)
    –cpuset-cpus 1,2 : 允许使用1、2两个核心
    –cpuset-cpus 0-3:允许使用0、1、2、3 核心
  4. 通过 –cpu-shares 调整容器使用cpu的权重(用于实现偏心)

centos7(或者其他系统也有)上有个kworker的进程,似乎是用来分配系统时间的(可能我理解的不对),参考: http://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu

 

参考资料: https://docs.docker.com/engine/reference/run/

timewait high之 debug方法

  1.  ss -s   发现timewait好高
  2. 如果自己的client,可以看看是调用外部的哪个服务太频繁了

  3. 如果自己是server,可以看看是自己的哪个服务导致的:
  4. 或者,只统计外部服务器的IP也可能有助于找到问题的原因
  5. 。。。

解决办法:

  1. 长连接
  2. 不要主动关闭连接,如果走的是http协议,而且是别人的服务,则可以(如果对方支持的话)强制使用HTTP/1.0协议,这样的话,client端不做主动关闭,就不会有timewait;
  3. HTTP/1.1中有个Connection的头,可以设置Connection: close,server端就会主动关闭连接了

效果跟踪:下面是使用HTTP/1.0后的效果:

非主流抓包工具

httpry:

An open-source HTTP packet sniffing tool which captures live HTTP packets with libpcap library, and displays HTTP requests and responses in a human-readable format. It comes with a collection of parsing Perl scripts for mining various information from its standard output.

效果:

安装:

  1. linux下yum可以安装
  2. 其它系统编译安装,源码: https://github.com/jbittel/httpry (从源码来看,虽然是c写的,似乎可以写perl插件)

 

 

mysql sniffer: https://phpor.net/blog/post/9562

haproxy 实现http隧道代理

什么是http隧道代理?(自己搜吧)

haproxy的经典逻辑是:每个请求都分配给所配置的后端(backend)来处理;对于connect请求,原则上不需要添加配置backend的,但是这不符合haproxy的规则;测试+跟踪源代码发现: haproxy根本不能实现http隧道代理,之于option http-tunnel 配置也不过是生命不要解析第一个请求之后的数据而已,connect请求还是要原样转发给backend的