SolrCloud 15-20分鐘

的設置
後消失我們有（在每個DC 3）設置組成的6臺服務器一個SolrCloud（Solr的版本4.10.4）羣集分佈在2個數據中心。SolrCloud 15-20分鐘

羣集被設定與3個碎片和2的複製因子並處理一個芯與45M文檔在約每分片100GB平均。有3個Zookeeper實例管理位於6臺服務器中的3臺（第一臺DC中的服務器）上的羣集。

核心駐留在所有碎片一個6Gb/s的SSD驅動器上。 DC內的ping時間在0.3ms的範圍內，而DC間的ping時間在3ms的範圍內。

羣集是設置在Tomcat 7.0.61和Java 7與26GB的所分配的存儲器，同時每個服務器具有可用32GB而每個節點被配置爲接觸所述動物園管理員每30秒。

每個Solr的節點緩存配置如下

<filterCache class="solr.FastLRUCache" 
      size="40000" 
      initialSize="40000" 
      autowarmCount="0"/> 
<queryResultCache class="solr.LRUCache" 
       size="50000" 
       initialSize="20000" 
       autowarmCount="0"/> 
<documentCache class="solr.LRUCache" 
       size="2000000" 
       initialSize="2000000" 
       /> 
<fieldValueCache class="solr.FastLRUCache" 
       size="8" 
       autowarmCount="8" 
       showItems="8" />

更重要的是，我們必須執行某些搜索操作的API應用程序頂一下，大多數時候是這樣的：

q=Fragmento+de+retablo+NOT+DATA_PROVIDER%3A%22CER.ES%3A+Red+Digital+de+Colecciones+de+museos+de+Espa%C3%B1a%22& 
rows=12&start=0& 
sort=score+desc& 
timeAllowed=30000&fl=*%2Cscore&facet.mincount=1

我們使用一個或多個參數對參數進行排序（第二個參數是我們的模式的唯一標識符，但在本例中不是）。

問題
我們的API每秒發送大約5-10查詢集羣上。即使最少數量的請求在一段時間後壓倒了羣集，節點也開始消失，同時觀察到大量的磁盤I/O。我們做一些手工高速緩存預熱約10分鐘，我們讓之前所提供的核心的API，我們注意到，一段時間後（以及集羣的崩潰前）在高速緩存中的命中率是1，但所有的queryResultCache=0.67和documentCache=0.9 ，而沒有任何驅逐事件發生。內存消耗約爲88％。

任何想法可能是錯誤的，或我們應該注重將得到高度讚賞。

來源

2015-09-25 Georgios Mamakis

你檢查你的Solr /動物園管理員日誌？您可能會在此找到有用的信息。 – Yann

嗨，我檢查了solr和zookeeper日誌，它抱怨套接字超時。我還運行了許多不同配置和分析的實驗，似乎GC啓動並暫停整個集羣 –