聚沙成塔-小哈的记事薄

总有一些世界观，是傻逼呵呵地矗立在那里的

admin — Sun, 15 Aug 2010 18:48:00 +0800

上一篇标题是be foolish，这一篇就就要写idiot了。《Three Idiots》，或者又叫《三傻大闹宝莱坞》，让无聊的周末晚上，变得丰富多彩起来。

这是一部校园青春片，归类在喜剧片里，于是自然的让屏幕前的我乐不可支，但如果仅仅如此，那么它就是美国校园喜剧的翻版，我也不会在这个技术博里分享观看后感受。作为同样经历经济高速发展的邻居——印度，这部电影所探讨的理想与现实、爱情与金钱、注重结果还是过程，深深的感触到了我。

噪鹃从来不自己筑巢，他只在别人的巢里下蛋，要孵蛋的时候他们会怎样？他们会把其它的蛋从巢里挤出去，竞争结束了，他们的生命从谋杀开始，这就是大自然——要么竞争，要么死……

丛林法则，优胜劣汰，“病毒”的开场白在父母送你去补习班的时候，在你选择大学专业的时候，会听到各种各样类似的版本。在大学里，为了绩点而奋斗，只看为考试而划重点的内容，不是为了知识，而是为了“从这5年后，当你看到你的朋友买车买房时不会诅咒自己。”

一定要让自己活在“高压锅”里么？某种程度上是的，当你的父母把唯一的空调装在你的房间里让你安心学习，把自己年轻时的遗憾作为目标寄托在你的身上时，当你家里有个生病的父亲、没有嫁妆出嫁的姐姐、以及辛苦照顾这个家的母亲时，我们很难有勇气说出：过自己喜欢过的生活、做自己喜欢做的事，哪怕钱赚的再少只要自己觉得幸福就足够了（这应该就是所谓的责任感使命感吧）。所以我们像男主角的两个朋友，要么生活在“虚伪”里，要么生活在“恐惧”中。

于是我们一个个的“成功”了，但是“理想”这种东西，要么戒了，要么又作为自己的遗憾，硬加到自己的孩子身上。

影片中的爱情，则是以一场订婚一场逃婚来演绎，笔墨不多，却同样有内心抉择的痛苦。是嫁给一个生活贴了标签的成功男士，还是去找能让心情像头发一般飘逸起来的男主角？影片中女主当然选择了后者，但面对现实的生活压力，有多少人能无视暂时的闲言碎语，有多少姻缘因为经济的原因而拆散，又有多少夫妻在坚硬的钢筋水泥的城市里扎不下根来。

所以当影片放到Farhan他爸爸说到：把（电脑）退了，换一部专业摄像机，钱还不够就向我要的时候。放到Raju Rastogi说出“断了两条腿，我才真正站了起来，获得这样的生活态度不容易，我不会放弃”的时候，当病毒主任最终也说出“做你想做的”，并把32年都没送出的太空笔插到Rancho的衣领上时，我再也无法控制自己的眼泪不夺眶而出。

不过看完片后思及自身，又让我感到另外一种悲哀——我不知道自己除了工作之外，还有什么值得投入精力的爱好，不知道自己真正想要的生活是什么。乔治奥威尔痛苦的是“英国人的［阶级］烙印是打在舌头上的”，“他的一切疙瘩都来自于这个事实：他认为他应该去爱他的同胞，但是他连同他们随便交谈都做不到。”而我则是“认为应该去过自己喜欢的生活，但是却连什么是自己喜欢的都不知道”。长年的填鸭式的教育，父母的期盼，老娘舅里形形色色的人生故事，让我以为生活就是如此。看来我们都需要一个像Rancho这样的朋友，告诉我们世界上还有种不合时宜的世界观，也能通向成功。

一个没有一出生就背负使命的园丁的儿子很少见，那至少让我们记住这句话“Follow excellence，Success will chase you !"

Copyright © 2008 This feed is for personal, non-commercial use only
聚沙成塔-小哈的记事薄 by hashei 如果喜欢，欢迎订阅feed.hashei.com
Digital Fingerprint: 10f920a9f2bae51c3c73c4f5fb50a949

Stay hungry，Stay foolish

hashei — Sun, 18 Jul 2010 00:07:00 +0800

好久没有更新，离上一篇日志已经2月了，头一个月在专注于复习在职研究生的期末考试，后一月则出差外加偷懒。对留言里提问题的、请求帮忙的朋友说声抱歉了，看来人一旦没有了压力，大脑里的懒惰小人就一定会占到上风。就连写这篇文章，也夹杂着看了《海贼王》第十部剧场版、《lie to me》第15级、常去的博客逛了一圈、开心网转了N个帖子。

到7月22日，我工作就将整三年。刚工作的时候，都是和Windows AD域、DNS、Exchange、WSUS打交道，感觉熟悉了MCSE的内容，就能解决工作中80%的问题，所以常常不思长进。后来转而学习中间件，用了大半年的时间知道了安装、部署、调优和troubleshooting，每天不紧不慢的看看红皮书、逛逛论坛、做做实验，日子也没什么紧迫感。直到在google reader上订阅了许多牛人的博客，才知道日子混的太多了。

比如回忆未来——张宴，和我同龄，经济与贸易专业，却已是金山的系统架构师技术——支持部平台组组长，并出了一本《实战Nginx：取代Apache的高性能Web服务器》，一篇Nginx+ PHP（FastCGI）搭建胜过Apache十倍的Web服务器成为各大linux论坛都转载的文章。

天分高？未必，《我是一只IT小小鸟》里没有一个天才的故事，都是我们可以“复制”的经历。唯一的区别，就是他们做到了。豆瓣上的这篇书评我深表赞同。

这些优秀的人的一些共同特质：

1) <读书> 他们都是在学生时代读了很多优秀的书，不管是囫囵吞枣型，还是精读的，大量的读书才有了后来质的飞跃。
2) <兴趣> 兴趣是最好的老师，这句话深有体会，真是兴趣的驱使，才能发挥一个人最大的潜能。
3) <专注> 有了兴趣这一强大的推动力，在加上专注这颗金刚钻，再难的瓷器活都可以做到至善至美。
4) <思考> 他们不论是思考技术问题，还是在人生的方向的把握的思考，都独具深度。
5) <积累> 他们注重知识很经验的积累，量变导致质变。
6) <交流> 如果说读书是自我学习实现腾飞的一只翅膀，那么与优秀的人的交流是提升自我的另外一只翅膀。
7) <分享> 分享是一种突破，没有有效的积淀，就不容易产生有价值的分享。当在前期从周围的环境、资源中不断获取之后提升了自己，这时候就是你该分享你的经验，回报这个环境的时候了。

于是接下来的日子一直在慢慢督促自己学习这些人。其实我是很幸运的，从事的工作一是适合自己，二也是充满挑战性的，学习的空间很大，而不会是可悲的“虽说有5年工作经验，其实是1年的工作经验然后重复5次”。

自从接触中间件，然后又做系统验收前的压力测试，不得不学习linux/unix下性能监控和调优的技术，于是看了《linux服务器性能调整》。压力测试结果不满意，于是看了《构建高性能Web站点》，通过动静分离，至少从前端的角度，尽可能的提升页面展示速度。公网上部署应用，也就有了安全的需求，selinux的原理与配置、log日志的审查，渗透与反渗透的技术也就不得不掌握。运营之后的报告，也提出了监控服务器、分析应用日志的要求，shell编程、sed和awk也不得不提上学习日程。

做售后工作之余，有时还会接触一些售前上的问题，比如设备的选型，那就牵涉到容量规划，《web容量规划的艺术》使我受益良多，《大话存储－网络存储系统原理精解与最佳实践》是我下一本要看的书，虽然一本书离精通存储产品还很遥远，但至少要从整体上避免整个系统中的短板。

如此种种衍生出去的学习，正好也印证了about me中的那段话“一点服务器技术、一点操作系统知识、一点数据库概念、一点中间件结构、一点编程能力、一点网络基础、一点存储原理，还要一点IT素质和经验积累。”这些是对系统工程师的要求，但没有人来教你这么多“一点”。如果自己不要求自己，将来面试工作的时候被告知lack of sth的时候一定不好受。

上面提到的成功特质中，1、2、3、6如果还算基本的话，4、5、7对我来说是难点，也应该是很多人的难点，因为网络上多的是零零碎碎的、重复的知识，系统的全面的极少。而那些写的深入的人，无一不是那个领域的专家。其实现在成为一个专家也并非难事，只要“一万个小时”就可以了，但事实是我们往往都知道自己的弱点和需要改进的地方，可当没有旁人督促的时候，总是缺乏动力去行动。

所以如果你看到这篇文章，并且赞同我的内容，又有写博客的习惯，不如交换一下友情链接，互相支持一下，既交个朋友、又多个读者。

最后用那句著名的“Stay hungry, Stay foolish“自勉。

为JVM启用大页面支持

hashei — Sat, 22 May 2010 23:22:00 +0800

最近在看《Linux服务器性能调整》，书中第九章-Linux虚存的性能问题中提到了当代计算机体系结构都支持多种页面大小。大型页面可以改善高性能计算及内存密集型应用的性能。回想起之前看IBM developmentworks上介绍websphere调优和oracle weblogic中tuning都提到了这一点，于是想记下一笔，不过网上正好看到ken Wu已经就此总结过了，于是转贴在此。红色部分为我添加的。

转自 Ken Wu`s Blog

原文链接 JVM优化之调整大内存分页(LargePage)

本文将从内存分页的原理，如何调整分页大小两节内容，向你阐述LargePage对JVM的性能有何提升作用，并在文末点明了大内分页的副作用。OK，让我们开始吧！

内存分页大小对性能的提升原理

首先，我们需要回顾一小部分计算机组成原理，这对理解大内存分页至于JVM性能的提升是有好处的。

什么是内存分页？
我们知道，CPU是通过寻址来访问内存的。32位CPU的寻址宽度是 0~0xFFFFFFFF ，计算后得到的大小是4G，也就是说可支持的物理内存最大是4G。

但在实践过程中，碰到了这样的问题，程序需要使用4G内存，而可用物理内存小于4G，导致程序不得不降低内存占用。
为了解决此类问题，现代CPU引入了 MMU（Memory Management Unit 内存管理单元）。

MMU 的核心思想是利用虚拟地址替代物理地址，即CPU寻址时使用虚址，由 MMU 负责将虚址映射为物理地址。
MMU的引入，解决了对物理内存的限制，对程序来说，就像自己在使用4G内存一样。

内存分页(Paging)是在使用MMU的基础上，提出的一种内存管理机制。它将虚拟地址和物理地址按固定大小（4K）分割成页(page)和页帧(page frame)，并保证页与页帧的大小相同。

这种机制，从数据结构上，保证了访问内存的高效，并使OS能支持非连续性的内存分配。
在程序内存不够用时，还可以将不常用的物理内存页转移到其他存储设备上，比如磁盘，这就是大家耳熟能详的虚拟内存。

在上文中提到，虚拟地址与物理地址需要通过映射，才能使CPU正常工作。
而映射就需要存储映射表。在现代CPU架构中，映射关系通常被存储在物理内存上一个被称之为页表(page table)的地方。
如下图：

从这张图中，可以清晰地看到CPU与页表，物理内存之间的交互关系。

图中的page table在现代操作系统中由全局目录（PGD）-中间目录（PMD）-页表项（PTE）三层树构成，有时候不同书上图不一样但意思一样，只是画多画少。

进一步优化，引入TLB（Translation lookaside buffer，页表寄存器缓冲）
由上一节可知，页表是被存储在内存中的。我们知道CPU通过总线访问内存，肯定慢于直接访问寄存器的。
为了进一步优化性能，现代CPU架构引入了TLB，用来缓存一部分经常访问的页表内容。
如下图：

对比 9.6 那张图，在中间加入了TLB。

为什么要支持大内存分页？
TLB是有限的，这点毫无疑问。当超出TLB的存储极限时，就会发生 TLB miss，之后，OS就会命令CPU去访问内存上的页表。如果频繁的出现TLB miss，程序的性能会下降地很快。

为了让TLB可以存储更多的页地址映射关系，我们的做法是调大内存分页大小。

如果一个页4M，对比一个页4K，前者可以让TLB多存储1000个页地址映射关系，性能的提升是比较可观的。

调整OS和JVM内存分页

在Linux和windows下要启用大内存页，有一些限制和设置步骤。

Linux：
限制：需要2.6内核以上或2.4内核已打大内存页补丁。
确认是否支持，请在终端敲如下命令：

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

如果有HugePage字样的输出内容，说明你的OS是支持大内存分页的。Hugepagesize就是默认的大内存页size。
接下来，为了让JVM可以调整大内存页size，需要设置下OS 共享内存段最大值和大内存页数量。

共享内存段最大值
建议这个值大于Java Heap size，这个例子里设置了4G内存。

# echo 4294967295 > /proc/sys/kernel/shmmax

注意在32位操作系统上这个值不能超过4GB

大内存页数量

# echo 154 > /proc/sys/vm/nr_hugepages

这个值一般是 Java进程占用最大内存/单个页的大小，比如java设置 1.5G，单个页 10M，那么数量为 1536/10 = 154。
注意：因为proc是内存FS，为了不让你的设置在重启后被冲掉，建议写个脚本放到 init 阶段(rc.local)。

更简便的方法是

echo "vm.nr_hugepages=154" >> /etc/sysctl.conf

通过下述命令来验证设置是否生效

grep HugePages_Total /proc/meminfo

结果应该是你之前设置的数值154

Windows:

限制：仅支持 windows server 2003 以上server版本

操作步骤:

Control Panel -> Administrative Tools -> Local Security Policy
Local Policies -> User Rights Assignment
双击 “Lock pages in memory”, 添加用户和组
重启电脑

注意: 需要管理员操作。

单个页大小调整

JVM启用时加参数 -XX:LargePageSizeInBytes=10m

如果JDK是在1.5 update5以前的，还需要手动加 -XX:+UseLargePages，作用是启用大内存页支持。

——————————————————————

其实除了JVM可以使用大页面提高性能，还有一种应用更符合内存密集型的场景，那就是数据库。数据库的调优中很早就有了这部分的建议。详见

Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i and 10g Databases

当中提到

In order that an Oracle database can use Huge Pages in RHEL 4, you also need to increase the ulimit parameter "memlock" for the oracle user in/etc/security/limits.conf if "max locked memory" is not unlimited or too small, see ulimit -a or ulimit -l. For example:

oracle           soft    memlock         1048576
oracle           hard    memlock         1048576

The memlock parameter specifies how much memory the oracle user can lock into its address space. Note that Huge Pages are locked in physical memory. The memlock setting is specified in KB and must match the memory size of the number of Huge Pages that Oracle should be able to allocate. So if the Oracle database should be able to use 512 Huge Pages, then memlock must be set to at least 512 * Hugepagesize, which is on my system 1048576 KB (512*1024*2). If memlock is too small, then no single Huge Page will be allocated when the Oracle database starts.

如果limits文件中有相应设置的话，需要检查一下，避免系统没有留出足够的内存（被cache、buffer占用了）

不过作者也提到了

我们生产环境大部分java应用都没调过large page。性能瓶颈也不是在jvm上。

文章里提到的优化，仅仅是实验性质的。

优化对我们来说，是一个循序渐进的过程。我们追求的是效果明显的优化方案，而不是什么都调优一把。

按我的经验，这些一般只是锦上添花而已

Linux 性能监控

admin — Wed, 19 May 2010 16:48:00 +0800

我在Unix/Linux分类中曾转过《Linux System and Performance Monitoring》系列的文章，今天又在Vpsee看到了类似的几篇。内容基本一样，但是排版好许多，最主要是读起来很流畅，一步步的递进很好，没有英文资料翻译过来的那种生硬感，估计是根据那个系列结合自己经验重写过的。

下午把vpsee逛了圈，感觉是VPS服务商里blog写的最有技术含量的，不仅有linux下的应用、优化，还有架构的分析以及较少看到资料的瘦客户端介绍。还有，我经常逛的LinuxTOY就是架设在他们的服务器上的。

WebLogic如何更换64位JDK

hashei — Tue, 18 May 2010 16:08:00 +0800

使用32位JDK时，JVM一般设置最大设置为1.7G，而现在服务器普遍内存都很大，当然可以通过多个server建立垂直集群来更好的利用资源，但不妨使用64位JDK。虽然WebLogic可以直接在setDomainEnv里指定JAVA_HOME来更改JDK，但肯定会遇到BEA-000438的错，原因在于缺少对应64位JDK的native io libaray（位于weblogic/server/native）。一种方式是从别处拷贝一份过来，还有一种是下载wls_generic.jar形式的安装文件，而不是已经带有JDK的。然后下载64位JDK安装（Jrockit下载），用java –jar wls_generic.jar来安装就可以了。

————————————————————————————

附一个错误分析，和native libaray相关，但并不是由于64位的关系，而是没有执行权限。

启动过程中发现

<Apr 28, 2010 6:27:15 PM GMT+08:00> <Error> <Socket> <BEA-000438> <Unable to loa
d performance pack. Using Java I/O instead. Please ensure that a native performa
nce library is in: ‘/opt/java1.5/jre/lib/IA64N:/opt/java1.5/jre/lib/IA64N/server
:/opt/java1.5/jre/../lib/IA64N::/opt/weblogic/bea/weblogic90/server/native/hpux1
1/IPF64:/opt/weblogic/bea/weblogic90/server/native/hpux11/PA_RISC:/opt/weblogic/
bea/weblogic90/server/native/hpux11/PA_RISC/oci920_8:/usr/lib’

没有启动native io，导致系统性能低下（这里要注意HP-UX里IA64N下的是32位JDK，IA64W下的才是64位JDK），而且java io配置的值较小，产生如下报错

在应用使用过程中从而出现

<Apr 28, 2010 6:14:10 PM GMT+08:00> <Error> <Console> <BEA-240003> <Console enco
untered the following error javax.servlet.jsp.JspException: Broken pipe (errno:3
2)
at com.bea.console.taglib.html.tree.TreeTag.print(TreeTag.java:231)
at com.bea.console.taglib.html.tree.TreeTag.doEndTag(TreeTag.java:192)

观察控制台的thread信息

Self-Tuning Thread Pool
Active Execute Threads    Execute Thread Total Count    Execute Thread Idle Count    Queue Length    Pending User Request Count    Completed Request Count    Hogging Thread Count    Standby Thread Count    Throughput    Health
16    58    15    6048    0    144840    4    38    4.577865205875421    OK

排队的请求数多达6000个，导致了OutOfMemory，在JAVA堆还很空的情况下

观察发现/opt/weblogic/bea/weblogic90/server/native/hpux11/IPF32下面和native io相关的libmuxer.so没有执行权限，chmod +x 后再次启动错误信息不再出现

欲速则不达

hashei — Mon, 12 Apr 2010 23:23:00 +0800

离上次更新已经有一个半月了，这段时间在机房待的比较多，弄的我耳鸣不止，双休日又读书，所以一直懒得动笔，难得的空闲时间又在沉迷《火炬之光》（Torch Light)。博这种东西，一旦有了惰性就完了啊，今天总算打起精神，记下最近走过的几个弯路。

在Linux上安装WAS7，图形界面无法启动的问题

$ ../JDK/jre.pak/repository/package.java.jre/java/jre/bin/java setup.jar The installer is unable to run in graphical mode. Try running the installer with the -console or -silent flag.

这个问题其实是freebsdjlu做实验的时候发现的，因为我之前安装都是没问题，所以一开始觉得是安装软件的问题，没下完整或者ftp没用二进制，后来发现是缺少compat-libstdc++-33这个包。

后来去查了安装环境要求，原来需要的包很多

Preparing Red Hat Enterprise Linux 5 for installation

Platforms that support both 32-bit and 64-bit applications require both the 32-bit and 64-bit versions of the following packages:

compat-libstdc++-33-3.2.3-61
compat-db-4.2.52-5.1
libXp-1.0.0-8
libXmu-1.0.2-5
libXtst-1.0.1-3.1
pam-0.99.6.2-3.26.el5
libXft-2.1.10-1.1

可以参考 Installing and verifying Linux packages来安装需要的包

而且SELinux也是需要考虑的

You should consider the following points if you have enabled Security-Enhanced Linux (SELinux) on your Red Hat Enterprise Linux Version 5 operating system.

If SELinux is enabled and enforced while you are installing the product from the CD, then you must mount the CD with the following option:
```
 -o context=system_u:object_r:textrel_shlib_t
```
If you enable SELinux after installing the product while SELinux was disabled, then the file labels will be reset when the system is rebooted. In this case, you must run the relabel_was.sh script located in app_server_root /properties/version/nif/config/script to relabel the product runtime files. Note that running the relabel_was.sh command is not necessary if you made security mode changes with the commandsetenforce, which does not required a system reboot.

后来在一篇博客上看到这么一段

My little poor server

为什么一开始决定要在Windows Server 2003 64bit上安装Oracle9i呢？于是给服务器安装了Windows Server 2003 64bit操作系统。

可是为什么硬件架构是AMD64和Intel 64呢？Oracle9i没有这两个架构的64bit版本。于是格式化了重新安装Redhat Enterprise Linux 5。

可是又为什么不是正版的Redhat Enterprise Linux 5呢？于是格式化安装了Redhat Enterprise Linux 4 Update 2。

可是为什么RHEL4 Update 2不能在阵列上设置MPIO呢？于是格式化安装了Redhat Enterprise Linux 4 Update 4。

时间就这样在一遍一遍地折磨服务器和折磨群众的过程中悄然溜走，转眼就到了下班的时候，Yeah，明天再说了。

都是在出现问题以后才去检查软硬件兼容表的

在IBM刀片机上安装RHEL报错

在一台IBM的刀片机（JS21，PowerPC芯片）上直接安装redhat5.5——rhel-server-5.5-ppc-dvd。安装过程中报错：

md: Autodetecting RAID arrays.

md: autorun …

md: … autorun DONE.

RAMDISK: Compressed image found at block 0

RAMDISK: ran out of compressed data

invalid compressed format (err=1)

Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

机器上原先有操作系统AIX5.3

用上面这串错误去Google的话，会得到很多不同的解释，就是说造成这个问题的原因有多种。一次次的尝试很耗费时间，最后找到了这篇文章，《IBM Installation Toolkit：在 POWER 上加载 Linux》，用文中提到的工具IBM Installation Toolkit for Linux on POWER一次就安装成功了。（因为RHEL 5.5本月头上刚发布，所以工具介绍里没有写明支持，但是安装没有问题，5.3以上都用能用这个来安装）

这个问题其实和先前那个一样，被原有的知识所误导——X86平台上IBM的ServerGuide是为安装Windows操作系统准备的，安装Linux直接用安装盘即可，上手就去做，欲速则不达。

Java 类加载器的又一篇文章

hashei — Wed, 03 Mar 2010 23:30:00 +0800

之前写过两篇关于java类加载的文章，分别是：《WebSphere的类加载机制和故障排查》，《再谈WebSphere的类加载和故障排查》。今天在IBM网站上看到一篇《深入探讨 Java 类加载器》，分享出来炒炒冷饭。以后遇到问题的时候也能有点方向。

Java 虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就很容易花大量的时间去调试 ClassNotFoundException 和 NoClassDefFoundError 等异常。本文将详细介绍 Java 的类加载器，帮助读者深刻理解 Java 语言中的这个重要概念。

互联网网站的反爬虫策略浅析（转）

hashei — Sun, 28 Feb 2010 13:11:00 +0800

很早就看过，不过那时候没网站，也就没上心，自从开了JQ公会，头两月还好，第三个月搜狗的爬虫每天就占了几G的流量，不过那时候是虚拟主机，可配置性不大。现在转到VPS，也要开始注意了。

http://robbin.javaeye.com/

互联网网站的反爬虫策略浅析

因为搜索引擎的流行，网络爬虫已经成了很普及网络技术，除了专门做搜索的Google，Yahoo，微软，百度以外，几乎每个大型门户网站都有自己的搜索引擎，大大小小叫得出来名字得就几十种，还有各种不知名的几千几万种，对于一个内容型驱动的网站来说，受到网络爬虫的光顾是不可避免的。

一些智能的搜索引擎爬虫的爬取频率比较合理，对网站资源消耗比较少，但是很多糟糕的网络爬虫，对网页爬取能力很差，经常并发几十上百个请求循环重复抓取，这种爬虫对中小型网站往往是毁灭性打击，特别是一些缺乏爬虫编写经验的程序员写出来的爬虫破坏力极强。曾经有一次我在JavaEye的日志里面发现一个User-Agent是Java的爬虫一天之内爬取了将近100万次动态请求。这是一个用JDK标准类库编写的简单爬取网页程序，由于JavaEye网站内部链接构成了回环导致程序陷入了死循环。对于JavaEye这种百万PV级别的网站来说，这种爬虫造成的访问压力会非常大，会导致网站访问速度缓慢，甚至无法访问。

此外，相当数量的的网页爬虫目的是盗取目标网站的内容。比方说JavaEye网站就曾经被两个竞争对手网站爬取论坛帖子，然后在自己的论坛里面用机器人发帖，因此这种爬虫不仅仅影响网站访问速度，而且侵犯了网站的版权。

对于一个原创内容丰富，URL结构合理易于爬取的网站来说，简直就是各种爬虫的盘中大餐，很多网站的访问流量构成当中，爬虫带来的流量要远远超过真实用户访问流量，甚至爬虫流量要高出真实流量一个数量级。像JavaEye网站虽然设置了相当严格的反爬虫策略，但是网站处理的动态请求数量仍然是真实用户访问流量的2倍。可以肯定的说，当今互联网的网络流量至少有2/3的流量爬虫带来的。因此反爬虫是一个值得网站长期探索和解决的问题。

一、手工识别和拒绝爬虫的访问

有相当多的爬虫对网站会造成非常高的负载，因此识别爬虫的来源IP是很容易的事情。最简单的办法就是用netstat检查80端口的连接：

C代码

netstat -nt | grep youhostip:80 | awk ‘{print $5}’ | awk -F":" ‘{print $1}’| sort | uniq -c | sort -r -n

这行shell可以按照80端口连接数量对来源IP进行排序，这样可以直观的判断出来网页爬虫。一般来说爬虫的并发连接非常高。
如果使用lighttpd做Web Server，那么就更简单了。lighttpd的mod_status提供了非常直观的并发连接的信息，包括每个连接的来源IP，访问的URL，连接状态和连接时间等信息，只要检查那些处于handle-request状态的高并发IP就可以很快确定爬虫的来源IP了。
拒绝爬虫请求既可以通过内核防火墙来拒绝，也可以在web server拒绝，比方说用iptables拒绝：

C代码

iptables -A INPUT -i eth0 -j DROP -p tcp –dport 80 -s 84.80.46.0/24

直接封锁爬虫所在的C网段地址。这是因为一般爬虫都是运行在托管机房里面，可能在一个C段里面的多台服务器上面都有爬虫，而这个C段不可能是用户宽带上网，封锁C段可以很大程度上解决问题。
有些人提出一种脑残的观点，说我要惩罚这些爬虫。我专门在网页里面设计动态循环链接页面，让爬虫掉进陷阱，死循环爬不出来，其实根本用不着设置陷阱，弱智爬虫对正常网页自己就爬不出来，这样做多此一举不说，而且会让真正的搜索引擎降低你的网页排名。而且运行一个爬虫根本不消耗什么机器资源，相反，真正宝贵的是你的服务器CPU资源和服务器带宽，简单的拒绝掉爬虫的请求是反爬虫最有效的策略。

二、通过识别爬虫的User-Agent信息来拒绝爬虫

有很多爬虫并不会以很高的并发连接爬取，一般不容易暴露自己；有些爬虫的来源IP分布很广，很难简单的通过封锁IP段地址来解决问题；另外还有很多各种各样的小爬虫，它们在尝试Google以外创新的搜索方式，每个爬虫每天爬取几万的网页，几十个爬虫加起来每天就能消耗掉上百万动态请求的资源，由于每个小爬虫单独的爬取量都很低，所以你很难把它从每天海量的访问IP地址当中把它准确的挖出来。
这种情况下我们可以通过爬虫的User-Agent信息来识别。每个爬虫在爬取网页的时候，会声明自己的User-Agent信息，因此我们就可以通过记录和分析User-Agent信息来挖掘和封锁爬虫。我们需要记录每个请求的User-Agent信息，对于Rails来说我们可以简单的在app/controllers/application.rb里面添加一个全局的before_filter，来记录每个请求的User-Agent信息：

Ruby代码

logger.info "HTTP_USER_AGENT #{request.env["HTTP_USER_AGENT"]}"

然后统计每天的production.log，抽取User-Agent信息，找出访问量最大的那些User-Agent。要注意的是我们只关注那些爬虫的User-Agent信息，而不是真正浏览器User-Agent，所以还要排除掉浏览器User-Agent，要做到这一点仅仅需要一行shell：

Ruby代码

grep HTTP_USER_AGENT production.log | grep -v -E ‘MSIE|Firefox|Chrome|Opera|Safari|Gecko’ | sort | uniq -c | sort -r -n | head -n 100 > bot.log

统计结果类似这样：

C代码

57335 HTTP_USER_AGENT Baiduspider+(+http://www.baidu.com/search/spider.htm)
56639 HTTP_USER_AGENT Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
42610 HTTP_USER_AGENT Mediapartners-Google
19131 HTTP_USER_AGENT msnbot/2.0b (+http://search.msn.com/msnbot.htm)

从日志就可以直观的看出每个爬虫的请求次数。要根据User-Agent信息来封锁爬虫是件很容易的事情，lighttpd配置如下：

C代码

$HTTP["useragent"] =~ "qihoobot|^Java|Commons-HttpClient|Wget|^PHP|Ruby|Python" {
url.rewrite = ( "^/(.*)" => "/crawler.html" )
}

使用这种方式来封锁爬虫虽然简单但是非常有效，除了封锁特定的爬虫，还可以封锁常用的编程语言和HTTP类库的User-Agent信息，这样就可以避免很多无谓的程序员用来练手的爬虫程序对网站的骚扰。
还有一种比较常见的情况，就是某个搜索引擎的爬虫对网站爬取频率过高，但是搜索引擎给网站带来了很多流量，我们并不希望简单的封锁爬虫，仅仅是希望降低爬虫的请求频率，减轻爬虫对网站造成的负载，那么我们可以这样做：

C代码

$HTTP["user-agent"] =~ "Baiduspider+" {
connection.delay-seconds = 10
}

对百度的爬虫请求延迟10秒钟再进行处理，这样就可以有效降低爬虫对网站的负载了。

三、通过网站流量统计系统和日志分析来识别爬虫

有些爬虫喜欢修改User-Agent信息来伪装自己，把自己伪装成一个真实浏览器的User-Agent信息，让你无法有效的识别。这种情况下我们可以通过网站流量系统记录的真实用户访问IP来进行识别。
主流的网站流量统计系统不外乎两种实现策略：一种策略是在网页里面嵌入一段js，这段js会向特定的统计服务器发送请求的方式记录访问量；另一种策略是直接分析服务器日志，来统计网站访问量。在理想的情况下，嵌入js的方式统计的网站流量应该高于分析服务器日志，这是因为用户浏览器会有缓存，不一定每次真实用户访问都会触发服务器的处理。但实际情况是，分析服务器日志得到的网站访问量远远高于嵌入js方式，极端情况下，甚至要高出10倍以上。
现在很多网站喜欢采用awstats来分析服务器日志，来计算网站的访问量，但是当他们一旦采用Google Analytics来统计网站流量的时候，却发现GA统计的流量远远低于awstats，为什么GA和awstats统计会有这么大差异呢？罪魁祸首就是把自己伪装成浏览器的网络爬虫。这种情况下awstats无法有效的识别了，所以awstats的统计数据会虚高。
其实作为一个网站来说，如果希望了解自己的网站真实访问量，希望精确了解网站每个频道的访问量和访问用户，应该用页面里面嵌入js的方式来开发自己的网站流量统计系统。自己做一个网站流量统计系统是件很简单的事情，写段服务器程序响应客户段js的请求，分析和识别请求然后写日志的同时做后台的异步统计就搞定了。
通过流量统计系统得到的用户IP基本是真实的用户访问，因为一般情况下爬虫是无法执行网页里面的js代码片段的。所以我们可以拿流量统计系统记录的IP和服务器程序日志记录的IP地址进行比较，如果服务器日志里面某个IP发起了大量的请求，在流量统计系统里面却根本找不到，或者即使找得到，可访问量却只有寥寥几个，那么无疑就是一个网络爬虫。
分析服务器日志统计访问最多的IP地址段一行shell就可以了：

C代码

grep Processing production.log | awk ‘{print $4}’ | awk -F’.’ ‘{print $1"."$2"."$3".0"}’ | sort | uniq -c | sort -r -n | head -n 200 > stat_ip.log

然后把统计结果和流量统计系统记录的IP地址进行对比，排除真实用户访问IP，再排除我们希望放行的网页爬虫，比方Google，百度，微软msn爬虫等等。最后的分析结果就就得到了爬虫的IP地址了。以下代码段是个简单的实现示意：

Ruby代码

whitelist = []
IO.foreach("#{RAILS_ROOT}/lib/whitelist.txt") { |line| whitelist << line.split[0].strip if line }
realiplist = []
IO.foreach("#{RAILS_ROOT}/log/visit_ip.log") { |line| realiplist << line.strip if line }
iplist = []
IO.foreach("#{RAILS_ROOT}/log/stat_ip.log") do |line|
ip = line.split[1].strip
iplist << ip if line.split[0].to_i > 3000 && !whitelist.include?(ip) && !realiplist.include?(ip)
end
Report.deliver_crawler(iplist)

分析服务器日志里面请求次数超过3000次的IP地址段，排除白名单地址和真实访问IP地址，最后得到的就是爬虫IP了，然后可以发送邮件通知管理员进行相应的处理。

四、网站的实时反爬虫防火墙实现策略

通过分析日志的方式来识别网页爬虫不是一个实时的反爬虫策略。如果一个爬虫非要针对你的网站进行处心积虑的爬取，那么他可能会采用分布式爬取策略，比方说寻找几百上千个国外的代理服务器疯狂的爬取你的网站，从而导致网站无法访问，那么你再分析日志是不可能及时解决问题的。所以必须采取实时反爬虫策略，要能够动态的实时识别和封锁爬虫的访问。
要自己编写一个这样的实时反爬虫系统其实也很简单。比方说我们可以用memcached来做访问计数器，记录每个IP的访问频度，在单位时间之内，如果访问频率超过一个阀值，我们就认为这个IP很可能有问题，那么我们就可以返回一个验证码页面，要求用户填写验证码。如果是爬虫的话，当然不可能填写验证码，所以就被拒掉了，这样很简单就解决了爬虫问题。
用memcache记录每个IP访问计数，单位时间内超过阀值就让用户填写验证码，用Rails编写的示例代码如下：

Ruby代码

ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
render :template => ‘test’, :status => 401 and return false
end

这段程序只是最简单的示例，实际的代码实现我们还会添加很多判断，比方说我们可能要排除白名单IP地址段，要允许特定的User-Agent通过，要针对登录用户和非登录用户，针对有无referer地址采取不同的阀值和计数加速器等等。
此外如果分布式爬虫爬取频率过高的话，过期就允许爬虫再次访问还是会对服务器造成很大的压力，因此我们可以添加一条策略：针对要求用户填写验证码的IP地址，如果该IP地址短时间内继续不停的请求，则判断为爬虫，加入黑名单，后续请求全部拒绝掉。为此，示例代码可以改进一下：

Ruby代码

before_filter :ip_firewall, :except => :test
def ip_firewall
render :file => "#{RAILS_ROOT}/public/403.html", :status => 403 if BlackList.include?(ip_sec)
end

我们可以定义一个全局的过滤器，对所有请求进行过滤，出现在黑名单的IP地址一律拒绝。对非黑名单的IP地址再进行计数和统计：

Ruby代码

ip_counter = Rails.cache.increment(request.remote_ip)
if !ip_counter
Rails.cache.write(request.remote_ip, 1, :expires_in => 30.minutes)
elsif ip_counter > 2000
crawler_counter = Rails.cache.increment("crawler/#{request.remote_ip}")
if !crawler_counter
Rails.cache.write("crawler/#{request.remote_ip}", 1, :expires_in => 10.minutes)
elsif crawler_counter > 50
BlackList.add(ip_sec)
render :file => "#{RAILS_ROOT}/public/403.html", :status => 403 and return false
end
render :template => ‘test’, :status => 401 and return false
end

如果某个IP地址单位时间内访问频率超过阀值，再增加一个计数器，跟踪他会不会立刻填写验证码，如果他不填写验证码，在短时间内还是高频率访问，就把这个IP地址段加入黑名单，除非用户填写验证码激活，否则所有请求全部拒绝。这样我们就可以通过在程序里面维护黑名单的方式来动态的跟踪爬虫的情况，甚至我们可以自己写个后台来手工管理黑名单列表，了解网站爬虫的情况。

这个策略已经比较智能了，但是还不够好！我们还可以继续改进：

1、用网站流量统计系统来改进实时反爬虫系统

还记得吗？网站流量统计系统记录的IP地址是真实用户访问IP，所以我们在网站流量统计系统里面也去操作memcached，但是这次不是增加计数值，而是减少计数值。在网站流量统计系统里面每接收到一个IP请求，就相应的cache.decrement(key)。所以对于真实用户的IP来说，它的计数值总是加1然后就减1，不可能很高。这样我们就可以大大降低判断爬虫的阀值，可以更加快速准确的识别和拒绝掉爬虫。

2、用时间窗口来改进实时反爬虫系统

爬虫爬取网页的频率都是比较固定的，不像人去访问网页，中间的间隔时间比较无规则，所以我们可以给每个IP地址建立一个时间窗口，记录IP地址最近12次访问时间，每记录一次就滑动一次窗口，比较最近访问时间和当前时间，如果间隔时间很长判断不是爬虫，清除时间窗口，如果间隔不长，就回溯计算指定时间段的访问频率，如果访问频率超过阀值，就转向验证码页面让用户填写验证码。

最终这个实时反爬虫系统就相当完善了，它可以很快的识别并且自动封锁爬虫的访问，保护网站的正常访问。不过有些爬虫可能相当狡猾，它也许会通过大量的爬虫测试来试探出来你的访问阀值，以低于阀值的爬取速度抓取你的网页，因此我们还需要辅助第3种办法，用日志来做后期的分析和识别，就算爬虫爬的再慢，它累计一天的爬取量也会超过你的阀值被你日志分析程序识别出来。

总之我们综合运用上面的四种反爬虫策略，可以很大程度上缓解爬虫对网站造成的负面影响，保证网站的正常访问。

软硬兼施优化 WebSphere Application Server

hashei — Sun, 21 Feb 2010 23:46:00 +0800

之前看的很多was优化案例，包括自己实施过程中都只从WebSphere的角度来考虑问题，虽然WAS的优化中包括了操作系统层面的优化，比如对AIX、HPUX的系统参数做出调整，对于网络tcp的参数做出改动，但并没有更进一步，在进行LPAR分区前就做出完整的规划。

WebSphere管理员和硬件与操作系统管理员往往交流不多，且是串行的实施顺序。虽说也就那么做下来了，但是是否充分发挥了硬件的资源，是否达到了最好的性能，最稳定的运行，还是可以有改进的余地？都值得探讨。IBM网站上这三篇文章可谓打通了两种管理员之间的任督二脉，看懂了总有好处。

本书提供了整体系统观点，重点关注在 Power System 和 AIX 上运行 WebSphere Application Server 负载的环境的端到端系统部署、调优和管理方法。因而，本书为两类截然不同的技术读者架起了一座桥梁，也就是硬件和操作系统管理员与 WebSphere Application Server 应用软件工程师。我们都了解，在典型的企业环境中，这两类技术读者需要密切合作，但仍然有着不同的视角和职责。然而，对于企业来说，在度量 Power System 和 AIX 上运行的 WebSphere Application Server 投资的成败时，最终要取决于所有系统架构师能否很好地理解如何同心协力地利用每种产品的特有优势。因而，我们首先要做的是澄清各种观点。

在 Power System 上优化 WebSphere Application Server，第 1 部分: 入门以及优化策略

在 Power System 上优化 WebSphere Application Server，第 2 部分: 设置 Power System 硬件和分区（上）

在 Power System 上优化 WebSphere Application Server，第 3 部分: 设置 Power System 硬件和分区（下）

有空么可以再看看《WebSphere Application Server V6.1 Planning and Design WebSphere Handbook Series》

SSH的一些知识

hashei — Sun, 14 Feb 2010 22:14:00 +0800

最近的几个项目里都用到Linux，于是不能像UNIX下有同事帮忙配置好一切那样轻松，要自力更生了。首先记录一下每次都会用到却还没深深记录在我的艾宾浩斯记忆曲线中的SSH相关知识。

SSH的全称为Secure Shell Protocol，是一种在互联网上提供安全远程登录（取代telnet)及其它安全网络服务（取代FTP）的协议，只要在客户端连接时选择SSH协议即可。对于服务器端的配置，Red Hat Enterprise Linux默认开启了SSH服务，对于配置文件的详细解释，可以参考下面两篇文章。

sshd_config配置详解

sshd_config 中文手册

由于SSH的传输加密特性，还可以用来做安全隧道

SSH tunnel tips

IBM developworks上的这一篇实战 SSH 端口转发介绍的更为详细，而且有“X 协议转发实例分析”，在维护UNIX/LINUX时可以更方便。

安全隧道的实际用途之一么，当然是用来翻墙。

Firefox + Autoproxy + Tor 使用详解（转载）

MyEnTunnel+FireFox+FoxyProxy 通过SSH帐号翻墙教程

如何使用代理服务器

当然用PPTP建个VPN也是可以的

利用低端VPS开设VPN翻墙

科学松鼠会的一篇公钥安全机制与宫爆鸡丁的故事不错

扯远了，最后付一篇

Unix/Linux 系统自动化管理: 远程登录篇

聚沙成塔-小哈的记事薄

总有一些世界观，是傻逼呵呵地矗立在那里的

Stay hungry，Stay foolish

为JVM启用大页面支持

内存分页大小对性能的提升原理

调整OS和JVM内存分页

Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i and 10g Databases

Related posts:

Linux 性能监控

Related posts:

WebLogic如何更换64位JDK

Related posts:

欲速则不达

在Linux上安装WAS7，图形界面无法启动的问题

在IBM刀片机上安装RHEL报错

Java 类加载器的又一篇文章

互联网网站的反爬虫策略浅析（转）

互联网网站的反爬虫策略浅析

一、手工识别和拒绝爬虫的访问

二、通过识别爬虫的User-Agent信息来拒绝爬虫

三、通过网站流量统计系统和日志分析来识别爬虫

四、网站的实时反爬虫防火墙实现策略

1、用网站流量统计系统来改进实时反爬虫系统

2、用时间窗口来改进实时反爬虫系统

软硬兼施优化 WebSphere Application Server

Related posts:

SSH的一些知识

聚沙成塔-小哈的记事薄

总有一些世界观，是傻逼呵呵地矗立在那里的

Stay hungry，Stay foolish

为JVM启用大页面支持

内存分页大小对性能的提升原理

调整OS和JVM内存分页

Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i and 10g Databases

Related posts:

Linux 性能监控

Related posts:

WebLogic如何更换64位JDK

Related posts:

欲速则不达

在Linux上安装WAS7，图形界面无法启动的问题

在IBM刀片机上安装RHEL报错

Java 类加载器的又一篇文章

互联网网站的反爬虫策略浅析（转）

互联网网站的反爬虫策略浅析

一、手工识别和拒绝爬虫的访问

二、通过识别爬虫的User-Agent信息来拒绝爬虫

三、通过网站流量统计系统和日志分析来识别爬虫

四、网站的实时反爬虫防火墙实现策略

1、用网站流量统计系统来改进实时反爬虫系统

2、用时间窗口来改进实时反爬虫系统

软硬兼施 优化 WebSphere Application Server

Related posts:

SSH的一些知识

软硬兼施优化 WebSphere Application Server