Вообщем переодически сервер дохнет по: The WebLogic Server encountered a critical failure java.lang.OutOfMemoryError: Metaspace Reason: There is a panic condition in the server. The server is configured to exit on panic И хотя это гавно пишет типа Reason: There is a panic condition in the server. The server is configured to exit on panic чёт ни хуя он ни куда не exit.... Вообщем т.к разбираться с тем чем он жрётся нет ни времени ни желания (оно обязательно появится)... как вариант можно приделать костыль... костыль будет заключаться в ребуте сервера при возникновении этой ошибки. Что значит для этого надо... Желания и понимание что так жить нельзя, и вообще... Делаем новый модуль называем скажем: Reboot-OOMMetaSpace Идём в в новый модуль делаем Policy: Называем его OOM-Metaspace и говорит что это Server log: Жмём next в Configuration Policy пишем: log.logMessage.contains('java.lang.OutOfMemoryError: Metaspace'...
Система:
[oracle@lal config]$ cat /proc/cpuinfo |grep -e processor -e "model name"
processor : 0
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 1
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 2
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 3
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
Оперативки: 12G
Настройки elasticsearch:
[oracle@lal config]$ cat elasticsearch.yml|grep -v '#\|^$'
cluster.name: cluster
node.name: "Node"
index.number_of_shards: 2
index.number_of_replicas: 0
index.merge.scheduler.max_thread_count: 1
index.refresh_interval: 30s
index.store.type: niofs
index.query.default_field: _type
path.data: /media/data/elasticsearch
path.work: /media/data/elasticsearch/tmp
path.logs: /media/data/elasticsearch/logs
bootstrap.mlockall: true
http.port: 9200
indices.recovery.max_bytes_per_sec: 100mb
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms
monitor.jvm.gc.young.warn: 1000ms
monitor.jvm.gc.young.info: 700ms
monitor.jvm.gc.young.debug: 400ms
monitor.jvm.gc.old.warn: 10s
monitor.jvm.gc.old.info: 5s
monitor.jvm.gc.old.debug: 2s
http.cors.enabled: true
http.cors.allow-origin: "/.*/"
threadpool.search.type: fixed
threadpool.search.size: 60
threadpool.search.queue_size: 4000
threadpool.bulk.type: fixed
threadpool.bulk.size: 30
threadpool.bulk.queue_size: 1000
threadpool.index.type: fixed
threadpool.index.size: 30
threadpool.index.queue_size: 4000
indices.fielddata.cache.size: 75%
indices.fielddata.cache.expire: 6h (Dont use this fucking shit!)
indices.cache.filter.size: 25%
indices.cache.filter.expire: 6h
indices.breaker.fielddata.limit: 85%
marvel.agent.enabled: false
marvel.agent.interval: -1
Параметры распишу когда будет не в падлу:
Итак есть такая картина
Соответственно есть индекс назовём его prod:
shards: 2 * 1 | docs: 141,685,097 | size: 119.49GB
Настройки slowlog для индекса:
curl -XPUT 'http://localhost:9200/prod/_settings' -d '{
"index.search.slowlog.threshold.query.warn" : "5s",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.indexing.slowlog.threshold.index.info": "5s"
}'
При запросе отчёта в kibana по индексу prod за 12h:
[2015-06-05 12:14:21,158][WARN ][index.search.slowlog.query] [Node] [prod][0] took[23.7s], took_millis[23738], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[2], source[{"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"*"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1433448855527,"to":1433492055527}}}]}}}},"highlight":{"fields":{},"fragment_size":2147483647,"pre_tags":["@start-highlight@"],"post_tags":["@end-highlight@"]},"size":500,"sort":[{"@timestamp":{"order":"desc","ignore_unmapped":true}}]}], extra_source[],
[2015-06-05 12:14:21,387][WARN ][index.search.slowlog.query] [Node] [prod][0] took[23.9s], took_millis[23973], types[], stats[], search_type[COUNT], total_shards[2], source[{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"5m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"*"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1433448855523,"to":1433492055523}}}]}}}}}}}},"size":0}], extra_source[],
Вообщем что бы решить эту херню надо читать доку на тему preload fielddata.
На самом деле при вызове обычной data histrogram по этому индексу в kibana можно увидеть загрузку проца максимум на 50%, iostat по диску тоже скажет что всё хорошо.
Дальнейшие поиски проблемы привели к еще одной ссылке:
https://www.elastic.co/guide/en/elasticsearch/guide/current/_monitoring_individual_nodes.html
Вообщем то нас интересует:
curl -XPUT 'http://localhost:9200/prod/_mapping/prod' -d '
{
"properties": {
"@timestamp": {
"format": "strict_date_optional_time||epoch_millis",
"type": "date",
"fielddata": {
"loading" : "eager"
}
}
}
}'
Можно сделать template если индекс создаётся с помощью logstash по дням например:
{
"order": 0,
"template": "testmap-*",
"settings": {
"index": {
"number_of_shards": "2",
"number_of_replicas": "0",
"refresh_interval": "5s"
}
},
"mappings": {
"prod": {
"properties": {
"@timestamp": {
"fielddata": {
"loading": "eager"
},
"format": "strict_date_optional_time||epoch_millis",
"type": "date"
}
}
}
},
"aliases": {}
}
P.S.
Вообще в идеале надо бы еще написать про
indices.fielddata.cache.size: 75%
indices.breaker.fielddata.limit: 85%
Но в падлу да и написано тута: http://evertrue.github.io/blog/2014/11/16/3-performance-tuning-tips-for-elasticsearch/
[oracle@lal config]$ cat /proc/cpuinfo |grep -e processor -e "model name"
processor : 0
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 1
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 2
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
processor : 3
model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
Оперативки: 12G
Настройки elasticsearch:
[oracle@lal config]$ cat elasticsearch.yml|grep -v '#\|^$'
cluster.name: cluster
node.name: "Node"
index.number_of_shards: 2
index.number_of_replicas: 0
index.merge.scheduler.max_thread_count: 1
index.refresh_interval: 30s
index.store.type: niofs
index.query.default_field: _type
path.data: /media/data/elasticsearch
path.work: /media/data/elasticsearch/tmp
path.logs: /media/data/elasticsearch/logs
bootstrap.mlockall: true
http.port: 9200
indices.recovery.max_bytes_per_sec: 100mb
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms
monitor.jvm.gc.young.warn: 1000ms
monitor.jvm.gc.young.info: 700ms
monitor.jvm.gc.young.debug: 400ms
monitor.jvm.gc.old.warn: 10s
monitor.jvm.gc.old.info: 5s
monitor.jvm.gc.old.debug: 2s
http.cors.enabled: true
http.cors.allow-origin: "/.*/"
threadpool.search.type: fixed
threadpool.search.size: 60
threadpool.search.queue_size: 4000
threadpool.bulk.type: fixed
threadpool.bulk.size: 30
threadpool.bulk.queue_size: 1000
threadpool.index.type: fixed
threadpool.index.size: 30
threadpool.index.queue_size: 4000
indices.fielddata.cache.size: 75%
indices.cache.filter.size: 25%
indices.breaker.fielddata.limit: 85%
marvel.agent.enabled: false
marvel.agent.interval: -1
Параметры распишу когда будет не в падлу:
Итак есть такая картина
Соответственно есть индекс назовём его prod:
shards: 2 * 1 | docs: 141,685,097 | size: 119.49GB
Настройки slowlog для индекса:
curl -XPUT 'http://localhost:9200/prod/_settings' -d '{
"index.search.slowlog.threshold.query.warn" : "5s",
"index.search.slowlog.threshold.fetch.debug": "500ms",
"index.indexing.slowlog.threshold.index.info": "5s"
}'
При запросе отчёта в kibana по индексу prod за 12h:
[2015-06-05 12:14:21,158][WARN ][index.search.slowlog.query] [Node] [prod][0] took[23.7s], took_millis[23738], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[2], source[{"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"*"}}]}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1433448855527,"to":1433492055527}}}]}}}},"highlight":{"fields":{},"fragment_size":2147483647,"pre_tags":["@start-highlight@"],"post_tags":["@end-highlight@"]},"size":500,"sort":[{"@timestamp":{"order":"desc","ignore_unmapped":true}}]}], extra_source[],
[2015-06-05 12:14:21,387][WARN ][index.search.slowlog.query] [Node] [prod][0] took[23.9s], took_millis[23973], types[], stats[], search_type[COUNT], total_shards[2], source[{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"5m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"*"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1433448855523,"to":1433492055523}}}]}}}}}}}},"size":0}], extra_source[],
Вообщем что бы решить эту херню надо читать доку на тему preload fielddata.
На самом деле при вызове обычной data histrogram по этому индексу в kibana можно увидеть загрузку проца максимум на 50%, iostat по диску тоже скажет что всё хорошо.
Дальнейшие поиски проблемы привели к еще одной ссылке:
https://www.elastic.co/guide/en/elasticsearch/guide/current/_monitoring_individual_nodes.html
Вообщем то нас интересует:
field_datadisplays the memory used by fielddata, which is used for aggregations, sorting, and more. There is also an eviction count. Unlikefilter_cache, the eviction count here is useful: it should be zero or very close. Since field data is not a cache, any eviction is costly and should be avoided. If you see evictions here, you need to reevaluate your memory situation, fielddata limits, queries, or all three.
Посмотрим как у нас с этим дела:
curl -XGET 'http://localhost:9200/_nodes/stats/indices/fielddata?pretty'
{
"cluster_name" : "cluster",
"nodes" : {
"8axrZeD1RBOo1W4H9puUgQ" : {
"timestamp" : 1441366280350,
"name" : "Node",
"transport_address" : "inet[/1.1.1.1:9300]",
"host" : "lalalal",
"ip" : [ "inet[/1.1.1.1:9300]", "NONE" ],
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 11280104,
"evictions" : 942334
}
}
},
"U9P_Jl2jQ0e2S3J9lJQfrw" : {
"timestamp" : 1441366280349,
"name" : "lalalal-24625-11310",
"transport_address" : "inet[/1.1.1.1:9301]",
"host" : "lalal",
"ip" : [ "inet[/1.1.1.1:9301]", "NONE" ],
"attributes" : {
"data" : "false",
"client" : "true"
},
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 0,
"evictions" : 0
}
}
}
}
}
тут 2 ноды, сам elastic и logstash, нас интересует первая.
Циферки я подправил по памяти т.к реальных данных не осталось.
Вообщем то тут видно что происходит много так называемых evictions (я так понимаю это что-то типа перезаписи этого кэша... хотя хуй его знает какой то дибильное слово).
Для того что бы нормализовать это поведение необходимо сделать 2 вещи (я блять уверен что 2!)
1. Eagerly load fielddata
Eager loading (as opposed to the default lazy loading). As new segments are created (by refreshing, flushing, or merging), fields with eager loading enabled will have their per-segment fielddata preloaded before the segment becomes visible to search.
Вообщем то делается это путём правки mapping`а существующего индекса:
curl -XPUT 'http://localhost:9200/prod/_mapping/prod' -d '
{
"properties": {
"@timestamp": {
"format": "strict_date_optional_time||epoch_millis",
"type": "date",
"fielddata": {
"loading" : "eager"
}
}
}
}'
В данном случае будем делать preload @timestamp ибо это поле используется для построения date histogram в kibana. Что и занимает наибольшее количество времени при построении отчёта.
Можно сделать template если индекс создаётся с помощью logstash по дням например:
{
"order": 0,
"template": "testmap-*",
"settings": {
"index": {
"number_of_shards": "2",
"number_of_replicas": "0",
"refresh_interval": "5s"
}
},
"mappings": {
"prod": {
"properties": {
"@timestamp": {
"fielddata": {
"loading": "eager"
},
"format": "strict_date_optional_time||epoch_millis",
"type": "date"
}
}
}
},
"aliases": {}
}
В принципе судя по доке этого достаточно, но всё таки я решил сделать еще одну вещь...
2. Index warmers
Warmers predate eager fielddata loading and eager global ordinals, but they still serve a purpose. An index warmer allows you to specify a query and aggregations that should be run before a new segment is made visible to search. The idea is to prepopulate, or warm, caches so your users never see a spike in latency.
Т.е можно указать запрос который будет выполняться перед тем как новые сегменты будут доступны для поиска (я блять понимаю это именно так!).
Я создавал warmers`ы через kopf. В качестве запроса я взял заспрос из slowlog , правда в качестве @timestamp указал "from": "now-3d", "to": "now" т.е:
{
"query" : {
"match_all" : {}
},
"facets": {
"0": {
"date_histogram": {
"field": "@timestamp",
"interval": "30m"
},
"global": true,
"facet_filter": {
"fquery": {
"query": {
"filtered": {
"query": {
"query_string": {
"query": "*"
}
},
"filter": {
"bool": {
"must": [
{
"range": {
"@timestamp": {
"from": "now-3d",
"to": "now"
}
}
}
]
}
}
}
}
}
}
}
},
"size": 0
}
Скажем сразу похоже как таковой этот запрос не работает.
Т.е если провести эксперемент типа:
1. Очищаем кэш индекса:
2. Ждём!!!
3. curl -XGET 'http://localhost:9200/_nodes/stats/indices/fielddata?pretty'
{
"cluster_name" : "cluster",
"nodes" : {
"8axrZeD1RBOo1W4H9puUgQ" : {
"timestamp" : 1441366280350,
"name" : "Node",
"transport_address" : "inet[/1.1.1.1:9300]",
"host" : "lalalal",
"ip" : [ "inet[/1.1.1.1:9300]", "NONE" ],
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 112104,
"evictions" : 0
}
}
},
"U9P_Jl2jQ0e2S3J9lJQfrw" : {
"timestamp" : 1441366280349,
"name" : "lalalal-24625-11310",
"transport_address" : "inet[/1.1.1.1:9301]",
"host" : "logstashcsm.gksm.local",
"ip" : [ "inet[/1.1.1.1:9301]", "NONE" ],
"attributes" : {
"data" : "false",
"client" : "true"
},
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 0,
"evictions" : 0
}
}
}
}
}
curl 'localhost:9200/_cat/thread_pool?v&h=id,host,port,pid,warmer.active,warmer.completed,warmer.rejected,warmer.max'
id host port pid warmer.active warmer.completed warmer.rejected warmer.max
U9P_ logstashcsm.gksm.local 9301 24625 0 0 0 2
8axr logstashcsm.gksm.local 9300 24967 0 7230 0 2
Как видно не закэшировалось ни хрена (возможно эти 112Kb это новые timestamp`ы), хотя warmer`ы выполнялись и продолжают выполняться. Хотя если бы этот запрос действительно выполнился то поидее memory_size_in_bytes был бы несколько сотен мегабайт.
Вообщем всех нас спасёт Eagerly load fielddata. Или для warmer надо указывать какий-то специфические запросы..
Пока что я разочаровался в warmers`ах похоже что они не работают( (или не работают так как я хочу=))
Result:
После всех этих действий и рестарта elasticsearch, картина улучшилась, отчёты в kibane грузятся в разы быстрее....:
curl -XGET 'http://localhost:9200/_nodes/stats/indices/fielddata?pretty'
{
"cluster_name" : "cluster",
"nodes" : {
"8axrZeD1RBOo1W4H9puUgQ" : {
"timestamp" : 1441366280350,
"name" : "Node",
"transport_address" : "inet[/1.1.1.1:9300]",
"host" : "lalalal",
"ip" : [ "inet[/1.1.1.1:9300]", "NONE" ],
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 1128963964,
"evictions" : 0
}
}
},
"U9P_Jl2jQ0e2S3J9lJQfrw" : {
"timestamp" : 1441366280349,
"name" : "lalalal-24625-11310",
"transport_address" : "inet[/1.1.1.1:9301]",
"host" : "lalal",
"ip" : [ "inet[/1.1.1.1:9301]", "NONE" ],
"attributes" : {
"data" : "false",
"client" : "true"
},
"indices" : {
"fielddata" : {
"memory_size_in_bytes" : 0,
"evictions" : 0
}
}
}
}
}
Slowlog:
[2015-09-04 15:48:05,831][TRACE][index.search.slowlog.query] [Node] [prod][1] took[1.5s], took_millis[1514], types[], stats[], search_type[COUNT], total_shards[2], source[{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"30m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"*"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1441198084264,"to":1441370884265}}}]}}}}}}}},"size":0}], extra_source[],
[2015-09-04 15:48:05,944][TRACE][index.search.slowlog.query] [Node] [prod][0] took[1.6s], took_millis[1626], types[], stats[], search_type[COUNT], total_shards[2], source[{"facets":{"0":{"date_histogram":{"field":"@timestamp","interval":"30m"},"global":true,"facet_filter":{"fquery":{"query":{"filtered":{"query":{"query_string":{"query":"*"}},"filter":{"bool":{"must":[{"range":{"@timestamp":{"from":1441198084264,"to":1441370884265}}}]}}}}}}}},"size":0}], extra_source[],
P.S.
Вообще в идеале надо бы еще написать про
indices.fielddata.cache.size: 75%
indices.breaker.fielddata.limit: 85%
Но в падлу да и написано тута: http://evertrue.github.io/blog/2014/11/16/3-performance-tuning-tips-for-elasticsearch/
Комментарии
Отправить комментарий