Question

我已经创建了一个用于记录的索引。

这意味着大多数都是写入，有些则偶尔进行一些搜索。在第一次加载阶段，我使用多个客户端使用批量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"}
    }
}

我也试过＆＃34; refresh_interval＆＃34;：＆＃34; -1＆＃34;

如果需要，请告诉我还需要提供的其他信息（设置，日志，指标）。以下是节点统计信息：

"_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
        }
    }

Answer 1

索引文档时，必须查找该ID以了解是否需要将旧版本的文档标记为已删除。随着您的指数增长，细分数量自然也会增加。因此，ES必须执行更多寻找以查找给定ID。我怀疑如果您对索引进行了优化，您会看到磁盘读取次数减少，至少会持续一段时间。

您可能必须调整合并策略，以便在插入文档时更加agressivly合并段数，或在非高峰时段安排优化。

更新：作为一个想法，单个节点上单个索引的10个分片似乎有点过分。除非你已经测试了其他配置或计划添加更多噪音，否则我建议放弃它;也许低至1或2。

Elasticsearch Bulk索引会创建大量磁盘读取OPS

1 个答案: