ElasticSearch使用問題及解決方案匯總
Elasticsearch是一個開源的分布式實時搜索與分析引擎，支持云服務。它是基于Apache Lucene搜索引擎的類庫創建的，提供了全文搜索能力、多語言支持、專門的查詢語言、支持地理位置服務、基于上下文的搜索建議、自動完成以及搜索片段(snippet)的能力。Elasticsearch支持RESTful的API，可以使用JSON通過HTTP調用它的各種功能，包括搜索、分析與監控。此外，它還為Java、PHP、Perl、Python以及Ruby等各種語言提供了原生的客戶端類庫。下面是總結了一下使用 elasticsearch所遇到的各類問題以及相關的解決方案。
1、out of memory錯誤問題
因為默認情況下es對字段數據緩存(Field Data Cache)大小是無限制的，查詢時會把字段值放到內存，特別是facet查詢，對內存要求非常高，它會把結果都放在內存，然后進行排序等操作，一直使用內存，直到內存用完，當內存不夠用時就有可能出現out of memory錯誤。
解決方法：
(1)設置es的緩存類型為Soft Reference，它的主要特點是據有較強的引用功能。只有當內存不夠的時候，才進行回收這類內存，因此在內存足夠的時候，它們通常不被回收。另外，這些引 用對象還能保證在Java拋出OutOfMemory 異常之前，被設置為null。它可以用于實現一些常用圖片的緩存，實現Cache的功能，保證最大限度的使用內存而不引起OutOfMemory。在es 的配置文件加上index.cache.field.type: soft即可。
(2)設置es最大緩存數據條數和緩存失效時間，通過設置index.cache.field.max_size: 50000來把緩存field的最大值設置為50000，設置index.cache.field.expire: 10m把過期時間設置成10分鐘。
2、拋出異常，錯誤如下：
- 1org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream
原因：es節點之間的JDK版本不一樣
解決方式：統一JDK版本和環境
3、拋出異常，錯誤如下：
- org.elasticsearch.client.transport.NoNodeAvailableException: No node available
(1)端口錯誤
client = new TransportClient().addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));
端口9300寫成9200的報錯No node available 或者查看連接的是不是本地計算機，如果是遠程的話查看一下IP地址是否正確。
(2)jar包報錯誤的話可能是引用包不匹配，開啟的服務是什么版本最好對應相應的jar包。
(3)修改了集群名稱，設置了集群名字導致出現問題，設置操作如下：
- Settings settings = ImmutableSettings.settingsBuilder().put("cluster.name", "yoodb").build();
- client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));
(4)集群超過5s沒有響應，解決方式如下：
1)設置client.transport.ping_timeout超時時間，增大一些
2)代碼內嵌入，如下：
- while (true) {
- try {
- bulk.execute().actionGet(getRetryTimeout());
- break;
- } catch (NoNodeAvailableException cont) {
- Thread.sleep(5000);
- continue;
- }
- }
4、由gc引起節點脫離集群
因為gc時會使jvm停止工作，如果某個節點gc時間過長，master ping3次(zen discovery默認ping失敗重試3次)不通后就會把該節點剔除出集群，從而導致索引進行重新分配。解決方法如下：
(1)優化gc，減少gc時間。
(2)調大zen discovery的重試次數(es參數：ping_retries)和超時時間(es參數：ping_timeout)。后來發現根本原因是有個節點的系統所在硬盤滿了。導致系統性能下降。
#p#
5、無法創建本地線程問題
es恢復時報錯，如下：
- RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]
剛開始以為是文件句柄數限制，但想到之前報的是too many open file這個錯誤，并且也把數據改大了。查資料得知一個進程的jvm進程的最大線程數為：虛擬內存/(堆棧大小*1024*1024)，也就是說虛擬內存越大或堆棧越小，能創建的線程越多。重新設置后還是會報那這錯，按理說可創建線程數完全夠用了的，就想是不是系統的一些限制。后來在網上找到說是max user processes的問題，這個值默認是1024，這個參數單看名字是用戶最大打開的進程數，但看官方說明，就是用戶最多可創建線程數，因為一個進程最少有一個線程，所以間接影響到最大進程數。調大這個參數后就沒有報這個錯了。
解決方法：
(1)增大jvm的heap內存或降低xss堆棧大小(默認的是512K)。
(2)打開/etc/security/limits.d/90-nproc.conf，把soft nproc 1024這行的1024改大就行了。
6、集群狀態為黃色時并發插入數據報錯，錯誤如下：
- [7]: index [index], type [index], id [1569133], message [UnavailableShardsException[[index][1] [4] shardIt, [2] active : Timeout waiting for [1m], request: org.elasticsearch.action.bulk.BulkShardRequest@5989fa07]]
這是錯誤信息，當時集群狀態為黃色，即副本沒有分配。當時副本設置為2，只有一個節點，當你設置的副本大于可分配的機器時，此時如果你插入數據就有可能報上面的錯，因為es的寫一致性默認是使用quorum，即quorum值必須大于(副本數/2+1)，我這里2/2+1=2也就是說要要至少插入到兩份索引中，由于只有一個節點，quorum等于1，所以只插入到主索引，副本找不到從而報上面那個錯。
解決方法：(1)去掉沒分配的副本。(2)把寫一致性改成one，即只寫入一份索引就行。
7、錯誤使用api導致集群卡死
其實這個是很低級的錯誤。功能就是更新一些數據，可能會對一些數據進行刪除，但刪除時同事使用了deleteByQuery這個接口，通過構造 BoolQuery把要刪除數據的id傳進去，查出這些數據刪除。但問題是BoolQuery最多只支持1024個條件，100個條件都已經很多了，所以這樣的查詢一下子就把es集群卡死了。
解決方法：用bulkRequest進行批量刪除操作。
8、設置jvm鎖住內存時啟動警告
當設置bootstrap.mlockall: true時，啟動es報警告Unknown mlockall error 0，因為linux系統默認能讓進程鎖住的內存為45k。
解決方法：設置為無限制，linux命令：ulimit -l unlimited
