В Elasticsearch есть несколько настроек, которые люди просто не могут не настроить. Мы понимаем: ручки так и просятся, чтобы их повернули. Но из всех ручек, которые можно повернуть, эти лучше оставить в покое. Ими часто злоупотребляют, что приводит к ужасной стабильности или ужасной производительности. Или и то, и другое.
Сборщик мусора
JVM использует сборщик мусора для освобождения неиспользуемой памяти. Этот совет является продолжением предыдущего, но заслуживает отдельного раздела, чтобы подчеркнуть его важность.
Не изменяйте сборщик мусора по умолчанию!!!
По умолчанию в Elasticsearch используется сборщик мусора Concurrent-Mark and Sweep (CMS). Этот GC работает одновременно с выполнением приложения, что позволяет минимизировать паузы. Однако у него есть две фазы " stop-the-world". Кроме того, у него возникают проблемы со сбором больших куч.
Несмотря на эти недостатки, в настоящее время это лучший GC для серверного ПО с низкой задержкой, такого как Elasticsearch. Официальная рекомендация - использовать CMS.
Существует более новый GC, называемый Garbage First GC (G1GC). Этот новый GC разработан для минимизации пауз еще больше, чем CMS, и для работы с большими кучами. Он работает, разделяя кучу на регионы и предсказывая, какие регионы содержат больше всего восстанавливаемого пространства. Собирая эти регионы первыми (сначала мусор), он может минимизировать паузы и работать с очень большими кучами.
Звучит здорово! К сожалению, G1GC все еще новый, и в нем регулярно обнаруживаются новые ошибки. Эти ошибки обычно относятся к типу segfault и вызывают жесткие сбои. Набор тестов Lucene очень жесток к алгоритмам GC, и похоже, что в G1GC еще не все недоработки устранены.
Мы бы хотели когда-нибудь рекомендовать G1GC, но пока он просто недостаточно стабилен, чтобы соответствовать требованиям Elasticsearch и Lucene.
Пулы потоков
Все любят настраивать пулы потоков. По какой-то причине кажется, что люди не могут устоять перед увеличением количества потоков. Много индексируете? Больше потоков! Много поиска? Еще больше потоков! Узел простаивает 95% времени? Больше потоков!
Настройки пула потоков по умолчанию в Elasticsearch очень разумны. Для всех пулов потоков (кроме поиска) количество потоков устанавливается равным количеству ядер процессора. Если у вас восемь ядер, вы можете одновременно запускать только восемь потоков. Поэтому имеет смысл назначить только восемь потоков для любого конкретного пула потоков.
Поиск получает больший пул потоков и настраивается на int((# of cores * 3) / 2) + 1.
Вы можете возразить, что некоторые потоки могут блокироваться (например, при операции ввода-вывода на диск), поэтому вам нужно больше потоков. В Elasticsearch это не является проблемой: большая часть дискового ввода-вывода обрабатывается потоками, управляемыми Lucene, а не Elasticsearch.
Более того, пулы потоков сотрудничают, передавая работу друг другу. Вам не нужно беспокоиться о том, что сетевой поток заблокируется из-за ожидания записи на диск. Сетевой поток уже давно передал этот блок работы другому пулу потоков и вернулся к работе с сетью.
Наконец, вычислительная мощность вашего процесса конечна. Наличие большего количества потоков просто заставляет процессор переключаться между контекстами потоков. Одновременно процессор может выполнять только один поток, поэтому, когда ему нужно переключиться на другой поток, он сохраняет текущее состояние (регистры и т.д.) и загружает другой поток. Если вам повезет, переключение произойдет на том же ядре. Если не повезет, переключение может переместиться на другое ядро и потребовать транспортировки по межъядерной шине связи.
Это переключение контекста съедает циклы, просто выполняя административную работу; по оценкам, на современных процессорах это время может достигать 30 мкс. Поэтому, если поток не будет заблокирован дольше 30 мкс, весьма вероятно, что это время было бы лучше потратить на обработку и завершение работы раньше.
Люди регулярно устанавливают потоковые пулы на глупые значения. На восьмиядерных машинах мы сталкивались с конфигурациями с 60, 100 и даже 1000 потоков. Такие настройки будут просто перегружать процессор, а не выполнять реальную работу.
Итак. В следующий раз, когда вы захотите настроить пул потоков, пожалуйста, не делайте этого. А если вы не можете удержаться, пожалуйста, помните о количестве ядер и, возможно, установите двойное количество. Больше этого - просто расточительство.