Не завидуйте мандаринкам или бессмертным, а корректируйте строчку кода долго. Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.
Широко используется ES, особенно ELKB, который используется практически всеми системами логирования по бальной шкале.
Журналы относятся к бизнес-сценарию больше писать и меньше читать, и предъявляют высокие требования к скорости записи. Возьмите один из наших кластеров в качестве примера, объем журнала одного кластера достигает 100 ТБ, а объем записи журнала в секунду достигает 100 ТБ.10W
полоска.
ES — это не простая последовательная запись.Чтобы построить инвертированный индекс и обеспечить надежность и производительность данных в реальном времени, за ним стоит множество трудоемких слияний или дополнительных операций, а также нагрузка на дисковый ввод-вывод и ЦП. очень большой!
Используя iotop для наблюдения, можно обнаружить, что процесс ES почти занимает ресурсы ввода-вывода SSD-диска, достигая200MB/s+
. Используя команду top для наблюдения, обнаруживается, что пользователи 8-ядерного ЦП почти заполнены. ES очень ресурсоемкий.
Поскольку найти узкое место системы несложно, следует сосредоточиться на оптимизации этого ресурса и выжимать скорость записи ES до предела.
Пример версии этой оптимизации:7.9.2
. Версия ES поднялась очень быстро, и она полностью выпала из эпохи 5.
1. Какие операции занимают ресурсы
Для оптимизации нужно сначала узнать процесс написания ЭП и понять, какие этапы отнимают больше всего времени.
Во-первых, это проблема реплик, чтобы обеспечить хотя бы высокую доступность, количество реплик здесь установлено равным 1, что не может быть сохранено. Поэтому установка количества копий на 0 подходит только при первом импорте данных.
Как показано на рисунке выше, часть данных должна пройти несколько этапов, прежде чем она наконец попадет в сеть. В этом процессе даже будет механизм резервного копирования, такой как tranlog.
Базовым хранилищем ES является Lucene, который содержит ряд инвертированных индексов. Такой индекс становится段
(сегмент). Но записи записываются не напрямую в сегмент, а сначала в буфер.
Когда буфер заполнен или остается в буфере достаточно долго, чтобы достичь времени обновления (ключевой момент), содержимое буфера будет записано в сегмент за один раз.
Вот почемуrefresh_interval
Конфигурация свойств может серьезно повлиять на производительность. Если вам не нужна высокая производительность в реальном времени, вы также можете настроить ее на большее значение.
По умолчанию буфер использует 10% пространства кучи с минимальным значением 48 МБ (для осколков). Если у вас много индексов и интенсивная запись, использование памяти в этой части является значительным и может быть соответствующим образом увеличено.
2. Начать оптимизацию
Существует три основных действия для записи данных:flush
,refresh
иmerge
. Настраивая их поведение, можно найти компромисс между производительностью и надежностью данных.
flush
Из приведенного выше введения видно, чтоtranslog
Записывается полный объем данных, что немного похоже на binlog в MySQL или aof в redis, который используется для обеспечения безопасности данных в нештатных ситуациях.
Это связано с тем, что после записи данных на диск нам нужно вызвать fsync для сброса данных на диск.Если мы этого не сделаем, данные будут потеряны при выключении системы.
ES по умолчанию сбрасывает каждый запрос, но для логов это не обязательно.Этот процесс можно изменить на асинхронный.Параметры следующие:
curl -H "Content-Type: application/json" -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{
"index.translog.durability" : "async",
"index.translog.flush_threshold_size" : "512mb",
"index.translog.sync_interval" : "60s"
}'
Это, пожалуй, самый важный шаг оптимизации, который оказывает наибольшее влияние на производительность, но в крайних случаях существует вероятность потери некоторых данных. Для системы регистрации это терпимо.
refresh
Помимо записи транслогов, ES также записывает данные в буфер. Но будьте осторожны! В этот момент содержимое буфера не может быть просмотрено, и его необходимо записать в сегмент.
Это действие обновления, значение по умолчанию — 1 секунда. То есть данные, которые вы пишете, будут искать с большой вероятностью в 1 секунду.
Так что ES — это не система поиска в реальном времени, это система почти в реальном времени.
пройти черезindex.refresh_interval
Этот интервал обновления можно изменить.
Для лог-системы, конечно, он должен быть больше. xjjdog здесь настроен на 120 секунд, уменьшая частоту этих попаданий на сегмент, и скорость, естественно, будет выше.
curl -H "Content-Type: application/json" -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{
"index.refresh_interval" : "120s"
}'
merge
На самом деле слияние — это механизм Lucene, который в основном объединяет небольшие блоки сегментов для создания более крупных сегментов для повышения скорости поиска.
Причина в том, что в процессе обновления будет создано множество небольших файлов сегментов, а удаление данных также вызовет фрагментацию пространства. Таким образом, слияние, с точки зрения непрофессионала, похоже на процесс дефрагментации. Подобно postgresql и т. д., существуют вакуумные процессы, делающие то же самое.
Очевидно, что эта операция сортировки требует не только затрат на ввод-вывод, но и затрат ЦП.
Важно отметить, что слияние имеет три стратегии.
- tieredПараметр по умолчанию, который объединяет сегменты индекса одинакового размера с учетом максимального количества сегментов индекса, разрешенного для каждого слоя.
- log_byte_sizeВыберите несколько индексов для объединения, чтобы создать новый индекс, измеряемый в логарифмических байтах.
- log_docИспользуя количество документов в индексном сегменте в качестве расчетной единицы, выберите несколько индексов для объединения, чтобы создать новый индекс.
Каждая стратегия имеет очень подробную таргетированную настройку, поэтому я не буду здесь вдаваться в подробности.
Поскольку в лог-системе нет операций случайного удаления, можно оставить значение по умолчанию.
3. Тонкая настройка
В новой версии оптимизирована конфигурация пула потоков, и не требуется настраивать сложные пулы потоков поиска, массового и индексного потоков. Достаточно настроить следующее: thread_pool.get.size, thread_pool.write.size, thread_pool.listener.size, thread_pool.analyze.size. конкретный наблюдаемый_cat/thread_pool
Данные, предоставляемые интерфейсом, корректируются.
На самом деле его можно распределить, настроив несколько дисков.I/O
давление, но легко заставить горячие точки данных сконцентрироваться на одном диске.
Процесс создания индекса в Lucene очень интенсивно использует ЦП, и количество инвертированных индексов можно уменьшить, чтобы уменьшить потребление ЦП. Первая оптимизация заключается в уменьшении количества полей, вторая оптимизация — в уменьшении количества полей индекса. Конкретная операция заключается в установке атрибута индекса поля, поиск которого не требуется, наnot_analyzed
илиno
. Что касается _source и _all, то они мало влияют на реальную отладку, поэтому я не буду вдаваться в подробности.
Кроме того, если лог передается через такой компонент, как filebeat или logstash, обычно включается пакетный режим. Производительность может быть увеличена за счет пакетной обработки, но она не должна быть слишком большой, ее можно установить в соответствии с фактическими наблюдениями, обычно между 1k-1w.
End
ES имеет множество сценариев использования. Учитывая его природу NoSQL, некоторые даже используют его для замены традиционных реляционных баз данных.
Это нормально, но помните о его задержке. В этой статье основное внимание уделяется сценарию записи журнала, где пропускная способность является приоритетом, а задержка данных особенно очевидна. ES не предназначен для этого сценария по умолчанию, поэтому конфигурация «из коробки» неэффективна.
Мы узнали, что при написании ES есть процессы сброса, обновления и слияния. Среди них наибольшее влияние на ввод-вывод оказывают операции транслогирования и слияния, а наибольшее влияние на ЦП оказывает процесс создания индекса и слияния. В обычном дизайне отображения количество полей и количество полей индекса должны быть сведены к минимуму. Этот двусторонний подход может устранить два узких места ЦП и ввода-вывода.
Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус.