Cassandra зависает после вставки 80 миллионов строк

Установка Cassandra с настройками по умолчанию. Просто сервер с одним узлом, 48 ГБ оперативной памяти, 2 ТБ жесткого диска. Было вставлено около 80 миллионов строк, когда он значительно замедлился. Новые подключения отклоняются с ошибкой тайм-аута.

Opssenter также выбрасывает тайм-ауты.

htop показывает 1 процесс cassandra, который загружает процессор на 100%

iotop показывает периодические чтения\записи, но очень малоинтенсивные - так что HDD не является узким местом

много оперативной памяти еще свободно и ничего не менялось

nodetool tpstats - не работал, раздавлен с "java.net.SocketTimeoutException: время чтения истекло"

статус nodetool - показывает, что сервер работает нормально (!): UN, загрузка 122GB, Owns 100%, токенов 256

tail /var/log/cassandra/system.log — для меня ничего информативного, последняя строчка

INFO [ScheduledTasks:1] 2014-02-16 04:36:21,824 StatusLogger.java (line 121) system.local

Что происходит? Как найти список выполняемых в данный момент операций? Как найти причину такого поведения? И как привести его в норму?

Спасибо!

P.S. В итоге выдало исключение:

ОШИБКА [ReadStage: 1550] 2014-02-16 05:22:26,476 CassandraDaemon.java (строка 192) Исключение в потоке Thread[ReadStage:1550,5,main] java.lang.OutOfMemoryError: пространство кучи Java в org.apache. cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:69) в org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76) в org.apache.cassandra.io.compress.CompressedRandomAccessReader.open( CompressedRandomAccessReader.java:43) в org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.createReader(CompressedPoolingSegmentedFile.java:48) в org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:39) в org. .apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1195) в org.apache.cassandra.db.columniterator.IndexedSliceReader.setToRowStart(IndexedSliceReader.java:108) в org.apache.cassandra.db.columniterator .IndexedSliceReader.(Inde xedSliceReader.java:84) в org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65) в org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42) в org. apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167) в org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62) в org.apache.cassandra.db.CollationController. collectAllData(CollationController.java:273) в org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53) в org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1560) в org.apache .cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1379) в org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:327) в org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadC ommand.java:65) в org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1396) в org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1931) в java .util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) в java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) в java.lang.Thread.run(Thread.java:744)


person Spaceman    schedule 16.02.2014    source источник
comment
Какую версию C* вы используете и каков размер кучи вашего узла?   -  person Lyuben Todorov    schedule 16.02.2014
comment
@LyubenTodorov Cassandra 2.0.5, размер кучи 8 ГБ   -  person Spaceman    schedule 16.02.2014
comment
Вы можете захотеть сделать доступной большую часть вашего system.log, а если вы еще не в рабочей среде, возможно, увеличьте уровень отладки для получения дополнительных сведений.   -  person Jay    schedule 17.02.2014
comment
Я обязательно буду. К настоящему времени я решил это, перезапустив cassandra - /etc/init.d/cassandra restart. Скрипт вставки данных создавался с учетом возможных проблем. Но даже при этом я был немного удивлен, что вставка данных продолжала нормально работать. Таким образом, метод «перезапустите и попробуйте еще раз» сработал хорошо, что звучит странно для любого пользователя, имеющего опыт работы с РСУБД.   -  person Spaceman    schedule 18.02.2014
comment
У вас должен быть дамп кучи в каталоге, из которого вы запустили C* (возможно, / или в домашнем каталоге пользователя C*, если вы используете пакет deb или rpm). У вас есть место, где вы можете загрузить это? Если нет, я могу сделать один для вас, если вы напишите мне.   -  person jbellis    schedule 19.02.2014


Ответы (1)


Вы уверены, что с точки зрения Кассандры на самом деле это 80 миллионов строк? Если вы используете CQL3 и первый столбец вашего первичного ключа одинаков для всех строк, тогда все они будут в одной строке под скрытыми, поскольку это ключ раздела. Это может вывести Кассандру из строя.

Проверьте cfhistograms для столбца Row Size и посмотрите, есть ли у вас массивная строка.

person Christopher Batey    schedule 17.02.2014
comment
да, есть 80 миллионов строк. Из-за алгоритма там не может быть много столбцов (есть счетчик, добавляющий 1,2,3... к ключу строки). А я и раньше проверял данные в опсцентре — да, всего по 2-3 столбца на строку. - person Spaceman; 18.02.2014
comment
Большие перегородки заставят ремонт быть несчастливым, но это примерно степень ущерба, который они нанесут. Определенно не должно привести к падению OOM. - person jbellis; 19.02.2014