0
我想知道我需要更改哪些參數（如果存在）以減少Qtime。如何減少Qtime？
Qtime : The elapsed time (in milliseconds) between the arrival of the request (when the SolrQueryRequest object is created) and the completion of the request handler. It does not include time spent in the response writer formatting/streaming the response to the client.
當我更新我的文檔時，我記錄了捲曲響應，並且我注意到QTime在此期間增加。
例如，我的第一個響應（對應於我的第一個doc索引）是6293毫秒。並且在大量索引文件之後，我的QTime變長：1560781毫秒，所以26分鐘左右！
編輯
第一招：10000個Solr的文檔1 CSV文件 - > QTIME：6293ms
第二招：用10000個Solr的文檔1 CSV文件 - > QTIME：1560781毫秒
這些措施之間的延遲= 32分鐘19s
此間隔期間索引的編號文檔：26720000文檔ments
我想這可以改善，但我不知道女巫設置修改有更好的表現。
關係到我的系統
- 信息我1種Solr的情況下，與一個核心。
- 我的系統運行在虛擬機上有8個CPU和16GB RAM
- 我用30％左右的RAM
- 我是JVM：1.7.0_09-的IcedTea OpenJDK的運行時環境（RHEL-2.3.8.0.el6_4 -x86_64） OpenJDK的64位服務器VM（建23.7-B01，混合模式）
問題
- 也許我需要設置更多的線程更新文件或類似的東西。
- 這種行爲可能與Jetty有關嗎？ （我不認爲有與Jetty的鏈接，有人可以證實它？）
- 如何使用更多的RAM來索引數據？ （我已經通過此命令設置了JVM爲Solr分配足夠的RAM：java -Xms2048M -Xmx8192M -jar start.jar）
- 我應該使用更多的solr實例（SolrCloud？）來解決它嗎？
- 爲什麼Qtime隨着更新負載而增加？它是Solr限制嗎（RAM，磁盤）？
任何提示，以幫助我更快地完成我的更新，將不勝感激。
謝謝。
有多少文件，你在指標有哪些？什麼是索引大小？開始6000ms已經非常慢了。 –
嗨，Okke，是的，我同意你的觀點，這很慢。我添加了在我的問題中提出的細節。這種行爲很奇怪，似乎在索引進程級別存在瓶頸，因爲延遲（或Qtime）會隨着增長而增加。擔心的是我只用了30％的RAM。 – Corentin
你什麼時候提交？你使用的是什麼DirectoryFactory。你什麼時候GC？許多因素起作用。建議的鏈接是一個好的開始。否則分佈式或Solrcloud解決方案始終是一個可以考慮的選項。 –