T级数据下 lucene 性能 还好吗？

本人无能，1T数据下lucene的索引程序就做了8天。。还在继续。
   无奈只好请教各位，有谁在1T数据下做过lucene索引程序，8天正常吗？

  有点语无伦次了，说一下具体情况吧
------------------------------------------------------------------------------
  服务器  win2003
  cpu 8个，内存 8g 硬盘 11t
  测试文件大小1t，包含文件目录200多，文件数目超过1700w，都是小文件，没有超过1m的。
-------------------------------------------------------------------------------

  预估2天完成，预估索引大小200g
  实际8天未完成，目前索引大小280g。

----------------------------------------------------------------------------------
  预估是有差别的，而且还很大。

----------------------------------------------------------------------------------
  log分析，后期平均每个文件处理时间变成 300%-500%，原因不清楚。


  在小数据量下的情况下做各种测试，无问题。

  请教各位解题思路，发现症结的方法。

换操作系统 win2003 sucks

恩 谢谢Readonly

这个是个问题。

你监测过创建索引时候的CPU/Memory/IO情况吗？
偶以前用的lucene量很少的，但是据有经验的高人教导：超过5G的索引，搜索起来速度就会急剧下降了，需要考虑用分布式索引和搜索。
高性能的全文检索方案，请google lucene/solar的邮寄列表的相关讨论。

对于 CPU/Memory/IO 有监视
其中CPU 开始 50-60% 这也是前期做了一些简单测试配置出来的结果。
后来就完蛋了 5-7%

Memory 逐渐增高，加到8.3g 不动了 一直到今天。。 估计是有点瓶颈问题了。

重点监测的是IO

几天下来 测试数据如下
Avg Disk Queue Length - 36 左右
Avg Disk Read Queue Length - 9 左右
Avg Disk Write　Queue Length - 26左右

以上数据解释为

1 Avg. Disk Queue Length（物理磁盘\平均磁盘盘队列长度）
阀值: 不超过组成物理磁盘的轴数的 1.5 到 2 倍。另有一种说法：Should not be higher than the number of spindles plus two，是轴数+2？
含义: 表示了在采样时间内，指定磁盘读和写请求队列的长度。（大多数磁盘只有一个轴，但独立磁盘冗余阵列 (RAID) 设备通常有多个轴。硬件 RAID 设备在系统监视器中显示为一个物理磁盘。通过软件创建的多个 RAID 设备在系统监视器中显示为多个实例。）

2 Avg. Disk Read Queue Length（物理磁盘\平均磁盘读队列长度）
阀值: 应该小于2
含义: 表示了在采样时间内，指定磁盘读请求队列的长度。


3 Avg. Disk Write Queue Length（物理磁盘\平均磁盘读队列长度）
阀值: 应该小于2
含义: 表示了在采样时间内，指定磁盘写请求队列的长度。


根据以上解析的分析是
读取磁盘不是问题，写入索引出现瓶颈。
CPU不是瓶颈，内存可能是平静

---------------------------------------------------
<据有经验的高人教导：超过5G的索引，搜索起来速度就会急剧下降了，需要考虑用分布式索引和搜索。
>
你说的情况是检索时间，我还没有到那一步呢。。所以哭的心都有了。。

目前是8个cpu，启动线程12个(少量数据测试12个线程最大程度利用cpu)
每个目录一个线程，分别索引。索引完毕后，不进行合并，保持不变，减少线程互锁的可能性。

另外索引数据已经超过28g，是否要合并这237个索引目录都是问题，合并之后速度未必会快。。算了 这是后话 等我做完了这个索引文件再说

                                                                    以上

我也在想1tb的数据，做一个索引，那索引文件必定是上百gb的，就这个索引文件的大小对lucene的搜索来说可能也是一个问题。
易或也向caocao那样，搜到一定数量后停止，如果是这样，我倒觉得把1tb分成几部分（可能需要根据应用本身的需求来划分），分别做索引，多个线程＋多台机器，这样速度应该会快很多

而且可以考虑一下这些文件中是不是所有的内容都需要作索引，看看能否尽量排除掉一些不需要作索引的文件信息

祝顺利，不过我好像看到有说过多份索引结果合并有时候会有一些问题



是不是代码有问题啊，否则memory不会不能释放的，是否是flush的周期太长了，所以内存得不到释放，可以缩短flush的周期，然后每隔一定的时间gc一下


ps供参考：之前我1000w条数据作索引，索引文件大概是2g不到，4核4g内存的cpu，要使用4个小时。

据高人说，这样的场景，肯定是要分布式，多节点去处理，例如mapreduce，并且文件系统的选择也很重要

谢谢ahuaxuan 的关注！
让我感觉到我还不是一个人在煎熬 :)

关于你说的<把1tb分成几部分>的问题。我也想过了，由于上百g的索引文件对lucene来说检索可能是个问题，所以我打算划分成多个单独的索引。检索的时候采用ParallelMultiSearcher同时索引多个索引文件，反正我有8个cpu....
方式是个这个方向，实验还没有做。。

不过我还有一个问题，我最终的测试数据是11t，怎么划分也是个问题。

关于<是不是所有的内容都需要作索引，看看能否尽量排除掉一些不需要作索引的文件信息>,我这里的信息都是txt，也就是全部都要做索引。

另外要求检索精度到具体的行。基本不可能排除什么东西。

关于内存，我也怀疑代码有问题，最起码在一个文件夹有260w个文件的情况下，代码有点不合适。

目前我是先读入到内存中，做成内存索引，每到10000个文件，将内存索引合并到磁盘中。其中10000这个参数可能有点大。

另外目前据观察，如果按目录索引，该目录文件过多（大于260w）会明显影响索引速度，单个文件索引时间变成500%。

恕我新学的，分布式，多节点是啥？
如果是靠多台机器分布提高的话，目前我只有2台，配置一样 ，参考上面。

如果一起做1T数据索引。。。。没有尝试过。。 能有帮助吗？ 这也是一个思路。。

建议改成Microsoft index service,windows自带的，应该支持TB没问题。