Периодические зависания

Обычно термины распределены по закону Ципфа1 поэтому некоторые термины будут повторяться на всех шардах, но многие будут встречаться только на одной или двух. Поэтому объем потребления памяти уменьшиться но не в 14 раз. Может раз 5-7 или меньше. Зависит от того, как у вас термины распределены.

Эх, была бы возможность выбирать при rewrite, топ самых высокочастотных слов, это бы решило все мои проблемы (убрало бы кучу слов с ошибками). Я видел на гитхабе обсуждение по этому вопросу, жаль что не реализовали этот функционал.

Значит так, план такой:

  1. Сейчас я уменьшаю количество шард до 4 и переиндексирую.
  2. Подключаю вторую ноду.

О результатах этих действий я отпишусь:)

Вместо переиндексации можно попробовать shrink index API. Эффект должен быть такой-же, но будет быстрее.

Вот что случилось. У нас был арендован второй сервер, на котором доиндексировались данные. Количество шард одинаковое - 14шт. На этом сервере эластик выдерживает в 2 раза больше нагрузки и не зависает во время очистки кучи. Такой результат нас полностью устраивает, так что вопрос можно считать закрытым. Игорь, спасибо за помощь!

Исходя из различий между двумя системами, можно предположить, что проблема могла возникнуть из-за:

  1. Частых переиндексирований.
  2. Случайно примененного автомаппинга. (В последствии я создал новый набор полей, с нужными типами, а эти игнорировались)
  3. Версия эластика 5.6.4 у нового сервера, против 5.6.2 на старом.

Я думаю, что 3. 1 и 2 на эту проблему существенно влиять не должны были. А вот в 5.6.4 уменьшился кеш запросов.

Возможно, но все равно, полученные знания в этой теме не будут проигнорированы, и будут применены в будущем на других индексах. Так что еще раз спасибо!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.