Кассандре не хватает памяти (куча места)

Question

В последнее время мы немного экспериментируем с Cassandra (версия 1.0.7), и у нас, похоже, есть некоторые проблемы с памятью.Мы используем EC2 в качестве нашей тестовой среды, и у нас есть три узла с 3,7 ГБ памяти и 1 ядром при 2,4 ГБ, все из которых работают на сервере Ubuntu 11.10.

Проблема в том, что узел, который мы ударили из нашего экономичного интерфейса, регулярно умирает (примерно после того, как мы сохранили 2-2,5 ГБ данных).Сообщение об ошибке: OutOfMemoryError: Пространство кучи Java и, согласно журналу, фактически использовало всю выделенную память.

Узлы находятся под относительно постоянной нагрузкой и хранят около 2000-4000 ключей строк в минуту, которые пакетируютсячерез интерфейс Trift в 10-30 клавишах строк одновременно (по 50 столбцов в каждой).Количество операций чтения очень низкое - около 1000-2000 в день, и запрашиваются только данные одного ключа строки.В настоящее время используется только одно семейство столбцов.

Первоначально считалось, что в файле cassandra-env.sh что-то не так.Итак, мы указали переменные 'system_memory_in_mb' (3760) и 'system_cpu_cores' (1) в соответствии со спецификацией наших узлов.Мы также изменили «MAX_HEAP_SIZE» на 2G и «HEAP_NEWSIZE» на 200M (мы думаем, что второе связано со сборкой мусора).К сожалению, это не решило проблему, и узел, который мы ударили через Thrift, продолжает умирать регулярно.

В случае, если вы найдете это полезным, своп отключен, и объем незапускаемой памяти кажется очень высоким на всех 3 серверах (2.3ГБ, мы обычно наблюдаем объем незапускаемой памяти на других серверах Linux (около 0-16 КБ) (мы не совсем уверены, как неопределяемая память связана с Cassandra, это то, что мы наблюдали, глядя на проблему).Процессор все время простаивает.Куча памяти явно уменьшается время от времени в соответствии с nodetool, но, очевидно, с течением времени становится больше предела.

Есть идеи?Заранее спасибо.

Answer 1

значения по умолчанию cassandra-env.sh идеально подходят практически для всех рабочих нагрузок, поэтому пока вы не знаете, почему это происходит, лучше всего вернуть их к значениям по умолчанию, или вы можете ухудшить ситуацию, не осознавая этого.

Я вижу одновременные операции чтения и записи 2k / sec / node в нашем кластере, поэтому 2k-4k операций записи в минуту очень мало, хотя тот факт, что умирает только ваш узел, принимающий ваши соединения, немного странен.

Если вы подключите свое приложение к конечной точке экономичного на одном из других узлов, то это тот, который умирает?
Клиентские соединения используют память, поэтому стоит дважды проверить, что вы не подключаете слишком много одновременно. « netstat -A inet | grep 9160 » на умирающем узле кассандры должен указать, сколько у вас клиентских соединений. В зависимости от вашего приложения вы ожидаете 10 или 100, а не 1000.

Как выглядят записи?
Пишешь ли ты одни и те же ключи строк несколько раз, и если да, то добавляешь новые имена столбцов или перезаписываешь те же самые?
Насколько велика каждая запись? Что-нибудь еще вы можете сказать мне?
Если вы перезаписываете одни и те же имена столбцов в одних и тех же ключах строк, может возникнуть проблема с уплотнением. Если вы постоянно добавляете имена новых столбцов к одним и тем же ключам строк, возможно, ваши строки становятся слишком большими, чтобы поместиться в память.

вывод "nodetool -h localhost tpstats" на умирающем узле также может дать некоторые подсказки относительно того, где вы падаете. Что-либо постоянно ожидающее, вероятно, плохие новости, особенно при такой низкой скорости записи.

Если вы собираетесь использовать кассандру в производстве, вы должны получить графики внутренних органов, чтобы лучше понять, что происходит. jmxtrans и графит должны быть вашими новыми лучшими друзьями.

Answer 2

Есть некоторые вещи, которые вы можете попробовать настроить. Сначала убедитесь, что у вас нет кэширования строк в вашем семействе столбцов. Также стоит проверить журнал на наличие ошибок и tpstats, если что-то умерло из-за ошибки, и что-то копируется в очередь. Трассировка стека исключения также может быть значимой, так как на самом деле существуют разные типы OOM, которые могут означать просто настройки ядра.

Если вы просто используете слишком много памяти на узел, то для размера вашего набора данных попробуйте проверить cfstats, вы можете приблизительно определить, сколько места расходуется на фильтры Блума. Поскольку у вас больше строк в CF, это может быть линейно больше и является частью базового минимального объема памяти, который потребуется вашим узлам.

nodetool cfstats | grep Bloom.*Used | awk '{ SUM += $5} END { print SUM " bytes" }'

Поскольку вы не читаете очень часто, вы, вероятно, можете увеличить количество ложных срабатываний на них. Каждый SSTable имеет фильтр Блума, который он использует, чтобы проверить, существует ли в нем строка или нет. Вы можете изменить с помощью cqlsh

ALTER TABLE MyColumnFamily WITH bloom_filter_fp_chance = 0.1;

После этого вызовите обновление этого CF (это будет медленно) для каждого узла

nodetool upgradesstables MyKeyspace MyColumnFamily

Это может привести к тому, что чтение может занять больше времени, поскольку существует 10% -ная (.1) вероятность, что он проверит таблицы SSTable на наличие строк, которых в нем нет, что приведет к дополнительному поиску на диске.

Другой основной приемник памяти, если у вас есть семейства столбцов с большим количеством строк, - это частота выборки индекса. Это может быть изменено для уровня узла в cassandra.yaml

http://www.datastax.com/docs/1.1/configuration/node_configuration#index-interval

Если он настроен на получение дампов кучи в OOM (по-моему, -XX: + HeapDumpOnOutOfMemoryError включен), в каталоге / var / lib / cassandra / data должны быть некоторые дампы кучи. Вы можете открыть их в VisualVM или любом другом инструменте, который вам нравится, чтобы определить, какая часть кучи находится.