2015-04-24 56 views
2

我創建了一個用於記錄的索引。Elasticsearch批量索引創建大量磁盤讀取OPS

這意味着主要有寫入,有時搜索一次。 在第一次加載的階段,我使用多個客戶端使用批量API同時索引文檔。

首先,大量的5000個文檔的索引需要200毫秒。 隨着時間的推移,索引時間增加,並達到1000-4500毫秒。

我使用的是具有32個內核和60 GB內存的EC2 c3.8xl機器,IO預配置卷設置爲7000 IOPS。

我有10個碎片,沒有副本,都在同一臺機器上。 ATM,索引中有15億條記錄。

縱觀指標,我看到,CPU和內存都很好,寫入IOPS爲300,但讀取IOPS也慢慢消失了起來,到了7000

爲什麼我只是索引,但大部分IOPS都被讀取?

我的設置是:

threadpool.bulk.type: fixed 
threadpool.bulk.size: 32     # availableProcessors 
threadpool.bulk.queue_size: 1000 

# Indices settings 
indices.memory.index_buffer_size: 50% 

indices.cache.filter.expire: 6h 

bootstrap.mlockall: true 

,我已經更改索引設置:

{"index":{"refresh_interval":"60m", 
    "translog": 
     {"flush_threshold_size":"1gb", 
     "flush_threshold_ops":"50000"} 
    } 
} 

我也試過 「refresh_interval」: 「 - 1」

請讓我知道如果需要我還需要提供什麼(設置,日誌,指標)。以下是節點統計:

"_all": { 

    "primaries": { 
     "docs": { 
      "count": 1473959582, 
      "deleted": 1376161 
     }, 
     "store": { 
      "size_in_bytes": 497545621011, 
      "throttle_time_in_millis": 102780138 
     }, 
     "indexing": { 
      "index_total": 416653525, 
      "index_time_in_millis": 679407284, 
      "index_current": 0, 
      "delete_total": 0, 
      "delete_time_in_millis": 0, 
      "delete_current": 0, 
      "noop_update_total": 1, 
      "is_throttled": false, 
      "throttle_time_in_millis": 0 
     }, 
     "get": { 
      "total": 2943640, 
      "time_in_millis": 15160148, 
      "exists_total": 1445558, 
      "exists_time_in_millis": 7460238, 
      "missing_total": 1498082, 
      "missing_time_in_millis": 7699910, 
      "current": 0 
     }, 
     "search": { 
      "open_contexts": 0, 
      "query_total": 70, 
      "query_time_in_millis": 12238, 
      "query_current": 0, 
      "fetch_total": 2, 
      "fetch_time_in_millis": 23, 
      "fetch_current": 0 
     }, 
     "merges": { 
      "current": 0, 
      "current_docs": 0, 
      "current_size_in_bytes": 0, 
      "total": 4184, 
      "total_time_in_millis": 128875711, 
      "total_docs": 1282672895, 
      "total_size_in_bytes": 429203874419 
     }, 
     "refresh": { 
      "total": 1930, 
      "total_time_in_millis": 1816632 
     }, 
     "flush": { 
      "total": 7774, 
      "total_time_in_millis": 4783754 
     }, 
     "warmer": { 
      "current": 0, 
      "total": 23565, 
      "total_time_in_millis": 1792 
     }, 
     "filter_cache": { 
      "memory_size_in_bytes": 184938864, 
      "evictions": 0 
     }, 
     "id_cache": { 
      "memory_size_in_bytes": 0 
     }, 
     "fielddata": { 
      "memory_size_in_bytes": 0, 
      "evictions": 0 
     }, 
     "percolate": { 
      "total": 0, 
      "time_in_millis": 0, 
      "current": 0, 
      "memory_size_in_bytes": -1, 
      "memory_size": "-1b", 
      "queries": 0 
     }, 
     "completion": { 
      "size_in_bytes": 0 
     }, 
     "segments": { 
      "count": 368, 
      "memory_in_bytes": 877782264, 
      "index_writer_memory_in_bytes": 23671280, 
      "index_writer_max_memory_in_bytes": 5368709120, 
      "version_map_memory_in_bytes": 19674480, 
      "fixed_bit_set_memory_in_bytes": 0 
     }, 
     "translog": { 
      "operations": 213819, 
      "size_in_bytes": 19598986 
     }, 
     "suggest": { 
      "total": 0, 
      "time_in_millis": 0, 
      "current": 0 
     }, 
     "query_cache": { 
      "memory_size_in_bytes": 0, 
      "evictions": 0, 
      "hit_count": 0, 
      "miss_count": 0 
     }, 
     "recovery": { 
      "current_as_source": 0, 
      "current_as_target": 0, 
      "throttle_time_in_millis": 0 
     } 
    } 

回答

0

當你索引它去尋找那些ID知道是否需要爲已刪除標記的文檔的舊版本的文檔。隨着指數的增長,細分市場的數量自然也會增加。因此,ES必須執行更多的查找來找到給定的ID。我懷疑如果您對索引進行了優化,您會看到磁盤讀取次數減少,至少在一段時間內會減少。

您可能需要調整合並策略,以便在插入文檔時更合理地合併段的數量,或在非高峯時段安排優化。

更新:作爲一個後來的想法,單個節點上的單個索引的10個分片似乎是矯枉過正的。除非您已經測試過其他配置,或者計劃添加更多noes,否則我會建議您放棄這些配置。也許低至1或2.