Слишком много открытых файлов во время восстановления Cassandra nodetool

Я сделал команду восстановления nodetool на одном узле. Этот узел вышел из строя, и в файлах журнала появилось следующее сообщение об ошибке:

INFO  [STREAM-IN-/192.168.2.100] 2015-02-13 21:36:23,077 StreamResultFuture.java:180 - [Stream #8fb54551-b3bd-11e4-9620-4b92877f0505] Session with /192.168.2.100 is complete
INFO  [STREAM-IN-/192.168.2.100] 2015-02-13 21:36:23,078 StreamResultFuture.java:212 - [Stream #8fb54551-b3bd-11e4-9620-4b92877f0505] All sessions completed
INFO  [STREAM-IN-/192.168.2.100] 2015-02-13 21:36:23,078 StreamingRepairTask.java:96 - [repair #508bd650-b3bd-11e4-9620-4b92877f0505] streaming task succeed, returning response to node4/192.168.2.104
INFO  [AntiEntropyStage:1] 2015-02-13 21:38:52,795 RepairSession.java:237 - [repair #508bd650-b3bd-11e4-9620-4b92877f0505] repcode is fully synced
INFO  [AntiEntropySessions:27] 2015-02-13 21:38:52,795 RepairSession.java:299 - [repair #508bd650-b3bd-11e4-9620-4b92877f0505] session completed successfully
INFO  [AntiEntropySessions:27] 2015-02-13 21:38:52,795 RepairSession.java:260 - [repair #03858e40-b3be-11e4-9620-4b92877f0505] new session: will sync node4/192.168.2.104, /192.168.2.100, /192.168.2.101 on range (8805399388216156805,8848902871518111273] for data.[repcode]
INFO  [AntiEntropySessions:27] 2015-02-13 21:38:52,795 RepairJob.java:145 - [repair #03858e40-b3be-11e4-9620-4b92877f0505] requesting merkle trees for repcode (to [/192.168.2.100, /192.168.2.101, node4/192.168.2.104])
WARN  [StreamReceiveTask:74] 2015-02-13 21:41:58,544 CLibrary.java:231 - open(/user/jlor/apache-cassandra/data/data/data/repcode-398f26f0b11511e49faf195596ed1fd9, O_RDONLY) failed, errno (23).
WARN  [STREAM-IN-/192.168.2.101] 2015-02-13 21:41:58,672 CLibrary.java:231 - open(/user/jlor/apache-cassandra/data/data/data/repcode-398f26f0b11511e49faf195596ed1fd9, O_RDONLY) failed, errno (23).
WARN  [STREAM-IN-/192.168.2.101] 2015-02-13 21:41:58,871 CLibrary.java:231 - open(/user/jlor/apache-cassandra/data/data/data/repcode-398f26f0b11511e49faf195596ed1fd9, O_RDONLY) failed, errno (23).
ERROR [StreamReceiveTask:74] 2015-02-13 21:41:58,986 CassandraDaemon.java:153 - Exception in thread Thread[StreamReceiveTask:74,5,main]
org.apache.cassandra.io.FSWriteError: java.io.FileNotFoundException: /user/jlor/apache-cassandra/data/data/data/repcode-398f26f0b11511e49faf195596ed1fd9/data-repcode-tmp-ka-245139-TOC.txt (Too many open files in system)
        at org.apache.cassandra.io.sstable.SSTable.appendTOC(SSTable.java:282) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at org.apache.cassandra.io.sstable.SSTableWriter.close(SSTableWriter.java:483) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:434) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:429) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at org.apache.cassandra.io.sstable.SSTableWriter.closeAndOpenReader(SSTableWriter.java:424) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at org.apache.cassandra.streaming.StreamReceiveTask$OnCompletionRunnable.run(StreamReceiveTask.java:120) ~[apache-cassandra-2.1.2.jar:2.1.2]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_31]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_31]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_31]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_31]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_31]
Caused by: java.io.FileNotFoundException: /usr/jlo/apache-cassandra/data/data/data/repcode-398f26f0b11511e49faf195596ed1fd9/data-repcode-tmp-ka-245139-TOC.txt (Too many open files in system)
        at java.io.FileOutputStream.open(Native Method) ~[na:1.8.0_31]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:213) ~[na:1.8.0_31]
        at java.io.FileWriter.<init>(FileWriter.java:107) ~[na:1.8.0_31]
        at org.apache.cassandra.io.sstable.SSTable.appendTOC(SSTable.java:276) ~[apache-cassandra-2.1.2.jar:2.1.2]
        ... 10 common frames omitted

У нас есть небольшой кластер с 5 узлами: node0-node4. У меня есть одна таблица с примерно 3,4 миллиардами строк с репликой 3. Вот описание таблицы:

CREATE TABLE data.repcode (
rep int,
type text,
code text,
yyyymm int,
trd int,
eq map<text, bigint>,
iq map<text, bigint>,
PRIMARY KEY ((rep, type, pcode), yyyymm, trd))
WITH CLUSTERING ORDER BY (yyyymm ASC, co_trd ASC, md5 ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'max_threshold': '32'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';

Я использую Кассандру 2.1.2. Я установил ограничение максимального количества открытых файлов для всех моих узлов на 200 000.

Прежде чем выполнить команду восстановления nodetool, я подсчитал количество файлов в моих каталогах данных. Вот количество на каждом из моих узлов до сбоя:

node0: 27'099 
node1: 27'187 
node2: 36'131 
node3: 26'635 
node4: 26'371

Теперь после аварии:

node0:   946'555 
node1:   973'531 
node2:   844'211 
node3: 1'024'147 
node4: 1'971'772

Нормально ли, что количество файлов в одном каталоге unix увеличивается до такой степени? Что я могу сделать, чтобы избежать этого? Как избежать этой проблемы в будущем? Должен ли я увеличить количество открытых файлов? Это кажется мне уже очень большим. Мой кластер слишком мал для такого количества записей? Должен ли я использовать другую стратегию уплотнения?

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


cassandra nodetool
person BuckBazooka    schedule 16.02.2015    source источник
comment
К каким файлам относятся эти числа? Это все обычные sstables или моментальные снимки? Совпадают ли они с количеством SSTables, указанным nodetool cfstats?   -  person Stefan Podkowinski    schedule 16.02.2015

Ответы (2)


arrow_upward
2
arrow_downward

Каков результат ulimit -a | grep "open files"?

Следующие рекомендуемые ограничения ресурсов (ulimit) для Cassandra следует установить следующим образом (для RHEL 6):

cassandra - memlock unlimited
cassandra - nofile 100000
cassandra - nproc 32768
cassandra - as unlimited

Точный файл и имя пользователя будут различаться в зависимости от типа установки и пользователя, от имени которого вы запускаете Cassandra. Вышеприведенное предполагает, что строки взяты из /etc/security/limits.d/cassandra.conf с пакетной установкой, запускающей Cassandra от имени пользователя "cassandra" (для установки tarball вам понадобится /etc/security/limits.conf).

Если ваши настройки отличаются от этих, сверьтесь с документом, ссылку на который я дал выше. Обратите внимание, что если вы запускаете Cassandra от имени пользователя root, некоторые дистрибутивы требуют явной установки ограничений для пользователя root.

Изменить 20180330

Обратите внимание, что приведенная выше настройка /etc/security/limit.conf работает для систем CentOS/RHEL 6. В противном случае корректировка должна быть выполнена в /etc/security/limits.d/cassandra.conf.

person Aaron    schedule 16.02.2015
comment
Чуть более новая ссылка, связанная с ограничениями ресурсов: docs.datastax.com/en/ landing_page/doc/landing_page/ Обратите особое внимание на информацию о RHEL 6 и RHEL 7. - person dustmachine; 30.03.2018
comment
Хороший звонок, @dustmachine! Правка сделана. - person Aaron; 30.03.2018

arrow_upward
0
arrow_downward

Количество открытых файлов не должно ограничиваться установками Cassandra. Это может быть 10 000 000, вообще никаких проблем. Проблема в том, что если у вас слишком много открытых файлов: у вас слишком много таблиц ss, что приводит к очень долгому времени перезапуска. Чтобы предотвратить это, используйте nodetool comact на всех узлах, где количество открытых файлов значительно превышает исходное число. Используйте следующее как владелец программного обеспечения Cassandra, чтобы подсчитать количество открытых файлов во время восстановления:

for i in {1..1000}; do echo -n "This is a test in loop $i "; lsof -p $(ps -ef | grep "/var/log/cassandra/gc.log" | grep -v "color" |  awk '{print $2}') | wc -l ; sleep 500; done
person Yuri Levinsky    schedule 02.09.2020
comment
Предполагая, что вы имеете в виду nodetool compact. Я бы не стал этого делать, так как это, скорее всего, предотвратит повторный запуск уплотнения, и вы вернетесь в ту же ситуацию. - person Aaron; 02.09.2020
comment
это зависит от количества процессоров, которые есть на каждом узле, и количества процессов сжатия, разрешенных в Cassandra. Я уменьшил количество открытых файлов на каждом узле с 1,2 млн до ~ 20 тыс. Размер кластера 15 узлов 10Tb, версия 3.6. Так что до 100к ехать не обязательно. - person Yuri Levinsky; 07.09.2020