SearchContextMissingException Không thực thi được lấy giai đoạn [tìm kiếm/giai đoạn/lấy/id]

Question

---

Cluser: Tôi đang dùng elasticsearch 1.3.1 với 6 nút trong các máy chủ khác nhau, tất cả được kết nối với mạng LAN. Băng thông cao và mỗi băng thông có RAM 45 GB.

Cấu hình Kích thước Heap mà chúng tôi đã phân bổ cho nút chạy là 10g. Chúng tôi có cấu hình mặc định elasticsearch ngoại trừ discoverym duy nhất, tên cụm, tên nút và chúng tôi 2 khu vực. 3 nút thuộc về một khu vực và một thuộc về một khu vực khác.

chỉ số: 15, tổng kích thước của chỉ mục là 76GB.

Bây giờ, một ngày, tôi đang đối mặt với trường hợp ngoại lệ SearchContextMissingException dưới dạng nhật ký DEBUG. Nó có mùi giống như một số truy vấn tìm kiếm đã mất nhiều thời gian để tìm nạp. nhưng tôi đã kiểm tra với các truy vấn, không có truy vấn để tạo ra số lượng lớn tải cho cụm ... Tôi tự hỏi tại sao điều này xảy ra.

Sự cố: Do vấn đề này từng người một tất cả các nút bắt đầu thu thập GC. và dẫn đến việc oom :(

Đây là ngoại lệ của tôi. Xin vui lòng giải thích cho tôi 2 điều.

1. SearchContextMissingException? Tại sao nó xảy ra?
2. là gì Làm thế nào chúng ta có thể ngăn chặn các cụm từ các loại truy vấn

Các Lỗi:

[YYYY-MM-DD HH:mm:ss,039][DEBUG][action.search.type ] [es_node_01] [5031530] 
    Failed to execute fetch phase 
    org.elasticsearch.transport.RemoteTransportException: [es_node_02][inet[/1x.x.xx.xx:9300]][search/phase/fetch/id] 
    Caused by: org.elasticsearch.search.SearchContextMissingException: No search context found for id [5031530] 
     at org.elasticsearch.search.SearchService.findContext(SearchService.java:480) 
     at org.elasticsearch.search.SearchService.executeFetchPhase(SearchService.java:450) 
     at org.elasticsearch.search.action.SearchServiceTransportAction$SearchFetchByIdTransportHandler.messageReceived(SearchServiceTransportAction.java:793) 
     at org.elasticsearch.search.action.SearchServiceTransportAction$SearchFetchByIdTransportHandler.messageReceived(SearchServiceTransportAction.java:782) 
     at org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.run(MessageChannelHandler.java:275) 
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
     at java.lang.Thread.run(Thread.java:722) 

Answer 1

Nếu bạn có thể, cập nhật 1.4.2. Nó khắc phục một số vấn đề khả năng phục hồi đã biết, bao gồm cả các lỗi xếp tầng như bạn mô tả.

Bất kể điều đó, cấu hình mặc định chắc chắn sẽ khiến bạn gặp sự cố. Tối thiểu, bạn có thể cần xem xét thiết lập bộ ngắt mạch cho ví dụ: bộ đệm dữ liệu trường.

Đây là đoạn mã được tải lên từ cấu hình sản xuất của chúng tôi. Tôi giả sử bạn cũng đã cấu hình filehandles linux giới hạn một cách chính xác: see here

# prevent swapping 
bootstrap.mlockall: true 

indices.breaker.total.limit: 70% 
indices.fielddata.cache.size: 70% 

# make elasticsearch work harder to migrate/allocate indices on startup (we have a lot of shards due to logstash); default was 2 
cluster.routing.allocation.node_concurrent_recoveries: 8 

# enable cors 
http.cors.enabled: true 
http.cors.allow-origin: /https?:\/\/(localhost|kibana.*\.linko\.io)(:[0-9]+)?/ 

index.query.bool.max_clause_count: 4096 

Answer 2

Cùng lỗi (hoặc tuyên bố gỡ lỗi) vẫn xảy ra trong 1.6.0, và không phải là một lỗi.

Khi bạn tạo một yêu cầu cuộn mới:

SearchResponse scrollResponse = client.prepareSearch(index).setTypes(types).setSearchType(SearchType.SCAN) 
      .setScroll(new TimeValue(60000)).setSize(maxItemsPerScrollRequest).setQuery(ElasticSearchQueryBuilder.createMatchAllQuery()).execute().actionGet(); 
String scrollId = scrollResponse.getScrollId(); 

một cuộn id mới được tạo ra (ngoài các scrollId phản ứng là trống). Để tìm nạp kết quả:

long resultCounter = 0l; // to keep track of the number of results retrieved 
Long nResultsTotal = null; // total number of items we will be expecting 
do { 
    final SearchResponse response = client.prepareSearchScroll(scrollId).setScroll(new TimeValue(600000)).execute().actionGet(); 
    // handle result 
    if(nResultsTotal==null) // if not initialized 
     nResultsTotal = response.getHits().getTotalHits(); //set total number of Documents 
    resultCounter += response.getHits().getHits().length; //keep track of the items retrieved 
} while (resultCounter < nResultsTotal); 

Cách tiếp cận này hoạt động bất kể số lượng phân đoạn bạn có. Một lựa chọn khác là thêm một lệnh break khi:

boolean breakIf = response.getHits().getHits().length < (nShards * maxItemsPerScrollRequest); 

Số lượng các mục để được trả lại là maxItemsPerScrollRequest (mỗi mảnh vỡ!), vì vậy chúng tôi mong đợi các số hạng mục đã yêu cầu nhân với số phân đoạn.Nhưng khi chúng ta có nhiều mảnh vỡ, và một trong số đó không có tài liệu, trong khi một số khác thì không, thì phương pháp cũ sẽ vẫn cung cấp cho chúng ta tất cả các tài liệu có sẵn. Cách khác sẽ ngừng sớm - Tôi mong đợi (chưa thử!)

Một cách khác để ngừng xem ngoại lệ này (vì nó là 'chỉ' DEBUG), là mở tệp logging.yml trong thư mục config của ElasticSearch, sau đó thay đổi:

action: DEBUG 

để

action: INFO