正在加载...
分页: 3/4 第一页 上页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]

nginx图片服务器的架构方案

[ 2009/12/14 08:23 | by selboo ]
图片服务通常数据容量较大,而且访问也频繁,鉴于此,图片服务就会有两种问题,一是存储问题,二是访问量问题。

存储问题就是硬盘容量问题,花钱买硬盘就可以了,看似简单,但着实也是最苦的问题。按目前探索来看,最好的方式是:在任何时刻遇到硬盘空间不够时,买颗硬盘插上,最多改改配置,就能立刻利用;另外,硬盘要能充分利用,不然图片存储量大再加上备份,很恐怖,最好是每颗硬盘都用上100%的空间。
访问量也是个大问题,如果服务不允许防盗链,那么访问量会引起带宽、服务器压力等问题,有钱的话直接扔CDN,没钱或者有更多的钱,就自己做吧。根据垣古不变的真理“越老的图,访问量也相对较少”这一点,分成两大部分,一边处理最新的图片,一边处理老旧的图片。最新的图片访问量大,但存储量较少;老图片访问量低,但存储量大。
大概分析完了,开始制定方案。

一、拟定一个存储目录规则:
在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成:/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后,就可以按年月来拆机器了。

二、分机器,分硬盘
按之前的计划,分成两个组,一组服务器用lvs做负载均衡负责新图片;另一组服务器做旧图片访问和备份。新图机器找几台好点的服务器,SCSI硬盘;旧图机器没太大要求,PC机就行,找够硬盘就可以,现在IDE的1T硬盘也不太贵,最好再搭个raid就省事了,最主要是这些机器要多。
照这个图,搭一搭

点击在新窗口中浏览此图片

说明一下:
1、图片服务通过lvs作为入口,处理能力上还是有保障的。
2、利用nginx直接对外服务,不必用squid。
3、图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器,如果发现主nginx的cpu占用比较大,那么可以考虑使用nginx的proxy_store将图片存到主服务器上,定期清理。
4、图中有一台存储分配服务器,作为图片服务更新图片的统一入口,有新图片或者修改图片的话,由这台服务器负责将图片放到正确的服务器上去。
5、旧图片服务器当前用年份来划分,每年增加两台服务器,亦可是加两块硬盘,注意,不要相信raid,一定要有两台机器,地理上分在两个城市则更好。
6、因为旧数据2006和2007年的数据基本上是没有变化的,所以假如硬盘够大,那么可以把两年的数据合并在一起。
7、如果细心定制,那么旧图片服务器的硬盘100%塞满是可以的,旧数据的容量基本上不会大幅增长,小小预留1-2G空间就可以了。
使用这个架构的话,到了2009年,我会把2008年的数据想办法迁到旧图服务器上,硬盘不够的话,加硬盘就可以了。如果图片量实在太大,主服务器连一年的数据都装不下,那可以用启用月份来划分;如果一个月都装不下了,那也太夸张了,那就启用日期吧;如果一天的数据都装不下,那就◎#¥%……※。
Tags: , ,

优化web服务器tcp半连接

[ 2009/11/29 11:44 | by selboo ]
在繁忙的web服务器上,很常见的问题是大量tcp 半连接的存在占用系统的大量资源。有效的减少半连接对优化服务器响应有着重要的作用。
实践步骤:

1。执行 /bin/netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
2。vi /etc/sysctl.conf 添加如下两行:

1)net.ipv4.tcp_tw_reuse = 1 //允许将TIME-WAIT sockets重新用于新的TCP连接
2)net.ipv4.tcp_tw_recycle = 1 //开启TCP连接中TIME-WAIT sockets的快速回收


3。运行sysctl -p

4。执行 /bin/netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

如果对于TIME_WAIT较高的服务器来说应该很快就会看到效果

Tags: , ,

Nginx+keepalived负载均衡

[ 2009/10/12 11:22 | by selboo ]
From:http://hi.baidu.com/yuhongchun027/blog/item/25eca12c3442e9e68a13998c.html

由于nginx的url hash功能可以很好的提升squid的性能,所以我把squid前端的负载均衡器更换为nginx,但是一台nginx就形成了单点,现在使用keepalived来解决这个问题,keepalived的故障转移时间很短(<1s),而且配置简单,这也是选择keepalived的一个主要原因,建议日PV值小的中小型企业web均可采用如下方案实行,下面直接上安装步骤:

一、环境:
centos5.3、nginx-0.7.51、keepalived-1.1.19
主nginx负载均衡器:192.168.0.154
辅nginx负载均衡器:192.168.9.155
vip:192.168.0.188

二、安装keepalived

#tar zxvf keepalived-1.1.19.tar.gz
#cd keepalived-1.1.19
#./configure --prefix=/usr/local/keepalived
#make
#make install
#cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
#cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
#cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
#mkdir /etc/keepalived
#cd /etc/keepalived/
vim keepalived.conf

! Configuration File for keepalived
global_defs {
   notification_email {
   yuhongchun027@163.com
        }
   notification_email_from keepalived@chtopnet.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    mcast_src_ip 192.168.0.155    <==辅nginx的IP地址
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass chtopnet
    }
    virtual_ipaddress {
        192.168.0.188                      <==vip地址
    }
}

#service keepalived start
我们来看一下日志:
[root@ltos ~]# tail /var/log/messages
Oct 6 03:25:03 ltos avahi-daemon[2306]: Registering new address record for 192.168.0.188 on eth0.
Oct 6 03:25:03 ltos avahi-daemon[2306]: Registering new address record for 192.168.0.154 on eth0.
Oct 6 03:25:03 ltos avahi-daemon[2306]: Registering HINFO record with values 'I686'/'LINUX'.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Withdrawing address record for fe80::20c:29ff:feb9:eeab on eth0.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Withdrawing address record for 192.168.0.154 on eth0.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Host name conflict, retrying with
Oct 6 03:25:23 ltos avahi-daemon[2306]: Registering new address record for fe80::20c:29ff:feb9:eeab on eth0.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Registering new address record for 192.168.0.188 on eth0.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Registering new address record for 192.168.0.154 on eth0.
Oct 6 03:25:23 ltos avahi-daemon[2306]: Registering HINFO record with values 'I686'/'LINUX'.

很显然vrrp已经启动,我们还可以通过命令:#ip a 来检查

[root@ltos html]# ip a
1: lo: mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:ba:9b:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.154/24 brd 192.168.0.255 scope global eth0
    inet 192.168.0.188/32 scope global eth0
    inet6 fe80::20c:29ff:feba:9be7/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0


说明vip已经启动,这样主服务器就配置好了,辅机的配置大致一样,除了配置文件有少部分的变化,下

面贴出辅机的配置文件:

! Configuration File for keepalived
global_defs {
   notification_email {
   yuhongchun027@163.com
        }
   notification_email_from keepalived@chtopnet.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    mcast_src_ip 192.168.0.154              <==主nginx的IP的地址
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass chtopnet
    }
    virtual_ipaddress {
        192.168.0.188
    }
}


检查其配置
[root@ltos html]# ip a
1: lo: mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:ba:9b:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.155/24 brd 192.168.0.255 scope global eth0
    inet 192.168.0.188/32 scope global eth0
    inet6 fe80::20c:29ff:feba:9be7/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

测试其效果方法很简单,分别在主辅机上建立不同的主页,index.html分别为192.168.0.154,192.168.0.155,然后用客户机上elinks http://192.168.0.188,主机down掉后辅机会马上接替提供服务,间隔时间几乎无法感觉出来,这个环境准备再进行下压力测试,用于我杭州网跃朋友的web服务器,如有疑问请联系yuhongchun027@163.com(抚琴煮酒)
Tags:
一.软件介绍(apache lighttpd nginx)

1. lighttpd

Lighttpd是一个具有非常低的内存开销,cpu占用率低,效能好,以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。
Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量。

Fastcgi的优点在于:

· 从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑.
· 从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮,
· 从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1)
· 从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python...)

2. apache

apache是世界排名第一的web服务器, 根据netcraft(www.netsraft.co.uk)所作的调查,世界上百分之五十以上的web服务器在使用apache.

1995年4月, 最早的apache(0.6.2版)由apache group公布发行. apache group 是一个完全通过internet进行运作的非盈利机构, 由它来决定apache web服务器的标准发行版中应该包含哪些内容. 准许任何人修改隐错, 提供新的特征和将它移植到新的平台上, 以及其它的工作. 当新的代码被提交给apache group时, 该团体审核它的具体内容, 进行测试, 如果认为满意, 该代码就会被集成到apache的主要发行版中.

apache 的特性:

1) 几乎可以运行在所有的计算机平台上.
2) 支持最新的http/1.1协议
3) 简单而且强有力的基于文件的配置(httpd.conf).
4) 支持通用网关接口(cgi)
5) 支持虚拟主机.
6) 支持http认证.
7) 集成perl.
8) 集成的代理服务器
9) 可以通过web浏览器监视服务器的状态, 可以自定义日志.
10) 支持服务器端包含命令(ssi).
11) 支持安全socket层(ssl).
12) 具有用户会话过程的跟踪能力.
13) 支持fastcgi
14) 支持java servlets

3. nginx

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx,它的发音为“engine X”, 是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP 代理服务器.Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发.

Nginx以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配 Lighttpd的性能,同时还没有Lighttpd的内存泄漏问题,而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。但是 Nginx并不支持cgi方式运行,原因是可以减少因此带来的一些程序上的漏洞。所以必须使用FastCGI方式来执行PHP程序。

nginx做为HTTP服务器,有以下几项基本特性:

处理静态文件,索引文件以及自动索引;打开文件描述符缓冲.

无缓存的反向代理加速,简单的负载均衡和容错.

FastCGI,简单的负载均衡和容错.

模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。如果由FastCGI或其它代理服务器处理单页中存在的多个SSI,则这项处理可以并行运行,而不需要相互等待。

Nginx专为性能优化而开发,性能是其最重要的考量,实现上非常注重效率。它支持内核Poll模型,能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。

Nginx具有很高的稳定性。其它HTTP服务器,当遇到访问的峰值,或者有人恶意发起慢速连接时,也很可能会导致服务器物理内存耗尽频繁交换,失去响 应,只能重启服务器。例如当前apache一旦上到200个以上进程,web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术,使得它的 CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接,它只占2.5M内存,所以类似DOS这样的攻击对nginx来说基本上 是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。

Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下,对软件版本进行进行升级。

二.3种WEB服务器的比较:

server                 Apache             Nginx          Lighttpd
Proxy代理        非常好         非常好    一般
Rewriter              好             非常好      一般
Fcgi                    不好             好          非常好
热部署           不支持         支持        不支持
系统压力比较     很大            很小         比较小
稳定性           好             非常好      不好
安全性           好             一般        一般
技术支持         非常好         很少        一般
静态文件处理     一般             非常好      好
Vhosts虚拟主机   支持             不支持      支持
反向代理         一般             非常好      一般
Session sticky       支持           不支持      不支持


注:在相对比较大的网站,节约下来的服务器成本无疑是客观的。而有些小型网站往往服务器不多,如果采用 Apache 这类传统 Web 服务器,似乎也还能撑过去。但有其很明显的弊端: Apache 在处理流量爆发的时候(比如爬虫或者是 Digg 效应) 很容易过载,这样的情况下采用 Nginx 最为合适。

建议方案:

Apache 后台服务器(主要处理php及一些功能请求 如:中文url)
Nginx 前端服务器(利用它占用系统资源少得优势来处理静态页面大量请求)
Lighttpd 图片服务器
总体来说,随着nginx功能得完善将使他成为今后web server得主流。

三.性能测试:

将分别测试3种软件在对动态页面和静态页面请求及并发时的响应时间

1.静态页面

Lighttpd
n/-c(ab参数)  cpu%  Mem  RequestsperSecond
100000/100  64  60  462.75
100000/200  67  60  312.07
100000/500  83  60  137.24
100000/1000  94  60  126.6    
出现错误丢包      

Nginx
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  34.6  140  943.66  10.597
100000/200  35.6  110  924.32  10.818
100000/500  34.3  110  912.68  10.956
100000/1000  37  160  832.59  12.106

Apache
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  40.6  170  690.72  14.47
100000/200  41.1  180  685.39  14.59
100000/500  42.3  190  633.64  15.78
100000/1000  43.1  200  547.53  18.26

2.动态页面

LIGHTTPD        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
1000/100  50  200  33.54  29.816
1000/200  52  210  30.43  32.858
1000/500  54  230  25.79  38.76
1000/1000  62  250  24.83  40.28
        
NGINX        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
1000/100  53.8  250  83.12  12.305
1000/200  55.8  250  74.05  13.504
1000/500  56  260  58.99  16.951
1000/1000  58  260  43.41  23.347
        
APACHE        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  60  200  27.37  36.541
100000/200  61  220  23.82  41.981
100000/500  73  150  20.59  48.562
100000/1000  53  200  27.18  36.796

3.PHPINFO函数页        
        
LIGHTTPD        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  45  20  168.06  59.504
100000/200  47  22  140.64  71.103
100000/500  49  24  52.8  189.386
100000/1000  在请求到4840时测试测试程序死掉      
        
NGINX        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  70  120  143.46  69.706
100000/200  72  130  140.57  71.14
100000/500  73  150  135.87  73.601
100000/1000  77  160  132.18  75.657
        
APACHE 出现丢包        
n/-c(ab参数)  cpu%  Mem  RequestsperSecond  Time taken for tests
100000/100  70  180  245.73  40.694
100000/200  72  190  245.79  40.684
100000/500  75  200  241.29  41.443
100000/1000  77  220  236.74  42.239


四.各大网站WEB服务器资源列表

网站名 操作系统 web服务器

1.门户网站类:

搜狐 LINUX apache 1.3.37
新浪 LINUX apache 2.0.54
迅雷 LINUX nginx 0.6.31
163 LINUX apache 2.2.6

2.搜索类

百度 unknown BWS 1.0
Google linux gws
Sougou FreeBSD apache 2.2.4
Hao123 linux apache 2.2.4

4. 电子邮箱类

126 linux apache
Hotmail win2003 microsoft-IIS 6.0
新浪邮箱 F5 Big-IP apache 2.2.8
263 linux apache 2.2.6

5. 博客类

新浪博客 linux nginx 0.5.35
搜狐博客 linux nginx
迅雷博客 linux nginx 0.6.32
天涯博客 F5 Big-IP Microsoft-IIS/5.0

6.视频类

优酷 linux apache
土豆 linux apache
Ku6 linux apache
六间房 linux nginx 0.6.14

Tags: , , ,

exit signal Segmentation fault

[ 2009/09/15 21:12 | by selboo ]
访问apache web服务器时出现 空白页面

连phpinfo都不能显示
<?
phpinfo();
?>


cat /usr/local/apache/logs/error_log

清空apache 日志

echo "">/usr/local/apache/logs/access_log
echo "">/usr/local/apache/logs/error_log

问题解决
Tags: , ,
分页: 3/4 第一页 上页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]