Запись на сервер, процессор занят на 20%

Elastic In Your Native Tongue Вопросы на русском языке
1

пытаюсь понять почему запись на сервер забирает 20% cpu сервера, это нормально?

_nodes/hot_threads ничего интересного не показали

сервер находится в google cloud

Hot threads at 2015-09-22T04:02:49.774Z, interval=500ms, busiestThreads=3, ignoreIdleThreads=true:

3.5% (17.5ms out of 500ms) cpu usage by thread 'elasticsearch[elasticsearch2-elasticsearch-1-vm][refresh][T#1]'
 2/10 snapshots sharing following 2 elements
   java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   java.lang.Thread.run(Thread.java:745)

какую еще информацию мне надо предоставить

2015-09-21.jpg2048×2048 1.1 MB

2

При записи происходит индексация данных, что является достаточно интенсивной с точки зрения CPU операцией. Сколько вы данных пишите в секунду? Пробуйте hot_threads 5 раз запустить с параметром threads=1000, залейте результаты в gist.github.com и пришлите сюда ссылку.

3

https://gist.github.com/maksymseleznov/4a9b6b5fa1bdc8089aac

я сделал несколько раз, вот такие результаты

4

Похоже, что elasticsearch сливает сегменты, и на это действительно уходит CPU и I/O. А что, это вызывает какие-то проблемы? Вы новые записи добавляете или старые обновляете?

5

У нас есть три таблицы , допустим A,B,C
в таблице "A" данных всегда больше чем в таблице "В" или "C" примерно в 10 раз.
В таблицу "A" в основном записываются новые данные с периодичностью примерно 1 новый документ в секунду-две
в таблице "А" могут происходить обновления документов - но тоже не очень часто

В таблицу "B" документы в основном обновляются с периодичностью 1 новая запись в секунду-две
Так же в таблицу "B" записываются новые документы , но это не очень часто: 1 новый документ в 30сек-60сек.

В таблицу "С" запись и обновление происходят намного реже чем в других таблицах

-------на данный момент:
A -- 2.5 М документов (590Mb)
B и С -- по 200к документов , B(300MB) C(250MB)
индексируем мы только те поля которые действительно нам нужны

Очень хочется понять в какую сторону стоит двигаться если все данные будут записываться/обновляться в 10-20 раз чаще?

Спасибо Вам за помощь!

6

А таблица это что в elasticsearch? Тип или индекс?

7

ну у нас есть три типа те
typeA/A
typeB/B
typeC/C

в каждом типе по одному индексу.

8

То есть у вас 3 индекса, и каждый индекс содержит только документы одного типа, так? А как refresh выполняется? Какие-нибудь установки меняли?

9

да именно так. настройки такие только :
@"settings" : @{
@"number_of_shards" : @(10)
},

мапинг кастумный для каждого типа документов
больше нечего не меняли

10

https://gist.github.com/maksymseleznov/94a23eabec19c089b706 - settings
https://gist.github.com/maksymseleznov/90df76cd94a952064b4f - mappings

не совсем понял что refresh что именно продразумевается?

каждый индекс содержит только одного типа документы

дополнителного ничего не делали, разве что отключили кибану

11

Это - Near Real-Time Search | Elasticsearch: The Definitive Guide [2.x] | Elastic

12

curl -XPOST http://localhost:9200/_refresh

{"_shards":{"total":60,"successful":30,"failed":0}}

я ничего не менял там по обновлению, все по умолчанию

Вы видели я выложил?
https://gist.github.com/maksymseleznov/94a23eabec19c089b706 - settings
https://gist.github.com/maksymseleznov/90df76cd94a952064b4f - mappings

13

Видел. Никаких очевидных проблем не заметил, кроме того, что у вас несколько больших полей not_analyzed (bio например), что само по себе странно и может привезти к проблемам.

Я бы посоветовал протестировать систему под реальной нагрузкой. Я думаю, что предполагать, что увеличение потока документов в 10 раз увеличит нагрузку на CPU в 10 раз в вашем случае не верно.

14

Немного не понятно что не так с "not_analyzed" это же не что иное как "не индексировать" , или я просто что-то не правильно понял

*поля био нам просто не нужно и не понадобится для индексации.

15

Немного не понятно что не так с "not_analyzed" это же не
что иное как "не индексировать" , или я просто что-то не правильно понял

Не совсем, если не надо индексировать поле совсем (по полю нельзя искать), то надо выставлять "index: no", а "not_analyzed" - индексируем "как есть", сохраняя возможность поиска (см. линк)