分类目录归档:Linux&Unix

TOKYOTYRANT 队列服务器【转】

Tokyo Tyrant最常用的功能就是提供key->value的数据存储服务,再加上Tokyo Tyrant的lua语言扩展就可以实现很多适合自己需求的功能,例如:定时清理缓存数据(ttserver本身并不去管数据的过期时间,当然它采用的是磁盘存储,可以有很大的空间用来存放数据,不必去管数据的过期);session服务器;队列服务器;记数器等等!

下面就来说一说,如何用Tokyo Tyrant构建一个队列服务器:

1. 安装

复制代码
#安装 Tokyo Cabinet

wget http://1978th.net/tokyocabinet/tokyocabinet-1.4.45.tar.gz
tar zxvf tokyocabinet-1.4.45.tar.gz
cd tokyocabinet-1.4.45
./configure –enable-off64
#32位系统需要 –enable-off64,以让它支持大于2GB的文件
make
make install

cd ../

#ttserver运行时,支持一些扩展脚本,这里采用lua脚本,所以需要lua的支持,安装 lua
wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
tar zxvf lua-5.1.4.tar.gz
cd lua-5.1.4.tar.gz
#要根据系统而定,直接make它会有提示
make linux
make install
ln -s /usr/local/bin/lua /usr/bin/lua

cd ../
#安装Tokyo Cabinet 的 lua 扩展
wget http://1978th.net/tokyocabinet/luapkg/tokyocabinet-lua-1.9.tar.gz
tar zxvf tokyocabinet-lua-1.9.tar.gz
cd tkoyocabinet-lua-1.9.tar.gz
./configure
make
make install

cd ../

//安装 Tokyo Tyrant
wget http://1978th.net/tokyotyrant/tokyotyrant-1.1.40.tar.gz
tar zxvf tokyotyrant-1.1.40.tar.gz
./configure –enable-lua –with-lua
make
make install

cd ../

复制代码

 

2. 配置

在 tokyo tyrant 的源码目录下有一个 ext 文件夹,里面存放的就是一些 lua 扩展脚本,queue.lua 就是用来提供队列服务的,这里我将 queue.lua 复制到 /etc/ttserver 里面去,打开该脚本,里面提供三个函数,主要是:

enqueue(key, value),进队列,key为队列名称,value为队列值。

dequeue(key, max),出队列,key为队列名称,max为每次从队列中取出多少条记录。

queuesize(key),队列的长度,key为队列名称。

3. 启动

#ttserver -host 127.0.0.1 -port 11221 -thnum 8 -dmn -pid /data/ttserver/my_queue/ttserver.pid -log
/data/ttserver/my_queue/ttserver.log -le -ulog /data/ttserver/my_queue/ -ulim 32m -sid 1 -rts
/data/ttserver/my_queue/ttserver.rts -ext /etc/ttserver/queue.lua
/data/ttserver/my_queue/database.tch

 

 

TokyoTyrant 队列服务器

启动参数说明可以参考这里:http://blog.s135.com/post/362/

4. 测试

向队列服务器里插入一条记录,my_queue为队列名,hello是记录值。如果插入成功就会返回:ok

#tcrmgr ext 127.0.0.1:11221 enqueue my_queue hello

 

从队列服务器里取出一条记录,my_queue为队列名,1为只取一条记录。返回队列头部的第一条记录值。

#tcrmgr ext 127.0.0.1:11221 dequeue my_queue 1

 

TokyoTyrant 队列服务器

5. 客户端访问

一般在web中有很多需要用到队列的地方,刚好,演示一下如何用tokyo tyrant为PHP提供队列服务。

我这里用到的是PHP版本的 tokyo tyrant 客户端,如果想用so版本的,就需要去http://pecl.php.net/package/tokyo_tyrant 下载后编译安装,这里我以 php 版的客户端测试。

循环向队列写入100条记录,并一次取出10条记录,代码如下:

复制代码
<?php
include(‘Tyrant/Tyrant.php’);

$tt = Tyrant::connect(’127.0.0.1′, ’11221′);

for($i=1; $i<=100; $i++)
{
$tt->ext(‘enqueue’, ’my_queue’, $i, 0);
}

var_dump($tt->ext(‘dequeue’, ’my_queue’, 10, 0));

//上面ext方法的最后一个参数0,为是否开启锁机制,还有下面两个值可选:
//一个相当于行锁,一个相当于表锁,一般第一个就够用了
//Tyrant::XOLCKREC for record locking
//Tyrant::XOLCKGLB for global locking
?>

复制代码

 

运行结果:

TokyoTyrant 队列服务器

返回的值是一个字符串,每条记录之间用”\n”分隔,最后也有一个”\n”。

接着再通过 tcrmgr 去队列中取出10条记录:

TokyoTyrant 队列服务器

队列服务器搭建完毕,以ttserver一直以来的表现,效率方面应该不是问题,这里我也没有进行大量的这方面的测试。

MongoDB vs Redis vs Tokyo Tyrant[转]

准备对MongoDB, Redis以及Tokyo Tyrant的读写做一个简单的测试,为了进行相对公平的测试,需要了解他们背后的实现机制,下面是一些比较:

存储实现的比较:
* 内存文件映像(Memory-File Mapping) Redis, MongoDB
* 文件 + Cache Tokyo Tyrant
* 内存: Redis, Tokyo Tyrant
Key/Value索引形式:
* B+ Tree : MongoDB, Tokyo Tyrant
* Hash Table: Redis, Tokyo Tyrant
* Fixed Length: Tokyo Tyrant

从上面的比较可以看出,Redis和MongoDB是基于系统内存映像文件,数据能命中在内存的时候读写操作性能应该是非常强的,当然,反过来,如果数据十分分散不能在内存命中,那么内存页的切换开销将是非常可怕的,MongoDB和Redis数据文件不同的是将数据存放在多个文件中,每当上一个存满的时候就会创建新的数据空间文件。鉴于MongoDB 是主要比较对象,而其采用B+Tree进行存储,故TT也使用B+Tree引擎进行比较。

那么该测试什么自然就可以得知:尽管使用内存映像文件读写操作会很快(快到什么程度),但是当写满内存以后呢?

文件大小限制:
32bit: MongoDB <= 2G
TT no limits if u ./configure –enable-off
64bit: MongoDB和TT均无限制。

注:Redis 总是受限于内存的大小。

为了进行相对公平的测试:
首先通过虚拟机对内存的使用进行同等限制,因为MongoDB和Redi实际上读写都是在内存操作的(利用MemoryMap文件),故当数据库的大小超过内存大小时候的性能尤为重要。故用虚拟机来设置一个较小的内存大小,来快速观察数据库大小超过内存的时候的性能。
这里设置虚拟机内存256M,实际可使用内存200M左右,CPU 2核,Unbuntu Server 9.10

测试记录:
Key: 512的随机字符串
Value: 大约5k的随机字符串
每项记录数据大小:大约5.5k
计划插入数据100000条:5.5k*1000=5.5M*100=550M 数据量大约 550M。

注:key开始是用1k的随机字符串来测试,但是在测试mongoDB 报告key too large to index, 因此减小key的大小到512字节。

当没有任何数据的时候:
MongoDB的大小:
64M: (db.0, db.1, ..)data FIle
16M: (database.ns) name space index file.

TC的大小:
133K btree.tcb
256 fixed.tcf
517K hash.tch

Redis的大小:
VirtualMemFile: 41M redis-3546.vm
DB: 0M
注:redis的文件初始大小基本等于你设置的内存以及内存页的大小,可以自己调整。redis通过定时存盘的策略进行保存,定时策略可以自行设置。
通常情况下,redis的数据库必须<=内存,如果要让redis的数据库大于内存,那么必须在配置中打开vm_enabled选项(貌似没用,当插入数据超过内存后,会被Unbuntu的后台保护进程给杀掉,如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值)。

key/value 功能:
Redis: 读写key/value,value可以有各种结构,但Value无索引。
MongoDB: 以collection组织,key如果不特别指定将由系统作为ObjectId产生(指定使用“_id”字段),value是结构化的,value里的字段可以被索引。
TokyoTyrant: 读写key/value,table 数据引擎支持结构化的value和字段索引,其它数据引擎不支持,b+tree可以用key索引。

基准测试机器:
虚拟机是跑在 2 CPU 2.26G Intel Core 2 Duo,内存为2G
虚拟机:
CPU 2核
内存 256M
操作系统:Unbuntu Server 9.10 32bit

使用软件版本:
* MongoDB: mongodb-linux-i686-2010-02-26
* TokyoTyrant: TT1.1.40; TC1.4.42
* Redis: 2010-03-01(GIT SRC)

启动:
redis-server ./redis.conf(设置了最大内存210兆:maxmemory 210000000, vm-enable=yes,vm-max-memory 20000000,vm-pages 1342177)
./ttserver -port 1974 /data/db/tt.tcb
bin/mongod -port 1974 –dbpath /data/db/mongo

MongoDB
如上所述测试添加10万条数据:
内存,刚开始的时候虚拟内存占用48564,物理内存占用 3432,在插入2000条数据后,虚拟内存到达143M,物理内存33M,内存增长很迅速。最后虚拟内存稳定在1048M,物理内存则在160M-211M徘徊。
CPU占用率最低的时候为6%,最高的时候达到30%,平时在8%-10%之间。
从测试看,每次分配DB空间的时候所有插入操作被冻结,最坏的一次插入2000条耗时1分多(这个时候正好有分配空间文件发生),平时,插入2000条数据大约耗时17-18秒。
最后MongoDB的数据文件总大小达到:977M

接着测试MongoDB读取10万条记录(非命中形式:该key是随机产生的,因此大都不会存在数据库中)

内存:虚拟内存稳定在1048M,物理内存占用在90M-94M。
CPU:最低占用8%,最高到45%;平时在10%-12%左右。
读取2000条记录大约耗时3-4秒,第一次用了6秒。

Redis
同样测试添加10万条数据:
内存,开始的时候忘记看了,大致较开始的虚拟内存占用112M,物理内存82M,在4万条记录的时候VM占用196M,物理内存占用163M,最后的时候VM占用237M,物理内存204M。
CPU:最低占用3%,最高的时候15%,平时在7%-11%之间。
当Redis向磁盘写入数据的时候,有变慢(2000条记录耗时21秒),平时存2000条记录大约耗时18-19秒左右。
不过没有设定maxmemory的时候,在大约写入 6万多个数据后服务器被挂掉。当设置最大使用内存(200M)后,达到内存限制,写入不了(已写入48136个数据),但是不会挂了。
Redis文件在写入48136个数据时候的大小(包括VM文件):277M,其中VM 41M,数据库236M。

接着测试Redis读取10万条记录(非命中形式:该key大都不会存在数据库中)
内存:虚拟内存237M,物理内存占用204M
CPU:在26%-43%

读取2000条记录大约耗时在3-4秒。

Tokyo Tyrant
如上所述测试添加10万条数据:采用默认配置参数运行TT B+Tree
内存:初始的时候VM: 76928 物理内存: 1232,在插入的过程内存的增加很少,在插入到4万条记录的时候虚拟内存仅为99540,物理内存23M,到最后虚拟内存117M,物理内存37M。
CPU占用率始终稳定在2%

在插入到5万条记录前,平均插入2000条耗时约19-20秒,到8万条记录前时候,插入2000条耗时20-22秒,再接下来的2万条,平均插入2000条耗时在慢慢增加并有震荡,28秒,最后到42秒(B+Tree的索引节点在内存中满了?可能需要调整参数?)。
TT的数据库只有一个文件大小为:589M

接着测试TT读取10万条记录(非命中形式:该key大都不会存在数据库中)
内存稳定在:VM110M;物理内存36M。
CPU:最低2%,最高6%,平时在4%

读取2000条记录大约耗时在7-8秒,偶尔6秒或9秒。

小结:
MongoDB和Redis写入数据不是直接写入磁盘,所以当重启系统时候没有存盘的数据将全部丢失。TT实际上也有内存缓冲,不过和前者相比要小的多。
以上测试并不完善,只是一个开始,比如没有测试小数据(以数字作为key,100字节Value),没有测试较大的数据(20K左右);没有测试在命中情况下的性能;没有测试并发读写的性能,据闻MongoDB的并发读写效率不是特别出色,MongoDB的特色在于支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,并实现了存储节点的自动sharding管理等配套功能;以及由于MongoDB是分布在多个文件中,当数据量远大内存,分布在足够多的文件的时候的性能;对开启同步日志后的Replication测试….对于TT来说,需要对TT的其它数据引擎进行测试,以及TT的各种数据引擎如何优化?TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据库。TC的主要缺点是在数据量达到上亿级别以后,并发写数据性能会大幅度下降(读不受影响),NoSQL: If Only It Was That Easy提到,他们发现在TC里面插入1.6亿条2-20KB数据的时候,写入性能开始急剧下降。Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作,例如从List两端push和pop数据,取 List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据,Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。

测试程序和详细记录见附件: testbench.tgz.zip

Refs:
* http://porteightyeight.com/2009/11/09/redis-benchmarking-on-amazon-ec2-flexiscale-and-slicehost/
* http://www.eb163.com/club/viewthread.php?tid=2470
* http://timyang.net/data/mcdb-tt-redis/
* http://www.javaeye.com/topic/524977
* http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/

摘自:http://www.cnblogs.com/riceball/archive/2010/03/05/MongoDB_Vs_Redis_Vs_TokyoTyrant.html

Linux查看当前目录下文件的个数[转]

查看当前目录下文件的个数
ls -l | grep “^-” | wc -l
查看当前目录下文件的个数,包括子目录里的。
ls -lR| grep “^-” | wc -l
查看某目录下文件夹(目录)的个数,包括子目录里的。
ls -lR| grep “^d” | wc -l
简要说明:
ls -l
长列表输出该目录下文件信息(注意这里的文件,不同于一般的文件,可能是目录、链接、设备文件等)
grep “^-”
这里将长列表输出信息过滤一部分,只保留一般文件,如果只保留目录就是 ^d
wc -l
统计输出信息的行数,因为已经过滤得只剩一般文件了,所以统计结果就是一般文件信息的行数,又由于一行信息对应一个文件,所以也就是文件的个数

转自:http://yzswyl.cn/blread-1547.html

nginx压力测试[转]

  在运维工作中,压力测试是一项非常重要的工作。比如在一个网站上线之前,能承受多大访问量、在大访问量情况下性能怎样,这些数据指标好坏将会直接影响用户体验。

  但是,在压力测试中存在一个共性,那就是压力测试的结果与实际负载结果不会完全相同,就算压力测试工作做的再好,也不能保证100%和线上性能指标相同。面对这些问题,我们只能尽量去想方设法去模拟。所以,压力测试非常有必要,有了这些数据,我们就能对自己做维护的平台做到心中有数。

  目前较为常见的网站压力测试工具有webbench、ab(apache bench)、tcpcopy、loadrunner

  软件名称简介优缺点

  webbench由Lionbridge公司开发,主要测试每秒钟请求数和每秒钟数据传输量,同时支持静态、动态、SSL

  部署简单,静动态均可测试。适用于小型网站压力测试(单例最多可模拟3万并发)

  ab(apache bench)Apache自带的压力测试工具,主要功能用于测试网站每秒钟处理请求个数

  多见用于静态压力测试,功能较弱,非专业压力测试工具

  tcpcopy基于底层应用请求复制,可转发各种在线请求到测试服务器,具有分布式压力测试功能,所测试数据与实际生产数据较为接近后起之秀,主要用于中大型压力测试,所有基于 tcp的packets均可测试

  loadrunner压力测试界的泰斗,可以创建虚拟用户,可以模拟用户真实访问流程从而录制成脚本,其测试结果也最为逼真模拟最为逼真,并可进行独立的单元测试,但是部署配置较为复杂,需要专业人员才可以。

  下面,笔者就以webbench为例,来讲解一下网站在上线之前压力测试是如何做的。

  安装webbench

  #wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz

  #tar zxvf webbench-1.5.tar.gz

  #cd webbench-1.5

  #make && make install

  进行压力测试

  并发200时

  # webbench -c 200 -t 60 http://blog.luwenju.com/index.php

  参数解释:-c为并发数,-t为时间(秒)

  Webbench – Simple Web Benchmark 1.5

  Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

  Benchmarking: GET http://blog.luwenju.com/index.php

  200 clients, running 60 sec.

  Speed=1454 pages/min, 2153340 bytes/sec.

  Requests: 1454 susceed, 0 failed.

  当并发200时,网站访问速度正常

  并发800时

  #webbench -c 800 -t 60 http://blog.luwenju.com/index.php

  Webbench – Simple Web Benchmark 1.5

  Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

  Benchmarking: GET http://blog.luwenju.com/index.php

  800 clients, running 60 sec.

  Speed=1194 pages/min, 2057881 bytes/sec.

  Requests: 1185 susceed, 9 failed.

  当并发连接为800时,网站访问速度稍慢

  并发1600时

  #webbench -c 1600 -t 60 http://blog.luwenju.com/index.php

  Webbench – Simple Web Benchmark 1.5

  Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

  Benchmarking: GET http://blog.luwenju.com/index.php

  1600 clients, running 60 sec.

  Speed=1256 pages/min, 1983506 bytes/sec.

  Requests: 1183 susceed, 73 failed.

  当并发连接为1600时,网站访问速度便非常慢了

  并发2000时

  #webbench -c 2000 -t 60 http://blog.luwenju.com/index.php

  Webbench – Simple Web Benchmark 1.5

  Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

  Benchmarking: GET http://blog.luwenju.com/index.php

  2000 clients, running 60 sec.

  Speed=2154 pages/min, 1968292 bytes/sec.

  Requests: 2076 susceed, 78 failed.

  当并发2000时,网站便出现“502 Bad Gateway”,由此可见web服务器已无法再处理用户访问请求

  总结:

  1、压力测试工作应该放到产品上线之前,而不是上线以后

  2、测试时尽量跨公网进行,而不是内网

  3、测试时并发应当由小逐渐加大,比如并发100时观察一下网站负载是多少、打开是否流程,并发200时又是多少、网站打开缓慢时并发是多少、网站打不开时并发又是多少

  4、 应尽量进行单元测试,如B2C网站可以着重测试购物车、推广页面等,因为这些页面占整个网站访问量比重较大

lvs+keepalived生产环境中使用[转]

这是生产环境中一个项目,该公司的网站经常受到同行的ddos攻击,故需要搭建一个环境让攻击者攻击时候转到公司的假网站上。我的任务就是搭建抗攻击的假网站。
我的设计这样的lvs(+keepalived组成高可用)+LNMP+组成公司的假网站。总过8台机器6台web服务器2台lvs
为了保密,ip和真正地web都不。。。web只用两台代替。
1,配置准备
centos下的yum环境,keepalived-1.1.17.tar.gz,ipvsadm-1.24.tar.gz(这两个包可用在网上下载,也可以在下面的链接上下http://www.kuaipan.cn/file/id_4516853896446486.html
2,安装配置
配置时候要确保下面的连接正常ln -sv /usr/src/kernels/2.6.32-220.el6.i686/ linux,因为keepalived-1.1.17.tar.gz,ipvsadm-1.24.tar.gz这两个包的编译都依赖开发的内核。如果出现以下情况:

[root@localhost src]# ll
total 8
drwxr-xr-x 7 root root 4096 Mar 1 03:01 redhat
[root@localhost src]#
因为在装系统的时候没有装kernels的开发包这时候需要自己装
yum install kernel*
安装ipvsadm-1.24.tar.gz
tar xf ipvsadm-1.24.tar.gz
cd ipvsadm-1.24
make && make install
安装keepalived-1.1.17.tar.gz
tar xf keepalived-1.1.17.tar.gz
cd keepalived-1.1.17
./configure
确保./configure的结果是下面样子
Keepalived configuration
————————
Keepalived version : 1.1.17
Compiler : gcc
Compiler flags : -g -O2
Extra Lib : -lpopt -lssl -lcrypto
Use IPVS Framework : Yes
IPVS sync daemon support : Yes
Use VRRP Framework : Yes
Use LinkWatch : No
Use Debug flags : No
make && make install
cp /usr/local/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/
cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/
mkdir /etc/keepalived
cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/
cp /usr/local/sbin/keepalived /usr/sbin/
3,配置keepalived的主备配置文件
vim /etc/keepalived/keepalived.conf
#######MASTER#####################
! Configuration File for keepalived
global_defs {
notification_email {
470499989@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.200
}
}
virtual_server 192.168.1.200 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP

real_server 192.168.1.117 80 {
weight 3
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.118 80 {
weight 3
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
#################BACKUP#########################
! Configuration File for keepalived
global_defs {
notification_email {
470499989@qq.com
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 127.0.0.1
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 80
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.200
}
}
virtual_server 192.168.1.200 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP

real_server 192.168.1.117 80 {
weight 3
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.1.118 80 {
weight 3
TCP_CHECK {
connect_timeout 10
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
如果在执行service keepalived start,启动不起来需要看日志
# tail /var/log/messages
Mar 30 12:05:15 localhost Keepalived_vrrp: bogus VRRP packet received on eth0 !!!
Mar 30 12:05:15 localhost Keepalived_vrrp: VRRP_Instance(VI_1) Dropping received VRRP packet…
Mar 30 12:05:16 localhost Keepalived_vrrp: ip address associated with VRID not present in received packet : -939415360
Mar 30 12:05:16 localhost Keepalived_vrrp: one or more VIP associated with VRID mismatch actual MASTER advert
#######如果是以上日志就是因为你所在的环境还有其他人在做keepalived,需要修改虚拟路由标识,因为默认是51.
#######如果还启动不了,那么你要是用的虚拟机做的实验的话,看看你虚拟机的时间date,这一点对虚拟机很重要的哟。
附加keepalived配置文件的解读
#####配置文件解读#####
! Configuration File for keepalived
global_defs {
notification_email { ###定义接收信息的邮件地址
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.200.1 ####定义用于监控的smtp地址
smtp_connect_timeout 30
router_id LVS_DEVEL ###定义lvs负载均衡标示
}
vrrp_instance VI_1 { ###定义一个vrrp组
state MASTER ###本机在该组中的所属的角色,只有MASTER和BACKUP两种状态,并且需要大写这些单词。
interface eth0 ###对外提供服务的网络接口
virtual_router_id 51 ###虚拟路由标识
priority 100 ###本机的在vrrp组的优先级
advert_int 1 ###主备同步检查时间间隔
authentication { ###主备之间通信验证设置
auth_type PASS
auth_pass 1111
}
virtual_ipaddress { ###虚拟ip地址,也就是vip地址。
192.168.200.16
}
}
virtual_server 192.168.200.100 443 { ###虚拟服务器定义,注意是ip+端口号
delay_loop 6 ###健康检查时间间隔,单位是秒。
lb_algo rr ###负载均衡调度算法,互联网应用常使用wlc。
lb_kind NAT ###负载均衡转发规则,一般包括DR、NAT、TUN3种。常用DR模型。
nat_mask 255.255.255.0 ###DR模式这项没有
persistence_timeout 50 ###会话保持时间,单位是秒。
protocol TCP ###转发协议
real_server 192.168.201.100 443 { ###定义realserver,real_server的值包括ip地址和端口号
weight 1 ###该realserver的权重
SSL_GET {
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

本文出自 “gabylinux” 博客,请务必保留此出处http://gabylinux.blog.51cto.com/1593644/822168

php5.3.5 编译bin下没有php-cgi[转]

转自:http://hi.baidu.com/hackers365/blog/item/7b3ff37eba99b32c0cd7da3f.html

今天编译了一个最新的php5.3.5,编译参数如下:

./configure –prefix=/usr/local/php5.3.25 –enable-fpm –with-openssl –with-pcre-regex –with-zlib –with-bz2 –with-curl –with-gd –with-gettext –enable-mbstring –with-mcrypt –with-mysql –with-pdo-mysql –enable-zip –with-pear

make

make install

开了php-fpm,运行php-fpm也正常。。nginx在前端访问phpinfo也可以。。但是ps aux|grep php-cgi的时候没有发现php-cgi进程。只有php-fpm进程,纳闷了。。。google后得到结论

以前的版本中需要–enable-fastcgi来开启fastcgi支持,会生成php-cgi文件,而到5.3以后则在内核中支持fastcgi。

nginx 502 解决方法参考

经常碰到Nginx 502 Bad Gateway 这个问题,提示

Jan 11 08:54:01.164292 [NOTICE] fpm_children_make(), line 352: child 10088 (pool default) started
Jan 11 08:54:01.164325 [WARNING] fpm_children_bury(), line 215: child 7985 (pool default) exited on signal 15 SIGTERM after 63.778601 seconds from start
查过网上的资源,基本都是认为是php线程打开文件句柄受限导致的错误。具体的解决的办法如下:
1、提升服务器的文件句柄打开打开
/etc/security/limits.conf : (增加)
*    soft    nofile    51200
*    hard    nofile    51200
# vi /etc/security/limits.conf 加上
* soft nofile 51200
* hard nofile 51200
2、提升nginx的进程文件打开数
nginx.conf : worker_rlimit_nofile 51200;
3、修改php-fpm.conf文件,主要需要修改2处
命令 ulimit -n 查看限制的打开文件数,php-fpm.conf 中的选项rlimit_files 确保和此数值一致。
 <value name=”max_requests”>10240</value>
<value name=”rlimit_files”>51200</value>
4、
# vi /etc/sysctl.conf
底部添加
fs.file-max=51200

完成以上修改,重启PHP,警告信息再也没了。
世界从此安宁,502 Bad Gateway 没有了。

dell r410安装网卡BCM5716驱动

今天新到的r410,刚跑几天就陆续出现eth1没响应,eth0到没事….这个郁闷。
装网卡驱动试试。
lspci -vv 查网卡驱动
NetXtreme II BCM5716 Gigabit Ethernet
http://zh-cn.broadcom.com/support/ethernet_nic/netxtremeii.php 下载驱动
解压后有rpm和tar两种形式。
yum -y install kernel-devel.x86_64 kernel-debug-devel.x86_64
解压tar包后make
make KVER=2.6.18-164.el5 #当前的内核版本
make install

linux 系统下查看网卡型号及驱动

1、查看网卡型号
kudzu –probe –class=network
结果如下:
class: NETWORK
bus: PCI
detached: 0
device: eth3
driver: bnx2
desc: “Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet”
network.hwaddr: d8:d3:85:b3:cd:0c
vendorId: 14e4
deviceId: 1639
subVendorId: 103c
subDeviceId: 7055
pciType: 1
pcidom: 0
pcibus: 4
pcidev: 0
pcifn: 1
2、查看驱动版本
modinfo bnx2
结果如下:
filename: /lib/modules/2.6.18-194.el5PAE/kernel/drivers/net/bnx2.ko
version: 2.0.2
license: GPL
description: Broadcom NetXtreme II BCM5706/5708/5709/5716 Driver
author: Michael Chan
srcversion: 7025AAF3645EE432EAF1C00
alias: pci:v000014E4d0000163Csv*sd*bc*sc*i*
alias: pci:v000014E4d0000163Bsv*sd*bc*sc*i*
alias: pci:v000014E4d0000163Asv*sd*bc*sc*i*
alias: pci:v000014E4d00001639sv*sd*bc*sc*i*
alias: pci:v000014E4d000016ACsv*sd*bc*sc*i*
alias: pci:v000014E4d000016AAsv*sd*bc*sc*i*
alias: pci:v000014E4d000016AAsv0000103Csd00003102bc*sc*i*
alias: pci:v000014E4d0000164Csv*sd*bc*sc*i*
alias: pci:v000014E4d0000164Asv*sd*bc*sc*i*
alias: pci:v000014E4d0000164Asv0000103Csd00003106bc*sc*i*
alias: pci:v000014E4d0000164Asv0000103Csd00003101bc*sc*i*
depends:
vermagic: 2.6.18-194.el5PAE SMP mod_unload 686 REGPARM 4KSTACKS gcc-4.1
parm: disable_msi:Disable Message Signaled Interrupt (MSI) (int)
parm: enable_entropy:Allow bnx2 to populate the /dev/random entropy pool (int)
module_sig: 883f3504bb64ec7285b5c47ed7a1e8e1124ab709d1d789bf78777b43dfcfff9788e6b1c1da763fece09cfbd9bab31828ce6ca80ce374b2929a3abf6cd83

3.或者lspci | grep Ethernet
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)