Импорт дельты, вызывающий ответ Solr в два раза ИЛИ даже хуже

СОЛР ВЕРСИЯ 6.0.0

Всплески при импорте изменений – каждые 2 часа

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

  1. Время отклика удваивается
  2. Средняя загрузка ЦП удваивается, а если она работает почти до часа звона, то увеличивается даже до 10 раз.

Мои настройки кэша

 1. <filterCache class="solr.FastLRUCache"
                 size="5000"
                 initialSize="512"
                 autowarmCount="128"/>

    <queryResultCache class="solr.FastLRUCache"
                     size="10000"
                     initialSize="512"
                     autowarmCount="128"/>

     <documentCache class="solr.FastLRUCache"
                   size="100000"
                   initialSize="10000"
                   autowarmCount="0"/>

      <cache name="perSegFilter"
      class="solr.search.LRUCache"
      size="10"
      initialSize="0"
      autowarmCount="10"
      regenerator="solr.NoOpRegenerator" />

    <enableLazyFieldLoading>true</enableLazyFieldLoading>

    <queryResultWindowSize>20</queryResultWindowSize>
    <queryResultMaxDocsCached>200</queryResultMaxDocsCached>
    <useColdSearcher>false</useColdSearcher>

Большинство моих запросов ориентированы на ЦП, поскольку они включали множество запросов IN, а не запросов IN. Также есть условие для подсчета очков. Предполагая, что мои запросы будут по-прежнему зависеть от процессора.

Справка

Что я делаю неправильно, поскольку мой дельта-импорт вызывает такой высокий отклик.

  • Размер индекса: 2 ГБ
  • Серверов: 4
  • Обслуживание: 100к в час

Кроме того, дельта-обновление приводит к обновлению 200 тысяч записей из 1 миллиона, поскольку одно из полей solr (последний вход в систему) часто меняется.

Мой дельта-импорт состоит из трех частей

а) удалить -- около 100

б) вставить -- около 30к

в) обновления -- около 1,9 тыс. (один или два столбца)

для вставки и обновления я использую обновление с помощью /update?&overwrite=true&wt=json

для удаленного stream.body=id:1 stream.body=id:1 .... и затем обновить

и в конце с помощью /update?commit=true&wt=json

Есть ли какой-либо оптимизированный способ сделать это (DIH лучше, но не оптимизирован с точки зрения производительности)


person Quiz Master    schedule 27.11.2018    source источник
comment
Пожалуйста, не используйте здесь индийские слова, такие как лак. Это только запутает людей.   -  person James Z    schedule 27.11.2018
comment
@JamesZ помогите с вопросами?   -  person Quiz Master    schedule 27.11.2018
comment
Нет, и просить конкретных людей помочь вам не считается хорошей практикой.   -  person James Z    schedule 27.11.2018
comment
Итак, что вы ожидаете? Ваш сервер работает под нагрузкой, и вы увеличиваете нагрузку на него, запрашивая индексирование контента (20% всех ваших данных) из вашей базы данных. Это будет потреблять ресурсы, а когда ресурсы потребляются, время отклика будет увеличиваться, так как ваш сервер занят. Один из вариантов — индексировать на отдельный сервер, а затем реплицировать этот индекс на ваши узлы запросов после завершения индексации.   -  person MatsLindh    schedule 28.11.2018
comment
@MatsLindh У меня есть один главный и три подчиненных сервера ... нагрузка на все серверы увеличивается.   -  person Quiz Master    schedule 28.11.2018


Ответы (1)


У вас очень большие кеши и большие настройки автопрогрева. Таким образом, когда ваш импорт попадает в фиксацию, программы чтения индекса должны быть повторно открыты, а кэши перестроены. А с useColdSearcher=false вы получите задержку ответа, пока все эти кэши прогреваются.

Вы можете попробовать изменить этот параметр, это сделает запросы медленнее, но не блокирует во время прогрева.

Вы также можете поэкспериментировать с настройками мягкой и жесткой фиксации, но помните, что мягкие фиксации делают содержимое видимым при запуске, поэтому, если вы сначала удаляете записи, а затем программная фиксация запускается частично через переиндексацию, вы можете увидеть частичные результаты. Не так много проблем с частичным обновлением.

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

person Alexandre Rafalovitch    schedule 28.11.2018
comment
1. Я могу попробовать useColdSearcher=false.... 2. У меня есть один главный и три подчиненных сервера. Нагрузка увеличивается одинаково на всех серверах, а не только на главном, так как все запросы распределяются поровну распределителем нагрузки. может ли кто-нибудь из них помочь в моем случае - person Quiz Master; 28.11.2018
comment
› еще одно сомнение в случае главного подчиненного устройства, доступна ли стратегия автопрогрева для подчиненных устройств › Также должен ли я иметь ограничение на максимальное количество подключений, чтобы сервер solr не отключался, и если да, то как выбрать этот максимальный нет. ? - person Quiz Master; 28.11.2018
comment
я уже использую ‹useColdSearcher›false‹/useColdSearcher› - person Quiz Master; 29.11.2018