好久没怎么正式更新 Blog 了，快荒芜了，长满了 Spam 的荒草。
最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。
Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：
Squid Cache 中共有 3500 万张图片；
在 Squid RAM 中有 200 万张图片；
4.7亿的图片，每张图片有4到5种尺寸；
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)
三个主要步骤：
计划
基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。
部署
Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。
度量(图形化展现)
Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。
Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。
–EOF–
web2.0的数据量用什么技术消化一直都是热门问题，
也希望能看到更多这方面的文章介绍
好东西，flickr就是nb
基准测试在很多时候还是很有用的，不管是大架构还是一些小站点里， 流量的突然爆发需在前期能基准测试而做到心里有数,在大站中一些非生产设备的基准测试也是为生产环境做应对措施
Capacity planning 也需要专门的Team来做，在国内很多SA,DBA都兼任这个。
基准测试在很多时候还是很有用的，不管是大架构还是一些小站点里， 流量的突然爆发需在前期能基准测试而做到心里有数,在大站中一些非生产设备的基准测试也是为生产环境做应对措施
第一次看到PB这个容量单位，-_-||
图片很耗空间的，flickr好强！
俺也很久没有更新了：）
不错，学习。
国内有个巴巴变网络相册的
做的还挺好的
http://www.bababian.com
就是在人数上和flickr有些差距
不过现在越来越多的摄影爱好者在加入
而且上传的照片质量越来越高
可以说在国内摄影的专业领域
已经很高了
如果对于交流和学习的话都很不错的地方
而且速度很快，没有专集组或者200张的图片限制