半卷

每次遇到opera的字体问题都很忧伤。尤其是打开 http://www.douban.com/ 时，满屏的飘忽的文字，更是觉得蛋疼。

不过！经过今天一个中午的摸索研究测试， 终于能够一行代码搞定问题了！！！跟我来吧！

第一步：下载  user.css 文件。

里面就是一行CSS设置，也可以自己人肉写：

* { font-family: “Microsoft YaHei” !important; }

这行设置的意思是，所有的网页文字统统设置成为微软雅黑！ 这个是在我自己的显示器上人肉观察得出的喜好，如果你不喜欢，可以打开 字体显示效果测试页面 来挑选顺眼的字体。

第二步，设置opera使用该CSS配置。

打开菜单->[设置]->[首选项]->[高级]->[内容]->[样式选项]，在“我的样式选项”里选择刚才下载的user.css文件，保存！重启浏览器，即可看到效果！

这个做法的原理，是利用user css与author css之间的样式权重特点，通吃页面上所有文字的字体，强制设置成为自定义的字体（例如上面的雅黑），从而统一显示效果。欲了解更多的同学，请看W3.org上对!important规则的解释。

昨天VPS突然挂掉了。我晚上玩推特时才发现（choqok更新不到数据了）。不过浏览器Opera里的twitter.com代理还能用，于是我就没管，以为是网络连接问题。

不过睡前看告警邮件，发现全系列的网络访问都不能进行，PING也失败，开始怀疑VPS死机了。。。

今早起来，在Control Panel上看VPS上的状态，提示的还是绿色的“Online”（你妹的，后来发现只要电源开着就算是Online！），但显然SSH已经无法连接上去了。

场景介绍完毕，顺便讲述背景

我的VPS是这款 Hostigation 上的KVM 128m，前几天买着玩，发现网络很好（什么pr路线啥的我也不懂），访问速度比之前的directspace快一些些（对于我这种被教育网毒害若干年的，内心一直怀着对网速的渴望）。这个KVM机器后台有个VNC登录界面，是Java Applet，于是捣鼓了一下（顺便吐槽一下openjdk-plugin，弱爆了），成功登录机器——结果看到界面后我惊呆了：

内存用完了啊亲！久违的Kernel Panic啊亲！！我第一次知道内存爆掉会连着内核也爆啊！！吐槽不能……只能默默的点击页面上的Reboot按钮……

深入内核被爆的秘密

其实内存不足的原因我也能大概猜到，机器上跑的是nginx + php5-fpm + wordpress。fpm这货根本就是内存大户，VPS上又只有128M内存+256M Swap，Wordpress博客又慢又胖，VPS上的CPU又不给力，监控宝还在其他地方默默地发起请求访问博客首页……所以访问不能承受之重，VPS内存溢出了。

为了验证，我祭出压力测试工具ab2（就是apache带的工具），首先小试一招：

悲催地看到，请求处理时间为1879ms。。。接近两秒啊！而从后台top命令可以看到 [php-fpm: pool www]这个进程突然冒出来，然后吃住20M内存不动了。。。

再来一次强大的招式，每秒并发10个请求，一共请求100次，看看啥情况：

偶也，跑了一分钟后突然来了一句超时，压力测试工具自动停了。这时候VPS上的悲惨状况我就不截图了（当时也没截图），内存已经彻底不够用，256M SWAP都快分配完毕了，幸好在悲剧重演之前，ab2工具自己停掉了，呼！看着岌岌可危的VPS，看着进程列表中满眼的 php-fpm，我只好默默地把他们都重启掉。。。

娇小的VPS果然不能承受野蛮的访问

研究出是php5-fpm的问题后，那就容易办了。按每个fpm进程20M内存占用来算，VPS上最多只应该启动5个进程；另外考虑到咱的博客基本没访问量，所以空闲fpm进程就设置为少一些吧。另外，也限制一下请求处理的时间，避免排队排到死：

这一次，再跑ab2压力测试工具，总算能够活下来了：

不过，悲惨地看到请求时延平均增长到了6秒。。。可见排队之长。。。

请求量之禅

这一次的事件告一段落了。不过有关这个请求量、处理时间的数值却引起我的思考。

目前这个弱小的kvm虚拟机，良好情况下，一个请求要消耗 2s，进程数限制是最多 5 个进程，这样所能承受的每秒最大请求是 2.5 r/s 。真是一个微小的数字。。。

在我的实际工作中，公司里的WEB机器跑的还是古老的C++写的CGI，一般单个CGI进程承受的访问量是 10r/s ~ 20r/s，机器配置是酷睿CPU+8G内存，一般CGI开50个进程（还同时跑着其他CGI），单机CGI承受量为500r/s（目前最高的我见过有1600r/s)。这时机器负载还算是正常服务，性能消耗还留有余地，一般CPU占用为30%，负载小于1，能再承受50%的高峰访问。

或许会问，有必要追求这个高的访问承受力吗？？实际上，我们公司的CGI部署起来，很少只用1台机器就够的。多数情况下，需要用4台以上（刚才提到的那个1600r/s的CGI），有些极高访问量的CGI会有每秒1万次请求，如果单机以 500r/s算，那么需要20台服务器组成集群来处理。而这些机器还只是专门跑WEB服务器的，DB还是另外独立部署，所以后面还有一大堆的DB机器……这些都是赤裸裸的钱啊……

所以，VPS什么的，真的是只能玩玩，搭个没访问量的个人博客。弱爆了唉。。。

工作繁忙。家里电脑也坏掉了。于是就随便贴篇小广告来冒个泡。之前看到同事有关SVN的小技巧分享，因此想扯谈一下版本管理系统的知识。

目前主要的三个版本管理系统分别是 svn, git, hg ，为啥是他们呢？因为googlecode.com上支持的就是这三个，可见其流行程度。

SVN是很早以前就出现的版本管理系统，适合于集中式的版本管理，就是咱们公司这种集中的版本server，改代码的人基本坐在一起。它一直流行至今，估计大家都很熟悉了，不多说了。

GIT是Linus同学为了解决Linux分布式开发的问题而弄的系统，它的特点就是拉取/合并分支非常简单，它与svn的不同之处是，它不全量保存每个文件，而是类似保存diff的方式存储每次版本的差异。这样存储方面会小很多，而且所以svn里需要拷贝目录的操作都变成了折腾diff，拉分支、打基线都不需要文件拷贝，很强大。

HG其实和GIT差不多，它出现的原因是因为GIT死活不肯弄windows版，所以HG就用python来开发，号称能跨平台。基本的操作方式抄袭GIT（其实版本管理就那么几种命令），因为我较少使用HG，就不详说了。

我个人比较喜欢GIT，这里有个好玩的网站( http://zh-cn.whygitisbetterthanx.com/ ) 对比说明了Why Git is Better Than X （为啥GIT比其他的XXX都强）。

PS：有个有意思的八卦，最初05年CVS大行其道时，KDE作为第一个大型软件工程切换使用SVN，证明了SVN的靠谱，于是广大人民纷纷跟进；去年，KDE迁移到了GIT，足以证明GIT的前途一片光明啊。。。