2011年3月网站Lucene调整优化手记
壹.起因
自网站重构以来，我们加入了Apache Lucene，用来辅助mysql数据库存储查询，以减少对DB的负担，网站的大部分数据共有的特点是不需要即时更新，数据量较大，这正是Lucene擅长解决的问题领域，起始版本是2.4，开始效果不赖，当然也遇到了一些问题，例如判断索引文件合理的大小值问题，分词器的选择问题，对于一个完整的存储查询解决方案来说是不言而喻的，Lucene的学习成本相对而言也较高，理论和内容都比较多，需要花时间和精力来研究。
09年底，Lucene推出了3.0版，自从2.9版开始，内部结构发生了不小的变化，同时根据官方文档的提示，Lucene在自身性能上有了明显的提高，随后我们做出：升级到3.0的决定。
2010年，网站各个部分的数据访问基本都是基于Lucene，各类索引的建立访问和管理，成为了新的问题，如何组织索引文件，如何更有效的访问，这类问题不断浮现，2010年底，网站的访问量有了新的提升，如何应对激增的访问，成为了首要的问题。
2011年开始，访问量最大的www系统显现出了问题，在高访问量下，出现了OutOfMemoryError，当虚拟机可用内存不足2%，且不能正常回收时，会throw出这个Error，一个良好运行的系统，是不应出现这样明显的性能问题的，我们决定：必须要解决这个问题了。
贰.经过
提到应对访问量，有经验的人员首先想到的是扩展，垂直扩展是我们首先尝试的，最直接的做法是：增大每个tomcat的JVM内存上限，提高tomcat的访问线程上限，研究apache和tomcat之间，如何更有效的转发请求等等，而随后的水平扩展，最直接的做法是，增加tomcat数量，更多的分散负载请求，这些我们都有尝试，效果却不明显，问题何在？最终我们把目光移到了Lucene本身，是不是我们使用它的方式有问题？
随后展开的查询搜索研究过程暂且不表，我们最终发现了一处地方，很有可能会影响性能：在我们的索引数据查询方法里，都是通过类似这样的方式来获得IndexSearcher对象的
