Datastax solr: Cassandra теперь будет сбрасывать до двух самых больших memtables, чтобы освободить память.

Я работаю с datastax 3.1 на одном узле с 4 ГБ оперативной памяти. Я ничего не менял в cassandra-en.sh и cassandra.yaml, кроме --Xss (из-за моей версии java, которая требует немного больше). Поэтому по умолчанию для Cassandra установлено значение 1Go my -Xms и параметры -Xmx: -Xms1024M - Xmx1024M

Но при вставке моих данных после примерно 200000 строк (в 3 разных column_families) журналы Solr и cassandra продолжают повторять такое предупреждение:

WARN StorageService Очистка CFS (Keyspace = 'OpsCenter', ColumnFamily = 'rollups60') для уменьшения нагрузки на память 17:58:07

WARN GCInspector Heap заполнен на 0,8825103486201678. Возможно, вам потребуется уменьшить размер таблицы памяти и / или кеша. Кассандра теперь очистит две самые большие таблицы памяти, чтобы освободить память. Отрегулируйте порог flush_largest_memtables_at в cassandra.yaml, если вы не хотите, чтобы Кассандра делала это автоматически

Итак, хорошо, моя куча заполнена, но почему после промывки моя куча все еще заполнена?

Если я перестану вставлять данные на этом этапе. Предупреждение повторять. Если я остановлюсь и перезапущу cassandra. Нет проблем поднять

Похоже, проблема с утечкой памяти? Итак, на что я должен смотреть?

Спасибо за помощь Futur.


java cassandra solr datastax datastax-enterprise
person hebus    schedule 14.10.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Одна вещь, которая требует памяти, - это кеши Solr. Взгляните на свой файл solrconfig.xml в директории conf каждого из ваших ядер Solr и посмотрите на значение, настроенное для кешей, таких как:

<filterCache class="solr.FastLRUCache"
             size="100"
             initialSize="0"
             autowarmCount="0"/>

Таких записей может быть несколько. Убедитесь, что по крайней мере autowarmCount и initialSize установлены на 0. Более того, уменьшите значение "size" до чего-то маленького, например, 100 или что-то в этом роде. Все эти значения относятся к количеству записей в кеше.

Еще одна вещь, которая может помочь, - это настройка Solr на более частое выполнение жестких коммитов. Найдите такую ​​запись, как:

 <!-- stuff ommited for brevity -->

 <autoCommit> 
   <maxDocs>5000</maxDocs> 
       <maxTime>15000</maxTime> 
       <openSearcher>false</openSearcher> 
 </autoCommit>

Вышеуказанные настройки будут записываться на диск каждый раз, когда добавляются 5000 документов или когда с момента последней фиксации прошло 15 секунд, что когда-либо происходило раньше. Также установите для openSearcher значение false.

Наконец, найдите эти записи и установите их следующим образом:

<ramBufferSizeMB>16</ramBufferSizeMB>
<maxBufferedDocs>5000</maxBufferedDocs>

Теперь, внесение всех этих модификаций в Solr сразу, несомненно, значительно замедлит его работу. Вместо этого попробуйте делать их постепенно, пока не избавитесь от ошибки памяти. Кроме того, может оказаться, что вам просто нужно выделить больше памяти для вашего Java-процесса. Если вы говорите, что у машины 4 ГБ ОЗУ, почему бы не попробовать свой тест с -Xmx2g или -Xmx3g?

person Shivan Dragon    schedule 17.10.2013

arrow_upward
1
arrow_downward

Cassandra пытается очистить пространство кучи, однако при очистке memtables не сбрасываются структуры данных кучи Solr.

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

Чтобы просмотреть использование кэш-памяти полей:

http://www.datastax.com/docs/datastax_enterprise3.1/solutions/dse_search_core_status

person Rock Brain    schedule 14.10.2013
comment
Я запутался. Есть ли способ заставить Solr поменять местами в физической памяти, чтобы избежать переполнения кучи JVM? Я знаю, это будет стоить времени, но если нет, это означает, что для одного узла я могу установить только около 1G0 данных индексации, поэтому (в моем случае) около 2 Go реальных данных ... - person hebus; 15.10.2013