2012-04-03 57 views
0

我試圖用大約150萬個節點的東西索引一個drupal站點。大多數簡單的節點,大約100k節點的規模較大(用tika處理的pdf文檔)。索引編制時,Apache SOLR 3.5掛起

我已經嘗試了幾次索引,並且總是以相同的方式失敗:SOLR在索引數日後(不尋找最大吞吐量本身)後因高負載和mem使用率而崩潰/掛起。首先,我將安裝移到了一個更大的盒子裏,從2 cpu/2GB內存到8核心16GB內存。這解決了問題一段時間,但現在情況幾乎完全相同。我能夠索引約500k節點。

Java的使用比堆大小(目前爲8000M) Solr的無響應的索引方式更多的內存(交換很多) 負荷約爲3.0(對於小和大盒)。搜索速度緩慢但可能。管理界面是響應式的

重新啓動SOLR可以解決問題一段時間,但它總是會回來。

在崩潰期間查詢索引大小時,我注意到目錄大小波動很大。在啓動SOLR之後,目錄大約是6,5,並且在再次降低到6.5 GB之前,它的工作方式可以達到13GB。這不斷重複。

我已經添加了有關注銷內存錯誤的說明,但是這不會提供給我任何日誌。

我爲drupal 6使用標準的SOLR配置。我使用了不同的mergefactors,但這似乎沒有做任何事情來解決問題。

有想法的人嗎?如果您需要更多信息,我會盡可能快地做出迴應!

這是在我的日誌的時刻: 異常在線程 「Lucene的合併線程#0」 org.apache.lucene.index.MergePolicy $ MergeException:java.io.FileNotFoundException:在/ usr /本地/ solr35 /例子/multicore/mydivp/data/index/_1bm.fnm(無此文件或目錄) at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:517) at org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run(ConcurrentMergeScheduler.java:482) 引起:java.io.FileNotFoundException:/usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm(沒有這樣的文件或目錄) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile。(RandomAcc在org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:345) 處, apache.lucene.index.FieldInfos。(FieldInfos.java:74) at org.apache.lucene.index.SegmentCoreReaders。(SegmentCoreReaders.java:73) at org.apache.lucene.index.SegmentReader.get(SegmentReader。 Java的:115) 在org.apache.lucene.index.IndexWriter $ ReaderPool.get(IndexWriter.java:705) 在org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4400) 的組織。 apache.lucene.index.IndexWriter.merge(IndexWriter.java:3940) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:388) 在org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run(ConcurrentMergeScheduler.java:456) 2012-04-03 14:26:25。409:信息::關閉掛鉤完整

親切的問候, 布拉姆·龍根

更新2012-04-06

它仍然是行不通的..我檢查的數據/索引/目錄揭示了Solr的保持重建/合併..一個段被構建,一旦完成,先前被刪除並且Solr再次啓動,即使沒有添加新文檔。另一個奇怪的是.fdt文件不會增長,即使Solr狀態表明大約300k以上的文檔被編入索引。目錄中最大的.fdt文件從不大於4.9GB。

有什麼想法?

+0

磁盤空間使用情況的變化是正常的。 Solr會在索引段變得過大時自動合併索引段。內存不足錯誤應該已經記錄到主Servlet容器日誌中,Tomcat的catalina.out或Jetty的jetty.log。什麼版本的Java? – 2012-04-03 16:53:44

+0

你錯誤理解Java如何直到內存,[這堆不是JVM實際使用的東西,它比這更復雜](http://stackoverflow.com/a/9146775/177800)。 – 2012-04-03 18:28:13

+0

我使用最新的java運行ubuntu 10.04: java版本「1.6.0_20」 OpenJDK運行時環境(IcedTea6 1.9.13)(6b20-1.9.13-0ubuntu1〜10.04.1) OpenJDK 64位服務器VM (構建19.0-b09,混合模式) 在我在CentOS上運行之前.. 我可能會誤解Java利用內存的方式,但此時無論我分配給-XmX的什麼值,JVM都是吃所有的物理內存和交換查殺性能;) – 2012-04-04 13:56:45

回答

1

這個博客可能在理解性能因素有助於(博客是上查詢更集中)和合並政策

http://www.nickveenhof.be/blog/upgrading-apache-solr-14-35-and-its-implications

而且,是你在同一臺服務器上的Solr和Drupal?

其他信息,建議您在使用logbytemerge或默認值時將luceneMatchVersion設置爲最新的Lucene_35。 Lucene的新版本應該有內存泄漏的修復也:

<?xml version="1.0" encoding="UTF-8" ?> 
<config name="my_config"> 
    <!-- Controls what version of Lucene various components of Solr 
     adhere to. Generally, you want to use the latest version to 
     get all bug fixes and improvements. It is highly recommended 
     that you fully re-index after changing this setting as it can 
     affect both how text is indexed and queried. 
    --> 
    <luceneMatchVersion>LUCENE_35</luceneMatchVersion> 
    <abortOnConfigurationError>${solr.abortOnConfigurationError:true}</abortOnConfigurationError> 
    <indexDefaults> 
    <useCompoundFile>false</useCompoundFile> 
    <mergeFactor>10</mergeFactor> 
    <!-- Tell Lucene when to flush documents to disk. 
    Giving Lucene more memory for indexing means faster indexing at the cost of more RAM 
    If both ramBufferSizeMB and maxBufferedDocs is set, then Lucene will flush based on whichever limit is hit first. 
    --> 
    <ramBufferSizeMB>32</ramBufferSizeMB> 
    <maxMergeDocs>2147483647</maxMergeDocs> 
    <maxFieldLength>20000</maxFieldLength> 
    <writeLockTimeout>1000</writeLockTimeout> 
    <commitLockTimeout>10000</commitLockTimeout> 
    <!-- 
    Expert: 
    The Merge Policy in Lucene controls how merging is handled by Lucene. The default in 2.3 is the LogByteSizeMergePolicy, previous 
    versions used LogDocMergePolicy. 

    LogByteSizeMergePolicy chooses segments to merge based on their size. The Lucene 2.2 default, LogDocMergePolicy chose when 
    to merge based on number of documents 

    Other implementations of MergePolicy must have a no-argument constructor 
    --> 
    <mergePolicy>org.apache.lucene.index.LogByteSizeMergePolicy</mergePolicy> 
... 
+0

嗨,尼克,謝謝你的回答! Solr和Drupal運行在不同的服務器上。我懷疑它與合併策略有關,但我不知道是什麼..我重新啓動了SOLR,這意味着它再運行20個小時..現在它創建新的.ftd並刪除舊的。 – 2012-04-04 14:10:53

+0

嗨,實際上我已經添加了 LUCENE_35到配置,沒有幫助:( – 2012-04-06 10:17:03

+0

好吧,嘗試了不同的mergepolicys,但每次我最大的.fdt文件達到4.9GB Solr只是崩潰:(達到此限制幾次現在..任何想法? – 2012-04-12 19:20:25

1

他的傢伙,

我已經改變了MergePolicy到LogByteSizeMergePolicy和MergeScheduler到ConcurrentMergeScheduler這似乎解決德問題。仍然不完全確定發生了什麼,但我們正在備份和運行;)

謝謝!