经过研究了下Linux相关代码，把对Linux Cache实现的方式做一些总结。
相关源码主要在：
./fs/fscache/cache.c    Cache实现的代码
./mm/slab.c                   SLAB管理器代码
./mm/swap.c                缓存替换算法代码
./mm/mmap.c             内存管理器代码
./mm/mempool.c       内存池实现代码

0. 预备：Linux内存管理基础

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存，而是虚拟内存，准确的说是“内存区域”。Linux除了内核以外，App都不能直接使用内存，因为Linux采用Memory Map的管理方式，App拿到的全部是内核映射自物理内存的一块虚拟内存。malloc分配很少会失败，因为malloc只是通知内存App需要内存，在没有正式使用之前，这段内存其实只在真正开始使用的时候才分配，所以malloc成功了并不代表使用的时候就真的可以拿到这么多内存。据说Google的tcmalloc改进了这一点。

进程对内存区域的分配最终多会归结到do_mmap()函数上来（brk调用被单独以系统调用实现，不用do_mmap()）。内核使用do_mmap()函数创建一个新的线性地址区间，如果创建的地址区间和一个已经存在的地址区间相邻，并且它们具有相同的访问权限的话，那么两个区间将合并为一个。如果不能合并，那么就确实需要创建一个新的VMA了。但无论哪种情况， do_mmap()函数都会将一个地址区间加入到进程的地址空间中，无论是扩展已存在的内存区域还是创建一个新的区域。同样释放一个内存区域使用函数do_ummap()，它会销毁对应的内存区域。

另一个重要的部分是SLAB分配器。在Linux中以页为最小单位分配内存对于内核管理系统物理内存来说是比较方便的，但内核自身最常使用的内存却往往是很小（远远小于一页）的内存块，因为大都是一些描述符。一个整页中可以聚集多个这种这些小块内存，如果一样按页分配，那么会被频繁的创建/销毁，开始是非常大的。

为了满足内核对这种小内存块的需要，Linux系统采用了SLAB分配器。Slab分配器的实现相当复杂，但原理不难，其核心思想就是Memory Pool。内存片段（小块内存）被看作对象，当被使用完后，并不直接释放而是被缓存到Memory Pool里，留做下次使用，这就避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片带来的不便，而且可以很好利用硬件缓存提高访问速度。但Slab仍然是建立在页面基础之上，Slab将页面分成众多小内存块以供分配，Slab中的对象分配和销毁使用kmem_cache_alloc与kmem_cache_free。

关于SALB分配器有一份资料：http://lsec.cc.ac.cn/~tengfei/doc/ldd3/ch08s02.html
关于内存管理的两份资料：http://lsec.cc.ac.cn/~tengfei/doc/ldd3/ch15.html
http://memorymyann.javaeye.com/blog/193061

1. Linux Cache的体系

在 Linux 中，当App需要读取Disk文件中的数据时，Linux先分配一些内存，将数据从Disk读入到这些内存中，然后再将数据传给App。当需要往文件中写数据时，Linux先分配内存接收用户数据，然后再将数据从内存写到Disk上。Linux Cache 管理指的就是对这些由Linux分配，并用来存储文件数据的内存的管理。

下图描述了 Linux 中文件 Cache 管理与内存管理以及文件系统的关系。从图中可以看到，在 Linux 中，具体的文件系统，如 ext2/ext3/ext4 等，负责在文件 Cache和存储设备之间交换数据，位于具体文件系统之上的虚拟文件系统VFS负责在应用程序和文件 Cache 之间通过 read/write 等接口交换数据，而内存管理系统负责文件 Cache 的分配和回收，同时虚拟内存管理系统(VMM)则允许应用程序和文件 Cache 之间通过 memory map的方式交换数据，FS Cache底层通过SLAB管理器来管理内存。

下图则非常清晰的描述了Cache所在的位置，磁盘与VFS之间的纽带。

2. Linux Cache的结构

在 Linux 中，文件 Cache 分为两层，一是 Page Cache，另一个 Buffer Cache，每一个 Page Cache 包含若干 Buffer Cache。内存管理系统和 VFS 只与 Page Cache 交互，内存管理系统负责维护每项 Page Cache 的分配和回收，同时在使用 memory map 方式访问时负责建立映射；VFS 负责 Page Cache 与用户空间的数据交换。而具体文件系统则一般只与 Buffer Cache 交互，它们负责在外围存储设备和 Buffer Cache 之间交换数据。读缓存以Page Cache为单位，每次读取若干个Page Cache，回写磁盘以Buffer Cache为单位，每次回写若干个Buffer Cache。
Page Cache、Buffer Cache、文件以及磁盘之间的关系如下图所示。

Page 结构和 buffer_head 数据结构的关系如下图所示。Page指向一组Buffer的头指针，Buffer的头指针指向磁盘块。在这两个图中，假定了 Page 的大小是 4K，磁盘块的大小是 1K。

在 Linux 内核中，文件的每个数据块最多只能对应一个 Page Cache 项，它通过两个数据结构来管理这些 Cache 项，一个是 Radix Tree，另一个是双向链表。Radix Tree 是一种搜索树，Linux 内核利用这个数据结构来通过文件内偏移快速定位 Cache 项，图 4 是 radix tree的一个示意图，该 radix tree 的分叉为4(22)，树高为4，用来快速定位8位文件内偏移。Linux(2.6.7) 内核中的分叉为 64(26)，树高为 6(64位系统)或者 11(32位系统)，用来快速定位 32 位或者 64 位偏移，Radix tree 中的每一个到叶子节点的路径上的Key所拼接起来的字串都是一个地址，指向文件内相应偏移所对应的Cache项。

查看Page Cache的核心数据结构struct address_space就可以看到上述结构（略去了无关结构）：

struct address_space  {
struct inode             *host;              /* owner: inode, block_device */
struct radix_tree_root      page_tree;         /* radix tree of all pages */
unsigned long           nrpages;  /* number of total pages */
struct address_space       *assoc_mapping;      /* ditto */
......
} __attribute__((aligned(sizeof(long))));

下面是一个Radix Tree实例：

另一个数据结构是双向链表，Linux内核为每一片物理内存区域(zone) 维护active_list和inactive_list两个双向链表，这两个list主要用来实现物理内存的回收。这两个链表上除了文件Cache之 外，还包括其它匿名(Anonymous)内存，如进程堆栈等。

相关数据结构如下：

truct page{
    struct list_head list;   //通过使用它进入下面的数据结构free_area_struct结构中的双向链队列
    struct address_space * mapping;   //用于内存交换的数据结构
    unsigned long index;//当页面进入交换文件后
    struct page *next_hash; //自身的指针，这样就可以链接成一个链表
    atomic t count; //用于页面交换的计数,若页面为空闲则为0，分配就赋值1，没建立或恢复一次映射就加1，断开映射就减一
    unsigned long flags;//反应页面各种状态，例如活跃，不活跃脏，不活跃干净，空闲
   struct list_head lru;
   unsigned long age; //表示页面寿命
   wait_queue_head_t wait;
   struct page ** pprev_hash;
   struct buffer_head * buffers;
   void * virtual
   struct zone_struct * zone; //指向所属的管理区
}
typedef struct free_area_struct {
    struct list_head free_list;   //linux 中通用的双向链队列
    unsigned int * map;
} free_area_t;
typedef struct zone_struct{
    spinlock_t        lock;
    unsigned long offset;  //表示该管理区在mem-map数组中，起始的页号
    unsigned long free pages;
    unsigned long inactive_clean_pages;
    unsigned long inactive_dirty_pages;
    unsigned pages_min, pages_low, pages_high;
    struct list_head inactive_clean_list;   //用于页面交换的队列，基于linux页面交换的机制。这里存贮的是不活动“干净”页面
    free_area_t free_area[MAX_ORDER]; //一组“空闲区间”队列，free_area_t定义在上面，其中空闲下标表示的是页面大小，例如：数组第一个元素0号，表示所有区间大小为2的 0次方的页面链接成的双向队列，1号表示所有2的1次方页面链接链接成的双向队列，2号表示所有2的2次方页面链接成的队列，其中要求是这些页面地址连续
    char * name;
    unsigned long size;
    struct pglist_data * zone_pgdat;   //用于指向它所属的存贮节点，及下面的数据结构
    unsigned  long  zone_start_paddr;
    unsigned  long    zone_start_mapnr;
    struct page * zone_mem_map;
} zone_t;

3. Cache预读与换出

Linux 内核中文件预读算法的具体过程是这样的：
对于每个文件的第一个读请求，系统读入所请求的页面并读入紧随其后的少数几个页面(不少于一个页面，通常是三个页 面)，这时的预读称为同步预读。对于第二次读请求，如果所读页面不在Cache中，即不在前次预读的group中，则表明文件访问不是顺序访问，系统继续 采用同步预读；如果所读页面在Cache中，则表明前次预读命中，操作系统把预读group扩大一倍，并让底层文件系统读入group中剩下尚不在 Cache中的文件数据块，这时的预读称为异步预读。无论第二次读请求是否命中，系统都要更新当前预读group的大小。
此外，系统中定义了一个 window，它包括前一次预读的group和本次预读的group。任何接下来的读请求都会处于两种情况之一：
第一种情况是所请求的页面处于预读 window中，这时继续进行异步预读并更新相应的window和group；
第二种情况是所请求的页面处于预读window之外，这时系统就要进行同步 预读并重置相应的window和group。
下图是Linux内核预读机制的一个示意图，其中a是某次读操作之前的情况，b是读操作所请求页面不在 window中的情况，而c是读操作所请求页面在window中的情况。

Linux内核中文件Cache替换的具体过程是这样的：刚刚分配的Cache项链入到inactive_list头部，并将其状态设置为active，当内存不够需要回收Cache时，系统首先从尾部开始反向扫描 active_list并将状态不是referenced的项链入到inactive_list的头部，然后系统反向扫描inactive_list，如果所扫描的项的处于合适的状态就回收该项，直到回收了足够数目的Cache项。其中Active_list的含义是热访问数据，及多次被访问的，inactive_list是冷访问数据，表示尚未被访问的。如果数据被访问了，Page会被打上一个Refrence标记，如果Page没有被访问过，则打上Unrefrence标记。这些处理在swap.c中可以找到。
下图也描述了这个过程。

下面的代码描述了一个Page被访问它的标记为变化：

*
 * Mark a page as having seen activity.
 *
 * inactive,unreferenced        ->      inactive,referenced
 * inactive,referenced          ->      active,unreferenced
 * active,unreferenced          ->      active,referenced
 */
void mark_page_accessed(struct page *page)
{
        if (!PageActive(page) && !PageUnevictable(page) &&
                        PageReferenced(page) && PageLRU(page)) {
                activate_page(page);
                ClearPageReferenced(page);
        } else if (!PageReferenced(page)) {
                SetPageReferenced(page);
        }
}

参考文章：
http://lsec.cc.ac.cn/~tengfei/doc/ldd3/
http://memorymyann.javaeye.com/blog/193061
http://www.cublog.cn/u/20047/showart.php?id=121850
http://blog.chinaunix.net/u2/74194/showart_1089736.html
关于内存管理，Linux有一个网页：http://linux-mm.org/

类似的文章

• 2009年12月14日 -- Buffer与Cache (1)
• 2009年10月20日 -- [转]手工释放Linux内存——/proc/sys/vm/drop_caches (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)

相信很多人都对Linux中top命令里“load average”这一栏困惑过，到底什么是Load，Load代表了什么含义，Load高会有什么后果？“%CPU”这一栏为什么会超过100%，它是如何计算的？
带着这些问题，我们通过一些测试，来探索下其中的不解之处。

首先，我们通过实验来大概确定其计算方式：
测试服务器：4核Xeon处理器
测试软件：MySQL 5.1.40
服务器上除了MySQL没有运行其他任何非系统自带软件。因为MySQL只能单线程运行单条SQL，所以可以很好的通过增加查询并发来控制使用的CPU核数。

空载时，top的信息为：

top – 14:51:47 up 35 days, 4:43, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.5%id, 0.1%wa, 0.2%hi, 0.2%si, 0.0%st

在数据库中启动一个大查询：

top – 15:28:09 up 35 days, 5:19, 3 users, load average: 0.99, 0.92, 0.67
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 96.3%id, 0.0%wa, 1.3%hi, 2.3%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 98.7%us, 1.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

同时可以看到%CPU也是在100%

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
877 mysql 15 0 308m 137m 4644 S 99.9 6.8 15:13.28 mysqld

然后开启第二个大查询，不久就可以看到top信息的变化，Load到了2：

top – 15:36:44 up 35 days, 5:28, 3 users, load average: 1.99, 1.62, 1.08
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 97.7%id, 0.0%wa, 1.0%hi, 1.3%si, 0.0%st
Cpu1 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

也可以观察到%CPU增加到了200%：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
877 mysql 15 0 312m 141m 4644 S 199.8 7.0 22:31.27 mysqld

由此可以简单的做出如下临时结论：
1. %CPU是由每个核的CPU占用律之和算出来的。
2. load跟执行的任务数有关
不过要想准确的知道其含义，还是必须从源码入手。

CPU利用率的计算方法

下载busybox的源码，在procps目录下有top.c的源码，查看第293行附近（1.17.1版），可以看到

if (prev_hist_count) do {
        if (prev_hist[i].pid == pid) {
                cur->pcpu = cur->ticks - prev_hist[i].ticks;
                total_pcpu += cur->pcpu;
                break;
        }
        i = (i+1) % prev_hist_count;
        /* hist_iterations++; */
} while (i != last_i);

这就是计算%CPU的代码，很明显total_pcpu就是累加了每个线程对每个核的使用率，所以%CPU的最大值就是核数*100%。

而CPU利用率又是怎么计算的呢，跟踪代码可以发现，是从系统的/proc/stat这里读取的，这个文件的格式可以参考：http://www.linuxhowtos.org/System/procstat.htm，下面是我笔记本上读出来的内容。

plx@plinux-Laptop:~/busybox-1.17.1$ cat /proc/stat
cpu 520529 3525 658608 3500749 210662 6650 29698 0 0
cpu0 249045 1936 466387 1624486 136381 308 17051 0 0
cpu1 271483 1588 192221 1876263 74281 6342 12646 0 0
intr 84067574 42497789 41743 0 0 0 0 0 0 1 57928 0 0 7175 0 0 0 477092 24693 0 5 0 183 0 20 0 0 0 12455 821851 745906 10192555 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 142313984
btime 1281403521
processes 6707
procs_running 2
procs_blocked 0
softirq 56932805 0 20168080 9440286 238191 821787 0 10621375 4052209 13257 11577620

cpuN的含义从左到右分别是：user、system、nice、idle、iowait、irq、softirq，具体含义可以看文档。
在下面几行的含义是：
“intr”这行给出中断的信息，第一个为自系统启动以来，发生的所有的中断的次数；然后每个数对应一个特定的中断自系统启动以来所发生的次数。
“ctxt”给出了自系统启动以来CPU发生的上下文交换的次数。
“btime”给出了从系统启动到现在为止的时间，单位为秒。
“processes (total_forks) 自系统启动以来所创建的任务的个数目。
“procs_running”：当前运行队列的任务的数目。
“procs_blocked”：当前被阻塞的任务的数目。
那么CPU利用率可以使用以下方法，先取两个采样点，然后计算其差值：

cpu usage=(idle2-idle1)/(cpu2-cpu1)*100 cpu usage=[(user_2 +sys_2+nice_2) - (user_1 + sys_1+nice_1)]/(total_2 - total_1)*100;

这是一段Bash代码采集利用率的，摘自网络：

#!/bin/sh
##echo user nice system idle iowait irq softirq
CPULOG_1=$(cat /proc/stat | grep 'cpu ' | awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}')
SYS_IDLE_1=$(echo $CPULOG_1 | awk '{print $4}')
Total_1=$(echo $CPULOG_1 | awk '{print $1+$2+$3+$4+$5+$6+$7}')
 
sleep 5
 
CPULOG_2=$(cat /proc/stat | grep 'cpu ' | awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}')
SYS_IDLE_2=$(echo $CPULOG_2 | awk '{print $4}')
Total_2=$(echo $CPULOG_2 | awk '{print $1+$2+$3+$4+$5+$6+$7}') 
 
SYS_IDLE=`expr $SYS_IDLE_2 - $SYS_IDLE_1`
 
Total=`expr $Total_2 - $Total_1`
SYS_USAGE=`expr $SYS_IDLE/$Total*100 |bc -l`
 
SYS_Rate=`expr 100-$SYS_USAGE |bc -l`
 
Disp_SYS_Rate=`expr "scale=3; $SYS_Rate/1" |bc`
echo $Disp_SYS_Rate%

还有一段Perl的代码，也是摘自网络：

#!/usr/bin/perl
use warnings;
 
$SLEEPTIME=5;
 
if (-e "/tmp/stat") {
	unlink "/tmp/stat";
}
open (JIFF_TMP, ">>/tmp/stat") || die "Can't open /proc/stat file!\n";
open (JIFF, "/proc/stat") || die "Can't open /proc/stat file!\n";
@jiff_0=;
print JIFF_TMP $jiff_0[0] ;
close (JIFF);
 
sleep $SLEEPTIME;
 
open (JIFF, "/proc/stat") || die "Can't open /proc/stat file!\n";  @jiff_1=;
print JIFF_TMP $jiff_1[0];
close (JIFF);
close (JIFF_TMP);
 
@USER=`awk '{print \$2}' "/tmp/stat"`;
@NICE=`awk '{print \$3}' "/tmp/stat"`;
@SYSTEM=`awk '{print \$4}' "/tmp/stat"`;
@IDLE=`awk '{print \$5}' "/tmp/stat"`;
@IOWAIT=`awk '{print \$6}' "/tmp/stat"`;
@IRQ=`awk '{print \$7}' "/tmp/stat"`;
@SOFTIRQ=`awk '{print \$8}' "/tmp/stat"`;
 
$JIFF_0=$USER[0]+$NICE[0]+$SYSTEM[0]+$IDLE[0]+$IOWAIT[0]+$IRQ[0]+$SOFTIRQ[0];
$JIFF_1=$USER[1]+$NICE[1]+$SYSTEM[1]+$IDLE[1]+$IOWAIT[1]+$IRQ[1]+$SOFTIRQ[1];
$SYS_IDLE=($IDLE[0]-$IDLE[1]) / ($JIFF_0-$JIFF_1) * 100;  $SYS_USAGE=100 - $SYS_IDLE;
 
printf ("The CPU usage is %1.2f%%\n",$SYS_USAGE);

Load的计算方法

跟踪busybox的代码可以知道，load是从/proc/loadavg中读取的。
我本机的一次抓取内容如下：

plx@plinux-Laptop:~/busybox-1.17.1$ cat /proc/loadavg
0.64 0.81 0.86 3/364 6930

每个值的含义依次为：
lavg_1 (0.64) 1-分钟平均负载
lavg_5 (0.81) 5-分钟平均负载
lavg_15(0.86) 15-分钟平均负载
nr_running (3) 在采样时刻，运行队列的任务的数目，与/proc/stat的procs_running表示相同意思
nr_threads (364) 在采样时刻，系统中活跃的任务的个数（不包括运行已经结束的任务）
last_pid(6930) 最大的pid值，包括轻量级进程，即线程。
假设当前有两个CPU，则每个CPU的当前任务数为0.64/2=0.32

我们可以在Linux内核中找到loadavg文件的源码：

tatic int loadavg_read_proc(char *page, char **start, off_t off,
                                 int count, int *eof, void *data)
{
        int a, b, c;
        int len;
#
 
        a = avenrun[0] + (FIXED_1/200);
        b = avenrun[1] + (FIXED_1/200);
        c = avenrun[2] + (FIXED_1/200);
        len = sprintf(page,"%d.%02d %d.%02d %d.%02d %ld/%d %d\n",
                LOAD_INT(a), LOAD_FRAC(a),
                LOAD_INT(b), LOAD_FRAC(b),
                LOAD_INT(c), LOAD_FRAC(c),
                nr_running(), nr_threads, last_pid);
        return proc_calc_metrics(page, start, off, count, eof, len);
}

以及计算load的代码：

#define FSHIFT      11          /* nr of bits of precision */
#define FIXED_1     (1<<FSHIFT) /* 1.0 as fixed-point(定点) */
#define LOAD_FREQ   (5*HZ)      /* 5 sec intervals，每隔5秒计算一次平均负载值 */
#define CALC_LOAD(load, exp, n)     \
         load *= exp;               \
         load += n*(FIXED_1 - exp); \
         load >>= FSHIFT;
 
unsigned long avenrun[3];
 
EXPORT_SYMBOL(avenrun);
 
/*
* calc_load - given tick count, update the avenrun load estimates.
* This is called while holding a write_lock on xtime_lock.
*/
static inline void calc_load(unsigned long ticks)
{
        unsigned long active_tasks; /* fixed-point */
        static int count = LOAD_FREQ;
        count -= ticks;
        if (count < 0) {
                count += LOAD_FREQ;
                active_tasks = count_active_tasks();
                CALC_LOAD(avenrun[0], EXP_1, active_tasks);
                CALC_LOAD(avenrun[1], EXP_5, active_tasks);
                CALC_LOAD(avenrun[2], EXP_15, active_tasks);
        }
}

看了大师的文章，理解了这些代码。
所以可以明白：Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数。 Linux的系统负载指运行队列的平均长度，也就是等待CPU的平均进程数。因为Linux内禁止浮点运算，因此系统的负载只能通过计算变化的次数这一修正值来计算。Linux内核定义一个长度为3的双字数组avenrun，双字的低11位用于存放负载的小数部分，高21位用于存放整数部分。当进程所耗的 CPU时间片数超过CPU在5秒内能够提供的时间片数时，内核计算上述的三个负载。负载初始化为0，假设最近1、5、15分钟内的平均负载分别为 load1、load5和load15，那么下一个计算时刻到来时，内核通过下面的算式计算负载：
load1 -= load1 -* exp(-5 / 60) -+ n * (1 – exp(-5 / 60 ))
load5 -= load5 -* exp(-5 / 300) + n * (1 – exp(-5 / 300))
load15 = load15 * exp(-5 / 900) + n * (1 – exp(-5 / 900))
其中，exp(x)为e的x次幂，n为当前运行队列的长度。Linux内核认为进程的生存时间服从参数为1的指数分布，指数分布的概率密度为：以内核计算负载load1为例，设相邻两个计算时刻之间系统活动的进程集合为S0。从1分钟前到当前计算时刻这段时间里面活动的load1个进程，设他们的集合是 S1，内核认为的概率密度是:λe-λx，而在当前时刻活动的n个进程，设他们的集合是Sn内核认为的概率密度是1-λe-λx。其中x = 5 / 60，因为相邻两个计算时刻之间进程所耗的CPU时间为5秒，而考虑的时间段是1分钟(60秒)。那么可以求出最近1分钟系统运行队列的长度：
load1 = |S1| -* λe-λx + |Sn| * (1-λe-λx) = load1 * λe-λx + n * (1-λe-λx)
其中λ = 1， x = 5 / 60， |S1|和|Sn|是集合元素的个数，这就是Linux内核源文件shed.c的函数calc_load()计算负载的数学依据。


所以“Load值=CPU核数”，这是最理想的状态，没有任何竞争，一个任务分配一个核。
由于数据是每隔5秒钟检查一次活跃的进程数，然后根据这个数值算出来的。如果这个数除以CPU的核数，结果高于5的时候就表明系统在超负荷运转了。

类似的文章

• 2009年10月21日 -- [转]Linux中查看系统资源占用情况的命令 (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年08月27日 -- Linux Cache 机制探究 (1)

今天重启一台数据库主机（Solaris系统），结果在重启时报出了错误：

cannot mount ‘/export/home/alt’: directory is not empty

SA折腾许久不能解决，查看ZFS Administration Guide，发现一条这样的描述：

By default, ZFS does not allow mounting on top of a non-empty directory. To force a mount on top of a non-empty directory, the -O option must be used.

原来是默认不允许挂载在一个非空目录的顶部，文档也给出了方案，-O参数。

zfs mount -O data/mysqldata

这样就可以强制挂载上去了。

不过据说mount -F zfs data/mysqldata这样旧的方式挂载也是OK的。

有时候，很多答案都在文档里了，只是我们不Care。

类似的文章

• 2010年05月21日 -- Solaris双Master结构主机更换磁盘方案 (0)
• 2010年05月21日 -- Solaris下crontab不执行的问题 (0)

今天在Solaris服务器上发现crontab脚本都没有执行，很诧异。
Google之发现，Solaris对于没有密码、没有被启用、密码失效的用户是不执行crontab的。
查看/var/cron/log，果然发现很多bad user(mysql)。
由于新装的机器，明天还要操作，所以密码还没来得及设置，于是就bad user了。
passwd设置密码后，看到日志里一些人物已经有pid了。
以后服务器装系统不应图方便，装完就立刻设置密码～

类似的文章

• 2010年07月22日 -- ZFS挂载时directory is not empty问题 (1)
• 2010年05月21日 -- Solaris双Master结构主机更换磁盘方案 (0)

为了轻量，我的Gentoo Linux用的Xfce桌面系统，一切都还不错，今天装ZendStudio遇到了些问题，记下。

安装的时候都很正常，解压下载的压缩包得到.bin文件，然后安装，也没有错，但是一启动就挂了。
查看了/home/plx/Zend/workspace/DefaultWorkspace7/.metadata/.log 发现如下异常：

!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: XPCOM error -2147467262
 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:1688)
 at org.eclipse.swt.browser.Mozilla.setText(Mozilla.java:1911)
 at org.eclipse.swt.browser.Browser.setText(Browser.java:750)
 at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.generateContentForPage(BrowserIntroPartImplementation.java:363)
 at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.dynamicStandbyStateChanged(BrowserIntroPartImplementation.java:577)
 at org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.doStandbyStateChanged(BrowserIntroPartImplementation.java:784)
 at org.eclipse.ui.internal.intro.impl.model.AbstractIntroPartImplementation.standbyStateChanged(AbstractIntroPartImplementation.java:249)
 at org.eclipse.ui.internal.intro.impl.model.IntroPartPresentation.standbyStateChanged(IntroPartPresentation.java:443)
 at org.eclipse.ui.intro.config.CustomizableIntroPart.standbyStateChanged(CustomizableIntroPart.java:266)
 at org.eclipse.ui.internal.ViewIntroAdapterPart$2.run(ViewIntroAdapterPart.java:74)
 at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
 at org.eclipse.ui.internal.ViewIntroAdapterPart.setStandby(ViewIntroAdapterPart.java:70)
 at org.eclipse.ui.internal.ViewIntroAdapterPart$1.propertyChanged(ViewIntroAdapterPart.java:55)
 at org.eclipse.ui.internal.WorkbenchPartReference.fireInternalPropertyChange(WorkbenchPartReference.java:375)
 at org.eclipse.ui.internal.WorkbenchPartReference.fireZoomChange(WorkbenchPartReference.java:540)
 at org.eclipse.ui.internal.PartPane.setZoomed(PartPane.java:356)
 at org.eclipse.ui.internal.PartStack.setZoomed(PartStack.java:1526)
 at org.eclipse.ui.internal.PartSashContainer.zoomIn(PartSashContainer.java:884)
 at org.eclipse.ui.internal.PartSashContainer.childRequestZoomIn(PartSashContainer.java:905)
 at org.eclipse.ui.internal.LayoutPart.requestZoomIn(LayoutPart.java:354)
 at org.eclipse.ui.internal.PartStack.setState(PartStack.java:1501)
 at org.eclipse.ui.internal.WorkbenchPage.setState(WorkbenchPage.java:3872)
 at org.eclipse.ui.internal.WorkbenchPage.toggleZoom(WorkbenchPage.java:3944)
 at org.eclipse.ui.internal.WorkbenchIntroManager.setIntroStandby(WorkbenchIntroManager.java:201)
 at org.eclipse.ui.internal.WorkbenchIntroManager.showIntro(WorkbenchIntroManager.java:136)
 at org.eclipse.ui.application.WorkbenchWindowAdvisor.openIntro(WorkbenchWindowAdvisor.java:173)
 at org.eclipse.ui.internal.ide.application.IDEWorkbenchWindowAdvisor.openIntro(IDEWorkbenchWindowAdvisor.java:458)
 at org.eclipse.ui.internal.WorkbenchWindow.open(WorkbenchWindow.java:777)
 at org.eclipse.ui.internal.Workbench$22.runWithException(Workbench.java:1041)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
 at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
 at org.eclipse.ui.internal.Workbench$27.runWithException(Workbench.java:1361)
 at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
 at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
 at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
 at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
 at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2293)
 at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
 at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
 at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
 at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
 at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
 at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:370)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
 at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

我以为是我没装JRE，但是安装目录下有JRE，Zend应该是调用自带的。
Google之，有人说删除xulrunner，我这依赖xulrunner的软件太多，不可能删。

发现有人说是少了个参数，
-Dorg.eclipse.swt.browser.XULRunnerPath=
这个java系统参数应该指定一个目录，但是这里可以任意写或者空着。
在添加该行后，重新启动ZendStudio，然后就可以把该行删除，以后再启动都不会报错了。
同理，因为ZendStudio基于Eclipse，所以Eclipse也适用。

类似的文章

• 2010年01月18日 -- Linux下编译PHP的几种错误 (1)
• 2009年10月14日 -- ORM or ROM？ (0)
• 2009年07月15日 -- Nginx 0.7.x + PHP 5.2.10（FastCGI）搭建胜过Apache十倍的Web服务器 (0)

周末遇到一个问题，数据库主机不断地报：NTP WARNING: Offset XXX secs。
肯定就是NTP同步时间出问题了。
首先简单介绍一下NTP：“NTP协议全称网络时间协议（Network Time Procotol）。它的目的是在国际互联网上传递统一、标准的时间。具体的实现方案是在网络上指定若干时钟源网站，为用户提供授时服务，并且这些网站间应该能够相互比对，提高准确度。”
我们内网也是有NTP服务器的，为什么同步会出现这么大的Offset？
登陆机器查看情况，首先看ntpstat

synchronised to local net at stratum 11
time correct to within 11 ms
polling server every 1024 s

很奇怪，为什么是local net？
查看配置文件/etc/ntp.conf，没有什么异常。
对比了其他服务器，发现server的配置不一样，怀疑可能是这台机器设置的server不可用，ping了一下，果然不通，确定了是内网NTP服务器设置的问题。
把其他服务器上配置的三个地址拷贝过来，/etc/init.d/ntpd restart，竟然出现了fail！

Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [FAILED]
Starting ntpd: [ OK ]

为什么Fail，已经修改过server地址了，并且其他服务器也是这个server就能同步。
再检查/etc/ntp/目录下的文件，发现一个step-tickers文件，里面写的是原先错误的server ip，于是修改之再次重启/etc/init.d/ntpd restart，
这次正常了

Shutting down ntpd: [ OK ]
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]

过一会再看ntpstst，也正常了。

synchronised to NTP server (X.X.X.X) at stratum 3
time correct to within 11 ms
polling server every 64 s

随机显示文章

• 2009年05月24日 -- RedHat Enterprise Linux在IBM System x服务器上的调优 (0)
• 2010年05月25日 -- 我的生活品质 (7)
• 2010年03月29日 -- 项目管理的可控性讨论 (0)

最近对我的本本（4核8线程）用top命令看系统状况出现了CPU利用率超过200%的情况，非常诧异，查了下相关资料，把这个问题弄清楚了。
首先来分析下CPU Load

load average: 0.09, 0.05, 0.01

分别是1分钟、5分钟、15分钟的平均Load。
Load这个东西怎么理解呢，就像一条马路，有N个车道，如果N个进程进入车道，那么正好一人一个，再多一辆车就占不到车道，要等有一个车空出车道。
在CPU中可以理解为CPU可以并行处理的任务数，那么就是“CPU个数 * 核数”，如果CPU Load = CPU个数 * 核数 那么就是说CPU正好满负载，再多一点，可能就要出问题了，有任务不能被及时分配处理器，那么保证性能的话，最好是小于CPU个数 * 核数 *0.7。

查看CPU核数可以通过：grep ‘model name’ /proc/cpuinfo

那么以哪个平均值为准呢？如果1分钟平均出现大于CPU个数 * 核数的情况，还不用担心，如果5分钟平均也是，那就要警惕了，15分钟平均也是这样，就要分析哪里出问题了，防范于未然
CPU利用率超过100%的问题，也是差不多，top命令应该是把每个核的CPU占用率加起来，算一个和，于是多核情况下会出现超过100%。

另外Context Switch Rate也是个非常值得注意的值，因为线程间切换的代价也是非常高的。

引用一个公式：Context Switch Rate = Interrupt Rate + TPS* N

对于一个多线程的程序，我觉得准备一个控制线程来调度任务是非常必要的，免得线程过于高并发，导致资源的争用和线程切换带来性能问题，最好控制并发的线程数基本等于CPU的总核数，减少这个N，获得更好的处理器性能。

参考了如下几篇文章：
压力测试衡量CPU的三个指标：CPU Utilization、Load Average和Context Switch Rate
理解Load Average做好压力测试
理解 Linux 的处理器负载均值
高性能服务器架构

PS. 最近博客写得少，都要长草了。顺便赞一下阿里的食堂，比我们学校食堂四年不变菜饭还贵好多了。

随机显示文章

• 2010年04月9日 -- Xfce下ZendStudio的报错处理 (0)
• 2010年04月4日 -- 每周推特 2010-04-04 (0)
• 2010年03月29日 -- 项目管理的可控性讨论 (0)

为什么我喜欢采用源码编译来配置服务器，张宴老师给出了很好的解释：

“ 之所以编译安装，而不采用RPM包安装，有以下几个方面的原因：
1、编译安装的自由度很大，需要哪些功能模块，就编译哪些功能模块，用不到的可以不安装，需要哪些参数，就加上哪些差数，能够节省系统资源，充分发挥性能优势；
2、一些自行开发的模块，或对程序源码作出的修改，必须通过编译安装才能实现；
3、编译安装的程序配置起来很方便；
4、我编译安装都是用SecureCRT等SSH客户端软件连上服务器，直接往里面一次粘贴多行安装语句，然后干别的事，所花的时间也不长。
5、我编译安装软件的每一行步骤和整个流程，都会写入文档，交接起来很方便。 ”

类似的文章

• 2010年01月18日 -- Linux下编译PHP的几种错误 (1)

Forcing buildconf
buildconf: checking installation…
buildconf: autoconf version 2.65 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running vcsclean for you.
To avoid this, install autoconf-2.13.
Can’t figure out your VCS, not cleaning.
rebuilding configure
configure.in:492: warning: AC_CACHE_VAL(have_broken_glibc_fopen_append, …): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:2013: AC_CACHE_VAL is expanded from…
aclocal.m4:1736: PHP_BROKEN_GLIBC_FOPEN_APPEND is expanded from…
ext/mbstring/config.m4:356: warning: AC_CACHE_VAL(cv_php_mbstring_stdarg, …): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:2026: AC_CACHE_CHECK is expanded from…
ext/mbstring/config.m4:205: PHP_MBSTRING_SETUP_MBREGEX is expanded from…
ext/pdo_dblib/config.m4:71: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:2754: PHP_CHECK_PDO_INCLUDES is expanded from…
ext/pdo_firebird/config.m4:48: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_mysql/config.m4:160: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_oci/config.m4:211: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_odbc/config.m4:59: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_pgsql/config.m4:121: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_sqlite/config.m4:31: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/sqlite/config.m4:50: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/standard/config.m4:235: warning: AC_CACHE_VAL(php_can_support_proc_open, …): suspicious cache-id, must contain _cv_ to be cached
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:3585: AC_LIBTOOL_LINKER_OPTION is expanded from…
aclocal.m4:5597: _LT_AC_LANG_C_CONFIG is expanded from…
aclocal.m4:5492: AC_LIBTOOL_LANG_C_CONFIG is expanded from…
aclocal.m4:3109: AC_LIBTOOL_SETUP is expanded from…
aclocal.m4:2967: _AC_PROG_LIBTOOL is expanded from…
aclocal.m4:2947: AC_PROG_LIBTOOL is expanded from…
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:3548: AC_LIBTOOL_COMPILER_OPTION is expanded from…
aclocal.m4:8133: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from…
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:6549: _LT_AC_LANG_CXX_CONFIG is expanded from…
aclocal.m4:5605: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from…
aclocal.m4:4737: _LT_AC_TAGCONFIG is expanded from…
rebuilding main/php_config.h.in
autoheader: WARNING: Using auxiliary files such as `acconfig.h’, `config.h.bot’
autoheader: WARNING: and `config.h.top’, to define templates for `config.h.in’
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE’ and
autoheader: WARNING: `AC_DEFINE_UNQUOTED’ allows one to define a template without
autoheader: WARNING: `acconfig.h’:
autoheader:
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader:             [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
configure.in:492: warning: AC_CACHE_VAL(have_broken_glibc_fopen_append, …): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:2013: AC_CACHE_VAL is expanded from…
aclocal.m4:1736: PHP_BROKEN_GLIBC_FOPEN_APPEND is expanded from…
ext/mbstring/config.m4:356: warning: AC_CACHE_VAL(cv_php_mbstring_stdarg, …): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:2026: AC_CACHE_CHECK is expanded from…
ext/mbstring/config.m4:205: PHP_MBSTRING_SETUP_MBREGEX is expanded from…
ext/pdo_dblib/config.m4:71: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:2754: PHP_CHECK_PDO_INCLUDES is expanded from…
ext/pdo_firebird/config.m4:48: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_mysql/config.m4:160: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_oci/config.m4:211: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_odbc/config.m4:59: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_pgsql/config.m4:121: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/pdo_sqlite/config.m4:31: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/sqlite/config.m4:50: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain _cv_ to be cached
ext/standard/config.m4:235: warning: AC_CACHE_VAL(php_can_support_proc_open, …): suspicious cache-id, must contain _cv_ to be cached
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:3585: AC_LIBTOOL_LINKER_OPTION is expanded from…
aclocal.m4:5597: _LT_AC_LANG_C_CONFIG is expanded from…
aclocal.m4:5492: AC_LIBTOOL_LANG_C_CONFIG is expanded from…
aclocal.m4:3109: AC_LIBTOOL_SETUP is expanded from…
aclocal.m4:2967: _AC_PROG_LIBTOOL is expanded from…
aclocal.m4:2947: AC_PROG_LIBTOOL is expanded from…
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:3548: AC_LIBTOOL_COMPILER_OPTION is expanded from…
aclocal.m4:8133: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from…
configure.in:1347: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, …): suspicious cache-id, must contain _cv_ to be cached
aclocal.m4:6549: _LT_AC_LANG_CXX_CONFIG is expanded from…
aclocal.m4:5605: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from…
aclocal.m4:4737: _LT_AC_TAGCONFIG is expanded from…

貌似因为autoconf版本太高。

在debian下执行
aptitude install autoconf2.13
export PHP_AUTOCONF=/usr/bin/autoconf2.13
export PHP_AUTOHEADER=/usr/bin/autoheader2.13
然后再重新autoconf就行了。

64位下编译最好加上在 configure 时加参数 –with-libdir=lib64 指定使用64位库。

类似的文章

• 2009年07月9日 -- 为PHP添加数据库模块 (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年08月27日 -- Linux Cache 机制探究 (1)

我对安全方面也不是了解很多，最近遇到了安全方面的问题，查了一些资料，亲自试了试，选出一些比较重要的记录一下。

安全方面即将加入阿里云的@Natural__Light大牛给我演示过不少入侵的方法，算“资深”了，从在中学开始入侵学校网络，咱们大学里的那些破网站，@Natural__Light大牛玩一样进后台。

1. 如果要考虑安全问题，就必须有一个假设：一切用户输入的内容都是不安全的，一切参数的传递都是不安全的。入侵者可能利用每一个我们假设是安全的地方。
2. Linux方面
   • 限制用户账号，开发和运维分开。
   • SSH登陆必须限制主机来源，切忌允许全部IP登陆，最好port也要修改。
   • 使用iptables限制端口出入和IP，内部系统只能允许内部IP。
   • 注意为不同的用户甚至不同的功能区分不同的账号和用户组。
   • 为关键文件和目录一定要设置好权限，千万不能777，配合用户和分组保证只有需要的人有需要的权限，尤其是/etc下的。
3. Apache方面
   • 使用专门的账号和用户组来启动Apache。
   • 不同功能和站点的配置文件最好拆分为不同的文件。
   • 设置ServerSignature Off和ServerTokens ProductOnly，防止服务器广播敏感信息和HTTP头透露关键信息。
   • 禁止浏览目录。
   • 只监听指定的IP和端口。
   • 必要时可以修改代码伪装服务器版本信息。
   • 为每个目录建立.htaccss文件保护。
   • 只允许特定常用的User-Agent访问。
   • 利用iptables或Nginx做反向代理，过滤DDOS攻击。
4. MySQL方面
   • 必须设置MySQL目录的权限，限制访问。
   • 必须使用一个独立的用户和用户组，没有Shell，也不能运行其他程序。
   • 必须删除无用户名账户，必须修改root账户密码，并且要限制主机来源。
   • 必须删除test库，这个库任何人都可以建表，危险。
   • 为每个功能单独建账号，使用不同的密码，限制主机来源，只给需要的权限。
   • 细化权限粒度，不要给任何账户不必要的权限。
5. PHP方面
   • 一定要分析任何用户输入或者传递的参数，过滤其中的危险字符。
   • 使用系统自带的过滤函数一定要了解其机制，避免对方利用单/多字符集的方法绕过。
   • 在前端限制特殊字符被输入，接到输入后还需要再次进行过滤。
   • 系统的错误信息必须被屏蔽或者关闭，错误可以跳转。
   • 禁止采用root账户连接数据库。
   • 用专门的账户运行PHP。

总的来说最重要的就是：以最低粒度控制权限，过滤任何用户可以修改的进入系统的内容。

类似的文章

• 2009年10月13日 -- 推荐一位牛人 (0)

.tar
解包： tar xvf FileName.tar
打包：tar cvf FileName.tar DirName
（注：tar是打包，不是压缩，适合将很多小文件备份）
———————————————
.gz
解压1：gunzip FileName.gz
解压2：gzip -d FileName.gz
压缩：gzip FileName
.tar.gz
解压：tar zxvf FileName.tar.gz
压缩：tar zcvf FileName.tar.gz DirName
（一般常用的就是这个了）

———————————————
.bz2
解压1：bzip2 -d FileName.bz2
解压2：bunzip2 FileName.bz2
压缩： bzip2 -z FileName
.tar.bz2
解压：tar jxvf FileName.tar.bz2
压缩：tar jcvf FileName.tar.bz2 DirName
———————————————
.Z
解压：uncompress FileName.Z
压缩：compress FileName
.tar.Z
解压：tar Zxvf FileName.tar.Z
压缩：tar Zcvf FileName.tar.Z DirName
———————————————
.tgz
解压：tar zxvf FileName.tgz
.tar.tgz
解压：tar zxvf FileName.tar.tgz
压缩：tar zcvf FileName.tar.tgz FileName
———————————————
.zip
解压：unzip FileName.zip
压缩：zip FileName.zip DirName
———————————————
.rar
解压：rar a FileName.rar
压缩：rar e FileName.rar
（需要下一个rar程序）
———————————————
.rpm
解包：rpm2cpio FileName.rpm | cpio -div
———————————————

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年08月27日 -- Linux Cache 机制探究 (1)
• 2010年08月10日 -- Load和CPU利用率是如何算出来的 (5)

看MySQL的文档有些累了，想下载个电影看看，遂上学校FTP。
看了看Linux下FTP客户端的比较，最终选了gFTP，虽然ftp命令也能下，毕竟电脑是拿来用的不是来装B的，能省事的还是省事点。
结果登录上学校的FTP，gFTP中目录全都不显示，遂Google之。
有的人说改/usr/bin/gftp脚本，加入export LANG=zh_CN.GBK，并且用locale-gen zh_CN.GBK，不过经我实测是不行的。在日志里看获取的目录是可以正常显示，但是界面里还是不行，有的人说是gtk1和gtk2的问题之类的，我觉得应该是扯淡。
然后又看了些解决方案，说locale-gen zh_CN，光GBK没用，然后改.gftp/gftprc，在remote_charset加入gbk,gb2312,utf8等字符集，并且把export LANG改为了zh_CN，实验之，一切OK。
整理步骤就是：
locale-gen zh_CN （我不确定locale-gen zh_CN.GBK是否也必要）
在/usr/bin/gftp中加入export LANG=zh_CN。（我不确定在.gftp/gftprc中的remote_charset加入gbk等是否必要）
遇到类似情况，自己尝试吧，毕竟每个人情况可能不一样，我这里给出的是我已经解决的，我的系统是Ubuntu 9.10 64bit Gnome。

下载《世界大战》ing，最近被某人带的对2012，宇宙，外星人之类的东西很感兴趣，额……好像一致很感兴趣……

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年08月27日 -- Linux Cache 机制探究 (1)
• 2010年08月10日 -- Load和CPU利用率是如何算出来的 (5)

前些天与监控宝的同志谈起监控的两种模式，比较有意思，记录下来。

我一直比较赞同的是主动请求式的监控模式，主要原因是被动探测会给监控结点带来很大的压力，就Cacti而言，用Spine轮询，共35个设备，每分钟轮询一次，能吃掉我35%的CPU。
相比之下，通过客户机主动发送请求给监控机的Ganglia，占用资源就非常小。一台监控机估计挂200台客户机监控不是问题。
区别就在于，主动请求式是客户机把自己的监控信息主动发送给监控机，监控机只要接收这些信息处理即可。
被动探测式是监控机把监控请求发送到客户机，客户机接到请求把需要的监控信息返回给监控结点。
所以，被动探测式会给监控机带来很大的压力，因为它要不断的发请求去获取信息。

但是监控宝的同志做了个很好的比方，让我想法有了些变化。
监控机好比警察，客户机好比犯人。
不能因为警察忙，就不管犯人，让犯人主动报告自己的情况。
如果犯人突然没信息了，警察就不知道犯人是死了还是跑了。
并且如果警察调走了，犯人不知道，这一群犯人就不知道向谁报告了。
但是经常也不能老去一直问犯人的情况，那样他的工作效率就太低了。
所以二者各有好处。

首先，警察很忙的时候，让犯人主动报告自己的情况，他记着就行。
但是，一旦犯人在规定的时间没报告，警察就要主动去联系了，看看犯人到底是死了还是跑了。

还原到监控中，就是主动与被动两种方式结合起来。
一般情况下，让客户机比较高频地自己报告情况情况给监控机，同时，监控机间隔比较长的像客户机主动发送请求，检查客户机是否存活。
同时，一旦监控机在规定的时间内没收到客户机的信息，就要像客户机发请求去轮询，确认客户机的状态。

主动和被动在合适的时候都有合理的用处，像手机就是主动向基站报告自己加入，雷达又是向被监控区域发送探测信号。
任何方法都有其存在的理由，没有最好没有最坏，只有最合适！

类似的文章

• 2010年09月12日 -- 中小站点的监控利器——监控宝 (1)
• 2010年01月26日 -- 自己写的MySQL实时监控脚本–mystat (0)
• 2009年12月13日 -- Debian下开启snmpd (0)

版权声明：可以任意转载，但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2008/08/17/memcached-pdf/以及本声明。

作者已经做成PDF版，我提供一个下载副本，上面的链接里也有，下面列出目录，有兴趣的可以下载。

下载地址：Note: There is a file embedded within this post, please visit this post to download the file.

第1 章 memcached的基础…………………………………………………………………………………………………..5
1.1 memcached是什么？…………………………………………………………………………………………………5
1.2 memcached的特征…………………………………………………………………………………………………….6
协议简单……………………………………………………………………………………………………………………6
基于libevent的事件处理…………………………………………………………………………………………….6
内置内存存储方式………………………………………………………………………………………………………6
memcached不互相通信的分布式…………………………………………………………………………………6
1.3 安装memcached……………………………………………………………………………………………………….7
memcached的安装………………………………………………………………………………………………………7
memcached的启动………………………………………………………………………………………………………8
1.4 用客户端连接……………………………………………………………………………………………………………8
1.5 使用Cache::Memcached…………………………………………………………………………………………….9
使用Cache::Memcached连接memcached……………………………………………………………………..9
保存数据………………………………………………………………………………………………………………….10
获取数据………………………………………………………………………………………………………………….10
删除数据………………………………………………………………………………………………………………….10
增一和减一操作………………………………………………………………………………………………………..10
1.6 总结……………………………………………………………………………………………………………………….11

第2章 理解memcached的内存存储………………………………………………………………………………….12
2.1 Slab Allocation机制：整理内存以便重复使用………………………………………………………….12
Slab Allocation的主要术语………………………………………………………………………………………..13
2.2 在Slab中缓存记录的原理……………………………………………………………………………………….13
2.3 Slab Allocator的缺点……………………………………………………………………………………………….13
2.4 使用Growth Factor进行调优……………………………………………………………………………………14
2.5 查看memcached的内部状态……………………………………………………………………………………15
2.6 查看slabs的使用状况……………………………………………………………………………………………..16
2.7 总结……………………………………………………………………………………………………………………….17

第3 章 memcached的删除机制和发展方向………………………………………………………………………..18
3.1 memcached在数据删除方面有效利用资源……………………………………………………………….18
数据不会真正从memcached中消失…………………………………………………………………………..18
Lazy Expiration…………………………………………………………………………………………………………18
3.2 LRU：从缓存中有效删除数据的原理………………………………………………………………………18
3.3 memcached的最新发展方向…………………………………………………………………………………….18
关于二进制协议………………………………………………………………………………………………………..19
二进制协议的格式…………………………………………………………………………………………………….19
HEADER中引人注目的地方……………………………………………………………………………………..20
3.4 外部引擎支持…………………………………………………………………………………………………………20
外部引擎支持的必要性……………………………………………………………………………………………..20
简单API设计的成功的关键………………………………………………………………………………………21
重新审视现在的体系…………………………………………………………………………………………………21
3.5 总结………………………………………………………………………………………………………………………22

第4 章 memcached的分布式算法………………………………………………………………………………………23
4.1 memcached的分布式……………………………………………………………………………………………….23
memcached的分布式是什么意思？……………………………………………………………………………23
4.2 Cache::Memcached的分布式方法…………………………………………………………………………….25
根据余数计算分散…………………………………………………………………………………………………….25
根据余数计算分散的缺点………………………………………………………………………………………….26
4.3 Consistent Hashing…………………………………………………………………………………………………..27
Consistent Hashing的简单说明…………………………………………………………………………………..27
支持Consistent Hashing的函数库………………………………………………………………………………29
4.4 总结………………………………………………………………………………………………………………………29

第5 章 memcached的应用和兼容程序……………………………………………………………………………….30
5.1 mixi案例研究………………………………………………………………………………………………………….30
服务器配置和数量…………………………………………………………………………………………………….30
memcached进程………………………………………………………………………………………………………..31
memcached使用方法和客户端…………………………………………………………………………………..31
5.2 memcached应用经验……………………………………………………………………………………………….32
通过daemontools启动……………………………………………………………………………………………….33
监视…………………………………………………………………………………………………………………………33
memcached的性能…………………………………………………………………………………………………….33
5.3 兼容应用程序…………………………………………………………………………………………………………35
Tokyo Tyrant案例………………………………………………………………………………………………………35

类似的文章

• 2009年11月17日 -- 配置全功能Cacti (0)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2010年08月27日 -- Linux Cache 机制探究 (1)

今天Twitter上关于Buffer和Cache讨论得蛮火的，被各种说话一搅和，有点乱了，就干脆整理一下。
首先从翻译上，Buffer应该翻译为“缓冲”，Cache应该翻译为“缓存”，两个完全不是一个东西。
在硬件这一层看，Buffer应该为内存，Cache为CPU集成的告诉缓存。
Buffer为了让不同速度的设备能够同步，建立的一个缓冲区域，写进Buffer的数据是为了从中拿出写入其他设备。
Cache是为了提高读取速度，将经常或马上需要的数据预读到缓存中，写进Cache的数据是为了其他设备从中去读取。
从软件这一层来说，Buffer是块设备的缓冲，Cache是文件系统的缓存。以Linux为例，
Buffer(Buffer Cache)以块形式缓冲了块设备的操作，定时或手动的同步到硬盘，它是为了缓冲写操作然后一次性将很多改动写入硬盘，避免频繁写硬盘，提高写入效率。
Cache(Page Cache)以页面形式缓存了文件系统的文件，给需要使用的程序读取，它是为了给读操作提供缓冲，避免频繁读硬盘，提高读取效率。
总而言之，Buffer里面的东西是为了写到别处去，Cache里面的东西是为了给别处读。
我的理解就是这样，欢迎大牛拍砖～

类似的文章

• 2010年08月27日 -- Linux Cache 机制探究 (1)
• 2010年06月22日 -- 数据库算法与数据结构——Cache&Buffer&Lock (1)
• 2009年10月29日 -- Page Cache和Buffer Cache的区别 (0)

今天想在监控宝搞下我的网站的监控，结果SNMP怎么都获取不到信息，遂Google之。
原来是Debian默认把snmpd设置为只能本地访问，于是改动之。

修改 /etc/default/snmpd。让snmpd监听所有的网卡（默认只监听回环地址127.0.0.1，这种状况下只能本机访问snmp信息）

# snmpd options (use syslog, close stdin/out/err).
#SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1′
SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid’

类似的文章

• 2009年12月17日 -- 主动请求式与被动探测式监控的比较 (0)
• 2009年12月13日 -- aptitude命令的使用 (0)

因为VPS用的Debian 5.0 64bit系统，在查资料的时候发现不少人都推荐一个aptitude命令来代替apt-get，试用了一下删除依赖包的时候aptitude要比apt-get好，虽然apt-get也有autoremove选项，不过还是决定使用aptitude来管理包。不过发现aptitude和apt-get不能混用，要不然互相都不知道对方做了什么。

aptitude 与 apt-get 一样，是 Debian 及其衍生系统中功能极其强大的包管理工具。与 apt-get 不同的是，aptitude 在处理依赖问题上更佳一些。举例来说，aptitude 在删除一个包时，会同时删除本身所依赖的包。这样，系统中不会残留无用的包，整个系统更为干净。

类似的文章

• 2009年12月13日 -- Debian下开启snmpd (0)

重启服务器后发现Nginx在我的WordPress报502 Bad Gateway错误。
查了好久，以为是nginx.conf或者php-fpm.conf的错，突然想起来，好像哪里看到说php.ini中memory_limit设低了会出错，
修改了php.ini的memory_limit为64M，重启nginx，发现真好了~
原来是PHP的内存不足了。
360M内存的服务器，扛这点应用应该OK~

类似的文章

• 2009年07月15日 -- Nginx 0.7.x + PHP 5.2.10（FastCGI）搭建胜过Apache十倍的Web服务器 (0)

今天终于配置好了Cacti，加入了MySQL/Linux/Apache/Memcached/Nigix模板。
主要遇到的一个问题是修改轮询时间，默认5分钟，我想改成1分钟。
要修改的地方是/etc/cron.d/cacti，改成1分钟间隔，*/1 * * * * root php /var/www/cacti/poller.php &>/dev/null
然后最好先设置好轮询间隔再导入模板，这样可以在导入的时候把模板的间隔也改掉，否则要手动去改。
修改了轮询时间需要重建轮询索引，最好还要关闭所有的设备再启动，怕有轮询器还没关闭。

过程很多地方有了：
1062错误的解决方法：

http://yadayadayada.nl/archives/2009/04/000779-tuning_cacti_with_the_spine_poller_the_solution.html

http://yadayadayada.nl/archives/2008/11/000750-tuning_cacti_with_the_spine_poller_mysql_error_1062_.html

采用SSH方式监控：http://code.google.com/p/mysql-cacti-templates/wiki/SSHBasedTemplates
MySQL模板安装方法：http://xok.la/2009/05/cacti_mysql_monitor.html
Cacti源代码安装方法：http://www.askwan.com/post/48/
Cacti中文版安装方法：http://hi.baidu.com/%C2%ED%B3%A4%D5%F72008/blog/item/566cbb440ac6742fcefca347.html

类似的文章

• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2009年12月15日 -- [转] memcached完全剖析 (0)
• 2009年10月25日 -- MySQL GUI Tool在Linux下运行 (0)

在NinGoo大牛博客上看到了这个性能测试工具，就拿下来试试，不过编译的时候遇到了些问题。

出现类似下面的错误

../libtool: line 2412: Xsysbench: command not found
../libtool: line 2547: X-lmysqlclient_r: command not found
../libtool: line 2547: X-lz: command not found
../libtool: line 2547: X-lcrypt: command not found

经查只要执行./autogen.sh再进行configure就行了。

当出现：


FATAL: unable to connect to MySQL server, aborting…
FATAL: error 1049: Unknown database ‘test’
FATAL: failed to connect to database server!

只需要指定–mysql-db=test（一个已存在的数据库）就可以了。

参考文章：

http://www.ningoo.net/html/2009/performance_test_tool_sysbench.html

http://cqfish.blog.51cto.com/622299/159604

随机显示文章

• 2011年01月6日 -- ICC静态编译Percona (9)
• 2010年03月7日 -- 每周推特 2010-03-07 (0)
• 2009年10月13日 -- 装RAC中libpthread.so.0的问题 (0)