содержание

Фоновое введение

Обзор знаний JVM

Обзор примечаний к конфигурации ES

Анализ ситуации

Практика настройки

Резюме и перспективы

1. Введение

Служба в проекте интегрирует springboot-admin для мониторинга службы.В последнее время я получаю оповещения по электронной почте, указывающие на то, что es неверен. Сообщение об ошибке выглядит следующим образом:

org.elasticsearch.ElasticsearchTimeoutException: java.util.concurrent.TimeoutException: Timeout waiting for task.

Я часто получаю это оповещение, поэтому я решил понять время, чтобы посмотреть в него. Из сообщения об ошибке одновременный тайм-аут ненормально. ES - промежуточное программное обеспечение, разработанное Java. Мы не модифицировали какой-либо код, поэтому мы начали пытаться решить его от JVM, а также привлекли некоторые знания о ES и Springboot.

2. Обзор знаний JVM

Вы можете обратиться к другой учебной заметке:Глубокое понимание виртуальной машины Java

1. Модель памяти JVM

Объект JVM gc: куча

2. куча памяти

2.1 Разделение кучи памяти

Область кучи делится на молодое поколение и старое поколение
Новое поколение разделено на зону Эдема, от зоны выжившего до зоны выжившего.
Зона Эдема и две меньшие области выживших. Соотношение размеров 8:1:1
Java8 не имеет постоянной генерации, и она изменена на область метаданных, которая в основном хранит метаданные, такие как метаданные класса и метода, которые имеют мало общего с объектами Java, которые должны быть восстановлены сборкой мусора.

2.2 Представление динамической памяти

Используйте команду jstat -gc (-gccapacity, -gcutil) для просмотра распределения кучи.

S0C: Общий объем памяти областиSurvivor0 (Емкость)
S1C: общий объем памяти области Survivor1
S0U: Текущий объем памяти областиSurvivor0 (используется)
S1U: Текущий объем памяти области Survivor1
EC: общий объем памяти области Eden
ЕС: Текущий размер памяти области Эдема
OC: общий объем памяти старого поколения
OU: Текущий объем памяти старого поколения
MC: общий объем памяти области метаданных
MU: Текущий размер памяти области метаданных

2.3 Стратегии распределения и утилизации памяти

2.3.1 Стратегия распределения

Когда создается большинство объектов, они размещаются в области Эдема.
Большие объекты непосредственно в старую эру, такие как длинные строки или массивы. Эти объекты для мусора сбора недружелюбны.
Объекты-долгожители будут продвигаться от молодого поколения к старому поколению

2.3.2 Стратегия переработки

Область eden заполнена: срабатывает минорный gc, и уцелевшие объекты копируются на один из уцелевших. Возраст субъекта +1
Выжившая область полна: те, кто встречает условия продвижения, войдет в старость. Если не удовлетворены, скопируйте на другую живущую область

2.3.3 Оценка условий акции

Serial и ParNew GC задаются параметром MaxTenuringThreshold, по умолчанию 15
Параллельный коллектор автоматически регулируется для возраста: выжившее пространство того же возраста, превышающего половину размера всех объектов в пространстве, больше или равна цели непосредственно в старости лет.

2.3. Мысли о разбиении кучи

2.3.1 Влияние программ с большой и малой кучей

Куча слишком велика: время STW при сборке мусора слишком велико, что влияет на время отклика программы. Говорят, что сборщик ZGC (выпуск java11) может решить эту проблему.Введение в ZGC в java11
Куча слишком мала: слишком частая сборка мусора

2.3.2 Почему он разделен на разные возрасты

Жизненный цикл каждого объекта разный, объекты с разным временем выживания делятся на разные области, а затем используются разные алгоритмы сборки мусора.
Многие объекты в java умирают, и эти объекты не войдут в старость.

2.3.3 Почему существует зона выживания

Если области выживших нет, а есть только область Эдема, каждый раз, когда выполняется минорный gc, объект отправляется на старость. Легко запустить полный сборщик мусора и повлиять на производительность.
Цель Survivor — уменьшить количество объектов, отправляемых в старость, и уменьшить возникновение полного gc.

2.3.4 Зачем создавать две зоны выживания

Каждый раз при минорном GC копируйте Eden и Survivor в другой Survivor, избегайте проблем с фрагментацией

3. Алгоритм сборки мусора

3.1 Алгоритм маркировки-развертки

Самый простой алгоритм сбора
Делится на два этапа маркировки и очистки
Недостатки:
- Вопросы эффективности
- Генерирует большое количество прерывистых фрагментов памяти

3.2 Алгоритм репликации

Разделите память на два куска одинакового размера и используйте один за раз
Когда блок израсходован, скопируйте уцелевшие объекты в другой блок.
Этот алгоритм используется современными виртуальными машинами нового поколения.
недостаточный:
- низкое использование памяти

3.3 Алгоритмы маркировки-сопоставления

Когда уровень выживаемости объекта высока, большое количество копий повлияет на эффективность, а старое поколение использует этот алгоритм
Процесс маркировки аналогичен алгоритму маркировки-развертки.
Следующим шагом будет не чистка объектов, а перемещение всех уцелевших объектов в сегмент для очистки памяти за границей

3.4 Алгоритм сбора поколений

Периоды выживания разные объекты, разные алгоритмы сбора
Большое количество объектов нового поколения умирает, а небольшое количество выживает, используя алгоритм репликации
Выживаемость объектов в пожилом возрасте высока, и используется алгоритм «отметить-разметать» или «отметить-собрать».

4. Сборщик мусора

4.1 Возрастная категория

Есть коллекторы нового поколения: Serial, ParNew, Paraller Scavenge.
Есть старая ловушка: CMS Serial old, Parallel Old
Сборщик G1 работает с молодым и старым поколением
Два неподключенных коллектора не могут сосуществовать, например, CMS и Parallel Scavenge.

4.2 Отдел рабочего механизма

Последовательный сборщик: Serial, Serial Old, однопоточный сборщик, простой, простой в реализации и эффективный.
Параллельный сборщик: ParNew, многопоточная версия Serial, может полностью использовать ресурсы ЦП и сократить время перезапуска.
Коллектор с приоритетом пропускной способности: параллельная очистка
Параллельный сборщик: CMS (Concurrent Mark Sweep), предпочтительно меньшее время паузы, основанное на алгоритме «mark-sweep».

4.3 Другие инструкции

Java11 имеет новый коллектор ZGC, который более эффективен, чем G1 (все еще на экспериментальной стадии)
Java5 по умолчанию использует сборщик CMS, а сборщик по умолчанию Java9 заменен на G1.
Пользователь может указать, какой сборщик мусора использовать
Подробное введение в каждую ссылку на сборщик мусораГлубокое понимание виртуальной машины Java

4.4 Как работает CMS

Он не будет ждать, пока старое пространство не будет почти заполнено перед перезапуском (одновременно с пользовательскими потоками, оставляя память для пользовательских потоков). Параметр конфигурации — XX:CMSInitiazingOccupanyFraction. По умолчанию 75%
使用标记-清除算法。 Весь процесс делится на четыре этапа:
- Начальная маркировка: STW, маркировка объектов, с которыми могут быть связаны корни GC, очень быстро
- Параллельная маркировка: процесс отслеживания корней GC. кропотливый. Выполнить с пользовательским потоком (параллельно)
- Повторная маркировка: STW, маркировка объектов, метки которых изменены программой, работающей в процессе параллельной маркировки.Время больше, чем начальная маркировка, и намного меньше, чем параллельная маркировка.
- Параллельное оформление: отнимает много времени. Выполнить с пользовательским потоком (параллельно)

3. Инструкции по настройке ES Обзор

См. еще одно примечание:Заметки об исследовании Elasticsearch

В основном он знакомит с некоторыми моментами, которые специально объяснены в руководстве на официальном веб-сайте es.

1. Примечание по настройке

1.1 ES использовала сборщик мусора

По умолчанию используется CMS, а версию 2.x официально не рекомендуется модифицировать до G1.Ошибки в некоторых версиях JAVA G1 могут привести к повреждению файла сегмента Lucene.
Однако для 5.x и более поздних версий нет четких рекомендаций или не рекомендуется G1, по умолчанию или использовать CMS

1.2 Требования к распределению памяти ES

Не более 32G. Поскольку указатель каждого объекта становится длиннее, используется больше пропускной способности памяти ЦП, что означает, что вы фактически теряете больше памяти.
Не превышайте половину памяти, потому что Lucene также нуждается в памяти, и эта память не управляется JVM.
Если вам не нужно выполнять операции агрегирования при сегментации слов, память кучи можно уменьшить. Чем меньше память кучи, тем выше производительность Elasticsearch (быстрее GC) и Lucene (больше памяти для кэширования).

2. Примечания по поводу перезапуска

Обновляйте или обслуживайте каждый узел один за другим, обеспечивая непрерывную работу кластера.
Сначала прекратите индексировать новые данные

Размещение шардов запрещено. cluster.routing.allocation.enable" : "нет"

curl -XPUT http://{ip}:9200/_cluster/settings -d'
{
    "transient" : {
        "cluster.routing.allocation.enable" : "none"
    }
}'

Выключите один узел и выполните обновление обслуживания
Запустите узел и подождите, чтобы присоединиться к кластеру

Перезапустите раздачу осколков. Cluster.Routing.allocation.enable ":" все "

curl -XPUT http://{ip}:9200/_cluster/settings -d'
{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}'

Повторите вышеуказанные шаги для других узлов.
Восстановление данных обновления индекса

4. Анализ текущей ситуации

1. Версия и аппаратное обеспечение

Java: 1.8.0_131
эластичный поиск: 5.5.1
кластер es: 4 узла данных
ОС: Centos7 24 ядра 128G
Сборщик мусора: старое поколение (CMS) + новое поколение (ParNew)

2. Текущее распределение кучи

Чтобы настроить JVM, важно сначала просмотреть память стека, есть несколько способов просмотра методов

2.1 jstat -gc Команда для просмотра распределения кучи

Статистика ES 2.2, информация о распределении кучи каждого узла

узел	общий размер кучи	Кайнозой	survivor	eden	старость	область метаданных
Узел А	32G	1.46G	0.146G	1.16G	30.5G	81M
Узел B.	32G	1.46G	0.146G	1.16G	30.5G	85M
Узел С	32G	1.46G	0.146G	1.16G	30.5G	81M
Узел D	20G	1.46G	0.146G	1.16G	18.5G	76M

3. Сравнение инструментов мониторинга

имя инструмента	Каждое подразделение	Данные интуитивно понятны	Просматривать ли исторические данные	Это бесплатно	Примечание
jstat	да	нет	нет	да	В основном используется для просмотра размера каждого раздела
ElasticHQ	нет	да	нет	да	В основном используется для просмотра общей информации
cerebro	нет	да	нет	да	В основном используется для просмотра общей информации
x-pack	нет	да	да	Один год пробный период	Соответствующие функции недоступны в течение пробного периода, а существующие функции не затрагиваются. Версия x-pack 6.3 имеет открытый исходный код, и последующие версии могут быть бесплатными.

Поскольку временная шкала, сообщающая об аномальной электронной почте, неопределенна, невозможно увидеть какое-либо время, глядя на панель монитора, есть все необходимые функции для просмотра исторических данных, поэтому x-pack является предпочтительным инструментом, который мы отслеживаем.
Функция мониторинга x-pack — только одна из них, но она действительно мощная и настоятельно рекомендуется! ! В то же время я с нетерпением жду, когда официальный ES сделает его бесплатным как можно скорее.
В интернете есть способ взломать x-pack.После декомпиляции jar-пакета модифицировать код,а потом запаковать обратно.Я пока не пробовал.

Резюме некоторых небольших проблем в процессе установки x-pack

Шаг 1: Заявка на получение сертификата

register.elastic.co/marvel_reg я…
После заполнения информации получите файл JSON, импортированный в ES, действительный в течение одного года.

curl -XPUT 'http://{ip}:9200/_xpack/license?acknowledge=true' -H "Content-Type: application/json" -d @sivabalan-nagarajan-2327c0fa-f56b-443a-a3d6-abef7ecf2220-v5.json

Шаг 2. Установите плагин x-pack, включая es и kibana.

./bin/kibana-plugin install x-pack 安装很慢，先把文件下载下来，用下一个命令安装
./bin/elasticsearch-plugin install file:///home/breakpad/softs/x-pack-5.5.1.zip

Шаг 3: Измените файл конфигурации

В конфигурационном файле es включена только функция мониторинга

xpack.security.enabled: false
xpack.monitoring.enabled: true
xpack.graph.enabled: false
xpack.watcher.enabled: false

В конфигурационном файле kibana включена только функция мониторинга

xpack.security.enabled: false
xpack.monitoring.enabled: true
xpack.graph.enabled: false
xpack.reporting.enabled: false

Исправление проблем

После установки rpm сообщается о проблеме недостаточных разрешений при запуске kibana в режиме systemctl?

Удалите X-PACK, чтобы установить пользователей kibana Установочный файл Sudo -u kibana bin / kibana-plugin: ///usr/share/kibana/x-pack-5.5.1.zip
Или сообщите об ошибке разрешения, измените права доступа к файлу отчета об ошибке на kibana.
Разрешения на установочный пакет сообщают об ошибке, измените разрешения на установочный пакет в Kibana

Как решить проблему, которую веб-страница не может быть открыта после начала Kibana?

Конфигурация пути журнала в config/kibana.yml в: logging.dest: /var/log/kibana.log
Права доступа к журналу изменений коснитесь /var/log/kibana.log chown kibana: kibana /var/log/kibana.log
Журнал не ошибается, но браузер просто не открывается. В итоге я случайно сменил браузер и он оказался нормальным, а потом заново открыл тот, который раньше не открывалсяобновление браузера хромПосле этого его можно нормально открыть! !

4. Анализ ситуации с мониторингом x-pack (для примера возьмем Node B, цикл 7 дней)

На кривой примерно 24 точки за сутки, то есть рассчитываются данные за каждый час

4,1 gc раз: в среднем около 250 раз/ч

4.2 второстепенное время gc: в среднем 10000 мс/ч

4.3 Полный ГК: Оставшаясячатая куча: 4,2 г, дважды полный GC составляет 2,224 человека, 2,438, соответственно, соответственно

5. Наблюдения

Соотношение распределения между новым поколением и старым поколением неразумно, новое поколение слишком мало, а старое поколение слишком велико.
- Во многих статьях в Интернете указывается, что по умолчанию соотношение молодого поколения к старому составляет 1:2, но, по наблюдениям, это не так (около 1:20 на нашей машине).
- Конкретную причину можно найти только в такой статье в Интернете.Насколько велика CMS по умолчанию нового поколения?
- Грубо: берем значение, рассчитанное по умолчанию NewRatio и сравниваем его со значением, рассчитанным по другой формуле, и берем меньшее
- Формула расчета такова: количество ядер компьютера * определенный параметр (64M) * 13/10. Значение, рассчитанное нашей машиной, равно 2G, что едва ли соответствует этому утверждению.
Кайнозойский сбор мусора является частым явлением.
После сбора старости: эффективная память составляет всего около 4G (активные данные)

6. Предварительный анализ и разрешение наблюдаемых явлений

Новое поколение слишком маленькое: мини-GC часто перезапускается, и размер нового поколения можно соответствующим образом увеличить.
Старость слишком велика: время восстановления основного или полного gc слишком велико, и размер старости можно соответствующим образом уменьшить.
Как определить размер нового поколения старого поколения: поПрактика оптимизации Meituan gcВ статье говорится:
- Общий размер: в 3-4 раза больше активного размера данных:
  - Узел B — 4,2G*4, мы установили его на 20G.
  - Другие машины имеют около 3,6 ГБ * 4, мы установили его на 16 ГБ.
- Молодое поколение: 1-1,5 раза больше активных данных
- Старое поколение: Общий размер - Молодое поколение. Подводя итог, мы устанавливаем новое поколение: старое поколение = 1:4

5. Настройка реального боя

С помощью приведенного выше анализа обнаруженных проблем попробуйте настроить параметры и понаблюдайте за скорректированными результатами мониторинга, чтобы убедиться, что наше предположение верно.

1. Изменить параметры конфигурации

Файл {es_home}/config/jvm.options

2. Изменены параметры конфигурации кучи

узел	общий размер кучи	Кайнозой	survivor	eden	старость	область метаданных
Узел А	16G	3.2G	320M	2.56G	12.8G	77M
узел B	20G	4G	400M	3.2G	16G	66M
Узел С	16G	3.2G	320M	2.56G	12.8G	77M
Узел D	16G	3.2G	320M	2.56G	12.8G	77M

3. Измененная информация мониторинга

3.1 Общее количество gc имеет тенденцию к снижению

3.2 Общее время сборки мусора имеет тенденцию к снижению, и полное время сборки мусора составляет около 900 мс.

4. Настройка параметров спрингбута

После настройки параметров JVM обнаружено, что время от времени по-прежнему возникают аварийные сигналы. Итак, я изучил принцип работы springboot-admin, который инкапсулирован на базе springboot-actuator, а затем посмотрел принцип работы springboot-actuator и нашел один из очень важных параметров:
```
management.health.elasticsearch.response-timeout
```
Этот параметр указывает, что программа мониторинга отправляет пульс в кластер es. Каково максимально допустимое время отклика? Если вы сообразительны, то должны понимать, что если JVM ES выполняет сборку мусора при отправке пульса, а STW вызывает задержку ответа, вы получите оповещение по электронной почте. Его значение по умолчанию — 100 мс, поэтому это значение должно быть установлено как минимум длиннее, чем минор gc.
Однако, если JVM выполняет полный gc при отправке пульса, поскольку время STW обычно велико, вы обязательно получите электронное письмо с предупреждением, если только вы не установите значение времени ожидания ответа больше, чем полное время gc.
Таким образом, необходимо установить разумное значение для этого значения в соответствии со временем сборки мусора.

6. Резюме и перспективы

1. Итоговая сводка по оптимизации

1.1 Настройка JVM

Уменьшите размер кучи, выделенной JVM узлами ES.
Отрегулируйте соотношение молодого поколения и старшего поколения

1.2 Тур по Springboot

Увеличьте время отклика springboot-actuator для проверки работоспособности Elasticsearch (по умолчанию 100 мс).

2. Перспективы

Оптимизация бизнеса: эта оптимизация настраивает параметры только с точки зрения JVM.Официальная документация es на самом деле дает много методов для эффективного использования es. Последующую оптимизацию можно проанализировать с точки зрения бизнеса, в том числе:
- Многие поля, не требующие сегментации слов, не настраиваются, и сегментация слов выполняется по умолчанию. Особенно влияет на производительность.
- Многие запросы не используют фильтр, а используют запрос. Не удалось кэшировать.
В то же время я рассчитываю на то, что ZGC будет запущен в использование в будущем.В то же время ES очень совместим с ZGC, и, возможно, на тот момент не требуется никакой настройки (независимо от того, насколько велика куча, gc время находится в пределах 10 мс).

VII. Справка

"Глубокое понимание виртуальной машины Java"
Полное руководство по поиску эластичных материалов
Практика оптимизации Meituan gc