Apache 内存暴增解决方法
[ 2009/12/14 08:37 | by selboo ]
前阵子总是发现 httpd 进程的使用内存总量居然达到了上百Mb，有时甚至上Gb，真是夸张。Apache 是架在 Squid 的后面，照理说不应该出现这种情况。通过排查，发现是 Apache 中开启了持续长连接导致。
Apache 进程的内存使用是 “递增/渐进” 式的，也就是在当前进程的 httpd 过程中，内存使用是持续增加的，也就是说在该进程退出之前，内存是持续增加的。主要是由于下面三个参数来控制。
KeepAlive On 设定是否要开启持续长连接，由于前面有 Squid，因此在这里把它打开
MaxKeepAliveRequests 50 在一次持续长连接中，最多允许接收几次请求，如果设置太大的话，很可能导致 httpd
进程持续消耗很多内存，因此可以选择一个适当的值，因为重新创建一个新的进程也是要有一定开销的
KeepAliveTimeout 5 设定一个长连接在没有活动后等待多久自动关闭，可以设置小一点，不过跟上面的类似，如果太小的话，也会导致频繁创建新的进程
现在，调整完上面的参数后，会发现 httpd 进程不再象以前那样狂吃内存了。
Apache 进程的内存使用是 “递增/渐进” 式的，也就是在当前进程的 httpd 过程中，内存使用是持续增加的，也就是说在该进程退出之前，内存是持续增加的。主要是由于下面三个参数来控制。
KeepAlive On 设定是否要开启持续长连接，由于前面有 Squid，因此在这里把它打开
MaxKeepAliveRequests 50 在一次持续长连接中，最多允许接收几次请求，如果设置太大的话，很可能导致 httpd
进程持续消耗很多内存，因此可以选择一个适当的值，因为重新创建一个新的进程也是要有一定开销的
KeepAliveTimeout 5 设定一个长连接在没有活动后等待多久自动关闭，可以设置小一点，不过跟上面的类似，如果太小的话，也会导致频繁创建新的进程
现在，调整完上面的参数后，会发现 httpd 进程不再象以前那样狂吃内存了。
nginx作为最前端的web cache系统
[ 2009/12/14 08:25 | by selboo ]
这个结构的优点：
1、可以使用nginx前端进行诸多复杂的配置，这些配置从前在squid是没法做或者做起来比较麻烦的，比如针对目录的防盗链。
2、nginx前端可以直接转发部分不需要缓存的请求。
3、因为nginx效率高于squid，所以某些情况下可以利用nginx的缓存来减轻squid压力。
4、可以实现url hash等分配策略。
5、可以在最前端开启gzip压缩，这样后面的squid缓存的纯粹是无压缩文档，可以避免很多无谓的穿透。
6、因为nginx稳定性比较高，所以lvs不需要经常调整，通过nginx调整就可以。
7、squid的文件打开数按默认的1024就绰绰有余，不过处理的请求可一个都不会少。
8、可以启用nginx的日志功能取代squid，这样做实时点击量统计时可以精确定位到url，不必要再用低效率的grep来过滤。
9、因为nginx的负载能力高于squid，所以在用lvs分流时可以不必分得特别均衡，出现单点故障的几率比较低。
海量小文件系统架构方案
[ 2009/12/14 08:24 | by selboo ]
现在的网站越做越大了，存储的东西越来越多，如何解决这些文件存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。
从我所了解的存储结构来看，分布式存储大致可以分为几种：
1、类googlefs的分布式文件系统
因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。
首先是文档比较少而出现的问题倒不少；然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要；然后还要想办法在传统的文件系统中做好完全的备份，以免造成损失。
另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的，如果数据量不是很大，可以一试。
2、手工使用文件路径分散存储
这个结构通常使用在web静态文件中，就以这种情形作为例子。
如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：
1)采用域名的分散策略
例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现。
2)采用目录的分散策略
假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。
以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步（把要同步的数据记入日志，通过日志记录来传输相应文件）、比较同步（使用rsync等同步软件）或即时同步（有新的修改就立刻传输）；另外要实现单点故障剔除的话，首先找一个策略把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点；然后在环境中使用故障剔除技术（lvs或nginx等），就可以解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。
从我所了解的存储结构来看，分布式存储大致可以分为几种：
1、类googlefs的分布式文件系统
因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。
首先是文档比较少而出现的问题倒不少；然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要；然后还要想办法在传统的文件系统中做好完全的备份，以免造成损失。
另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的，如果数据量不是很大，可以一试。
2、手工使用文件路径分散存储
这个结构通常使用在web静态文件中，就以这种情形作为例子。
如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：
1)采用域名的分散策略
例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现。
2)采用目录的分散策略
假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。
以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步（把要同步的数据记入日志，通过日志记录来传输相应文件）、比较同步（使用rsync等同步软件）或即时同步（有新的修改就立刻传输）；另外要实现单点故障剔除的话，首先找一个策略把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点；然后在环境中使用故障剔除技术（lvs或nginx等），就可以解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。
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年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。
存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上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年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。
nginx限制ip并发数
[ 2009/12/13 13:50 | by selboo ]
nginx限制ip并发数，也是说限制同一个ip同时连接服务器的数量
1.添加limit_zone
这个变量只能在http使用
vi /usr/local/nginx/conf/nginx.conf
limit_zone one $remote_addr 10m;
2.添加limit_conn
这个变量可以在http, server, location使用
我只限制一个站点，所以添加到server里面
vi /usr/local/nginx/conf/host/gaojinbo.com.conf
limit_conn one 10;
3.重启nginx
killall -HUP nginx
1.添加limit_zone
这个变量只能在http使用
vi /usr/local/nginx/conf/nginx.conf
limit_zone one $remote_addr 10m;
2.添加limit_conn
这个变量可以在http, server, location使用
我只限制一个站点，所以添加到server里面
vi /usr/local/nginx/conf/host/gaojinbo.com.conf
limit_conn one 10;
3.重启nginx
killall -HUP nginx
