2013-10-14 8 views
0

Я работаю с datastax 3.1 на одном узле с 4Go ОЗУ. Я ничего не меняю в cassandra-en.sh и cassandra.yaml, кроме «--Xss» (из-за моей версии java, которая требует немного больше) Итак, по умолчанию Cassandra установлен в 1Go мои параметры -Xms и -Xmx : -Xms1024M -Xmx1024MDatastax solr: Cassandra теперь сместится до двух крупнейших memtables, чтобы освободить память

Но при вставке мои данные после того, как около 200 000 строк (в 3-х различных column_families), Solr и журналы Cassandra держать повторить этот вид предупреждения:

WARN StorageService Промывка CFS (= пространство ключей «OpsCenter», ColumnFamily = 'rollups60') для сброса давления памяти 17:58:07

WARN GCInspector Heap - 0.8825103486201678 полный. Возможно, вам придется уменьшить размер памяти и/или кеширования . Cassandra теперь будет сбрасывать до двух крупнейших memtables для освобождения памяти. Регулировка flush_largest_memtables_at порога в cassandra.yaml, если вы не хотите, Cassandra, чтобы сделать это автоматически

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

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

Как выглядит проблема с утечкой памяти? Итак, где я должен смотреть?

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

ответ

1

Одна вещь, которая боров памяти кэшей в Solr. Посмотрите на файл solrconfig.xml внутри «конф» реж каждого из ваших ядер 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?

1

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

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

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

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

+0

Я смущен. Есть ли способ заставить Solr поменять местами в физической памяти, чтобы избежать кучи JVM для заполнения? Я знаю, это будет стоить время, но если нет, это означает, что для одного узла я могу установить только 1G0 индексирующих данных, поэтому (в моем случае) около 2 Go реальных данных ... – hebus